In T11946#239568, @labster wrote:

Finally, I want to get a link to the documentation of the entire process of installing an extension -- repos to edit, deploy steps, testing.

Fixed Snapblocks with https://github.com/miraheze/mw-config/commit/7d1c571166aab78174812c50cdb21ae73a3b48e4

From my testing, Extension:UnlinkedWikibase is now working.

It should have been installed in https://github.com/miraheze/mw-config/pull/5481 . Let me see what went wrong.

Same with Snap! Blocks on snapwikiwiki.

Is it possible to have it changed in LocalWiki if I make a PR? I want to make an extended confirmed protection group like on Wikipedia

Due to custom rights being used almost always in this is why it can't be because we can't add custom rights to ManageWiki right now.

This won't be possible in ManageWiki at this time, not to say it won't be eventually.

Whoops Extension tags prob not right

Great then, this is resolved then

Confirmation that the wikis undelete worked

Can you please try undeleting a wiki now?

The problem still exists (or happened again?). Still when I try to assgin permissions to the sysop group, it returns "Fatal exception of type "TypeError" ".

won't be working on this for the foreseeable future.

Security advisory is now published. This task should be good for opening to the public now. For those reading this, we actually found some more XSS vectors when deploying the fixes to prod, so we actually have multiple patches in the GHSA for this one.

Should be fixed.

I just realized it will be better to just leave deploying the fixes to someone with access to mwtask181. Removing myself as assignee as my part is done, I think.

I've set confidentiality to high, since you could read private ManageWiki settings (for example, the Discord webhook for wikis using that extension) with XSS on those pages.

https://github.com/miraheze/ManageWiki/security/advisories/GHSA-4jr2-jhfm-2r84

I'm going to create a new draft GHSA, GitHub got bugged and thinks there are no changes waiting to be merged from the private fork sigh.

security advisory draft (https://github.com/miraheze/ManageWiki/security/advisories/GHSA-42fh-6pcr-3j58) is ready, all the changes have been made to the private fork if I'm not missing anything. Waiting for an SRE to review everything and give me the okay (or merge the changes themselves) so that they can double check my work and we can deploy the fixes to production as soon as possible.

Please do a security merge not a normal PR, should be fairly easy to do security with GitHub

I think I'm good to go to squash all of these and make a PR.

Adding all the messages that has an issue to wgRawHtmlMessages is a mitigation to this but it might be to complex with to many at this time.

@Universal_Omega You mean making the help messages in MWS.php, like https://github.com/miraheze/mw-config/blob/master/ManageWikiSettings.php#L109, interface messages? Because if so that looks like a complex rewrite. Also, all of those messages as well as managewiki-requires, managewiki-conflicts, and all the various right-* messages from core that are also XSS vectors in the permissions subpage must be added to wgRawHtmlMessages. We can do that, if you want, but after this.

I think what we should do is allow raw messages in MWS to be defined in config, and if it is, add them to $wgRawHtmlMessages, which prevents true security vulnerabilities by not only require editinterface, but also the same rights to editsitecss/js which would mean absolutely no difference from Common.js, etc...

Yeah there's no way my last patch is right.

Confirmed in Special:ManageWikiDefaultPermissions also

New patch superseding the other patch. Only thing missing is I think the XSS on the permissions subpage, which seems a bit more complex.

Also, just to clarify my previous message.

I think I know what is causing this, so I'll try to get this fixed tomorrow at the latest.

Assuming that patch fixes that for the extensions subpage, I can more or less make a theory (the form descriptor is passed around through so many functions that it is hard to keep track).

Looking at meta.miraheze.org, that is indeed supposed to be the "label" (it is not actually a label HTML element)

https://github.com/miraheze/ManageWiki/blob/75510297a32ed8881c98212f29001d226f0a833e/includes/FormFactory/ManageWikiFormFactoryBuilder.php#L269 where required and conflicting extensions are added to the form.

/extensions and /settings confirmed busted. /core doesn't give any alerts.

If that would be more performant, then I'll try to do it that way. I didn't have any ideas on how to show to the users the existence of global extensions anyway, and showing them alongside regular extensions would be the best way.

We can use ExtensionRegistry::getAllThings() to get a list of all installed extensions, and compare it against $wgManageWikiExtensions

I agree with this task and was going to propose something like this but for most of them users should not be permitted to disable them and it should be made clear that they're "global extensions" and they shouldn't try to ask for us to disable them (as I feel like there's always going to be some who want to get rid of extensions they think they're not using)

We can use ExtensionRegistry::getAllThings() to get a list of all installed extensions, and compare it against $wgManageWikiExtensions to know which ones are being loaded outside of ManageWiki. As for showing this information to users, I don't yet know how to approach that.

Got it. Thank you.

Fixed now with https://github.com/miraheze/ManageWiki/commit/f01696ad5b41b3565b778592cf1ceecba75f2070

Just tried, the error persists, this is the ID:
[87edcc51ad4131f2c978cf16] 2024-01-31 20:53:16

Hi, I tried something, can you please see if it works for you now?

I think since investigating would be quite tricky it might be preferable to try a reset of all permissions. Would that be okay?

In T11716#234939, @Universal_Omega wrote:

It would only create technical debt to be renamed on certain wikis, if its renamed at all a name that covers central and child wikis would be good. However we could just add an alias for something else and have it change page title while in a technical aspect it is the same page is possible.

It would only create technical debt to be renamed on certain wikis, if its renamed at all a name that covers central and child wikis would be good. However we could just add an alias for something else and have it change page title while in a technical aspect it is the same page is possible.

1. The main reason for giving bureaucrats the ability to queue their wikis for deletion is to allow them to get rid of their unwanted wikis faster without requiring Steward intervention, speeding up the deletion process and allowing other users to use the subdomain quicker. Asking "why do bureaucrats need the ability to mark their wikis as queued for deletion when they can just mark them as closed?" is basically the same as asking "why do bureaucrats need the ability to mark their wikis as closed when they can just mark them as inactive?"
2. Other bureaucrats can untick the "Queued for deletion" box if a rogue bureaucrat ticks the box; this inherently provides community consensus, though your idea would also be helpful in ensuring that. Another way would be to prevent wikis queued for deletion less than two weeks ago from being deleted when the deletion script is run, giving local communities time to dispute controversial deletion queue additions.
3. The sitenotice part of my proposal is mostly aimed at preventing confusion regarding wiki requests with the same subdomain as a "deleted" wiki; a special page stating that the wiki is queued for deletion might still cause confusion, as some users upon reading it may think, "No wiki exists here anymore, this subdomain is free to use." A sitenotice + having the wiki's content still be readable is the only way to ensure that confusion is minimized.

I agree that automatic backups are a necessity, though they may not necessarily help here.

Same here. ID I just got by trying back: 14e8797367faead87e2bc0e0. Only able to see the source code, but not to edit.

In T11595#233602, @Universal_Omega wrote:

Does this still happen?

Does this still happen?

Blocked/waiting on T11520 since that's the best way to be able to implement my idea (if there's no objections to this approach that is)

After further reflection, this is what I'd propose. It might not be convenient technically but I feel like there's a reason we don't currently allow single bureaucrats to delete/undelete and there have certainly been controversial cases where bureaucrats have been in disagreement about closures so I can imagine it would be very similar for deletions.

Should be fixed