In T408383#11485780, @Reedy wrote:

Just to point out, a random zip with an exe that you've linked isn't necessarily any better for a random user than the other solutions you reference, and their flaws.

Ideally the HTML should be built server side in the Lua module, not in the JavaScript, which means everything would be sanitized by MediaWiki. You would also have the benefit of improving performance (No "Loading" flash), and reducing complexity of the JavaScript.

@Xeverything11 WMF's future audiences team are creating a Roblox game and are using Phabricator to track this

I am thinking that once authentication is standalone, you could put the entire MediaWiki stack behind authentication. The goal being to completely remove it from the attack surface, making any MediaWiki-level vulnerabilities irrelevant for private wikis.

I would say there is probably some argument for T297791, being able to decouple authn from the rest of mediawiki would prevent these types of vulnerabilities.

I would say there is probably some argument for T297791, being able to decouple authn from the rest of mediawiki would prevent these types of vulnerabilities. This is the 3rd vulnerability where an attacker could dump all the content of our private wikis (T297322 and T297574 being the other two, which were exploitable since 2014), I don't think it can be guaranteed that another vulnerability like this won't come at some point in the future, code evolves and since private wiki configuration is not always taken into account it can be easy to create these types of vulnerabilities.

A simpler, temporary approach might be to just change htmlform-user-not-valid to "This isn't a valid username." or similar which wouldn't break anything, just downgrade the usefulness of the message.

However with a different Accept header it works strangely :

Still broken for me:

Perhaps a good solution is to have VE open the Upload Wizard in a new window. We can implement cross-window communication with postMessage API, so when the user has finished the upload, we can close the window and (hopefully) refocus the tab they were editing with and the UW tab can send the file name or any other required info about the file back to VE before closing to allow VE to automatically insert the file into the Wikitext. This would of course introduce some mutual dependencies between VE and UploadWizard, but we can put the feature behind a config.

In light of https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Understanding_AbuseFilter_code we should consider declining this, the filter has basically been broken its entire existence and if it had worked properly I don't think that research report would have had the same result, nor would it have resulted in the same level of frustration.

I'm also having some pretty severe packet loss to esams.

ping phabricator.wikimedia.org -c10
PING phabricator.wikimedia.org (185.15.59.224) 56(84) bytes of data.
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=1 ttl=55 time=42.5 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=6 ttl=55 time=18.7 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=7 ttl=55 time=130 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=9 ttl=55 time=94.3 ms

Weird, it's working fine for me now too. Not sure why I was having trouble with it yesterday, sorry about that.

This is a local wiki problem, the message is defined at https://commons.wikimedia.org/wiki/MediaWiki:Exif-model-value. If it is a big enough problem, Commons community could probably write a Lua module that checks for special characters like < or > which break the link and conditionally output just the content instead of trying to make the link.

https://performance.wikimedia.org/xhgui/run/symbol?id=67d4b97cbb2058ea7bc85e13&symbol=MediaWiki%5CMassMessage%5CContent%5CMassMessageListContentHandler%3A%3AgetTargetsHtml: LinkRenderer does not cope very well with that page having over 50000 links. Also doesn't seem like LinkBatch is doing much in this situation, I think this is because the size of LinkCache is capped at 10000, so it will populate the first 10k, then populate the rest evicting the entries until the last 10k. Then when it goes to make the links it misses the cache and evicts and populates from the beginning again, a sort of cache thrashing.

I think this is intentional and propose to close as declined, the image isn't part of the file page so showing it doesn't make a lot of sense because it is irrelevant. What are the arguments for showing it in a diff?

GitHub is confused... on purpose...

OCG is defunct.

This is a styling issue not a bug, but I fixed it on the referenced page.

Add gadget author

I can reproduce on all wikis but you have to start out in visual editing and then switch to wikitext editing. Somehow the action of switching the editor seems to remove the message altogether.

Some more sensible error message saying that you can't access the version because it's revdeleted

But the client is requesting plain wikitext output (text/x-wiki or page content model), I don't think it would be a great idea to change the status quo and have MediaWiki suddenly start returning HTML to clients unexpectedly on 404. Of course a reverse proxy like Varnish might add its own HTML to a 404 response but that's not MediaWiki's responsibility nor is it how most non-Wikimedia wikis are setup.

According to https://gerrit.wikimedia.org/g/mediawiki/core/+/d38a67858dfb0ddea387d49720a8162540b579c3/includes/parser/Sanitizer.php#599

It would be really nice if we could resolve this.

Copying my description:

I had a look at how this code works and realised we are actually getting the default options in UserOptionsManager::loadUserOptions regardless of whether we are using a cached value or actually need new default options. This would fix the issue described in this task.

In T386883#10566990, @Urbanecm_WMF wrote:

Thanks for catching this! I was under the conviction UserOptionsLookup would cache the user options set for all users, and thus conditional defaults do not need to do any caching. On a closer inspection of the code, that assumption seems to be incorrect – UserOptionsManager apparently only caches what is stored in the database (user_properties), and never the defaults. With the introduction of conditional defaults, that might be something to reconsider. Is there a reason to not have the caching in either DefaultOptionsLookup or ConditionalDefaultsLookup, rather than in the code for individual conditions? Do you have any insights on this, @Dylsss?

Seems to make up a significant chunk of time spent inside a request for logged in users.

Is this actually too performance intensive nowadays? I ask because this is happening in production on Commons already for every file read (here) and there doesn't seem to be any performance concerns with regards to that (although I tend to think that should be on the client side)?

Hmm I am not sure if I agree about

On Special:Log, the "[cascading]" note is displayed at the end of the log entry, as if it applied to all restriction types, rather than only the edit restriction.

You cannot add categories this way, it may look like you can, but when you actually click on the category the page is not there. This is why I described it as a red herring.

Noting T3965 was also declined. How does disabling these functions improve security?

I wouldn't call this a bug report when MediaWiki isn't intended to be ran in this type of environment. Changed to feature request.

While duplicate categories to the same OutputPage should probably be de-duplicated in general. It also isn't correct that adding an interface message to an OutputPage adds its own categories to the category links of the OutputPage. See for example https://patchdemo.wmcloud.org/wikis/5293491307/wiki/MediaWiki_talk:Talkpageheader which has Category:Noop from the interface message, but this is actually a red herring as the page is not actually in that category.

Which protocol(s) do we use and/or which protocols are available/enabled in our CAS-SSO configuration? If OAuth2 there is probably stuff to adapt in https://we.phorge.it/source/phorge/browse/master/src/applications/auth/adapter/ (as https://gitlab.wikimedia.org/repos/phabricator/extensions/-/tree/wmf/stable/src/oauth is our custom MW OAuth1 stuff).

I had a look around and found https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/cas-overlay-template/+/refs/heads/master/build.gradle#277. OAuth2 isn't enabled, however OIDC is which is based on OAuth2. Related upstream task: https://we.phorge.it/T15942, and it doesn't look too hard to implement either.

Do we have a test instance somewhere which allows to test auth against?

https://idp-test.wikimedia.org?

In it's current form it doesn't look like the bot would work as it is hardcoded to only work on files used in the main namespace of a project: https://github.com/wikimedia/CommonsNotifier/blob/5dfcfc5ba1564f20fc4801db28b13d2eb97fc286/post-notifs.py#L155

Very likely T383508, please check again tomorrow, should be fixed once wmf.13 gets deployed to Commons.

LocalFile->getDescriptionText() should probably specify the main slot explicitly.

Just noting https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1112359 would fix this.

A lot has changed in MediaWiki architecturally since the last patch, I think this task is now realistic to resolve.

UploadWizard does take the ImageDescription exif into the description field automatically. If this isn't working then it can be reopened as a bug.

After:

I think it would sense here to just redirect the user away in the rare case someone has JavaScript disabled. We can redirect them to Commons:Upload, where they can choose the relevant upload form, which I think is better UX especially since users using the UploadWizard are less likely to be experienced users. And it lets us get rid of bootstrapping Special:Upload which feels kinda hacky.

Thanks for actioning!

This bug isn't in wmf.11 it was introduced after, does this need to be backported?

This was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UploadWizard/+/1109047 rather than the above patch

It is caused by 9fa34fe9b5eb8c297ff3125ffa758c30f8ca707b

Note: to reproduce on a local mediawiki install requires setting $wgUploadWizardConfig['customLicenseTemplate'] = 'Template:License_template_tag'; to trigger the faulty code path.

For the revert: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TimedMediaHandler/+/07675b0d0ec82579d5dc32bfd434af030b2e3211/includes/Hooks.php#355
Not sure why page protection would reset the transcode.

I'm going to go ahead and close this as declined, enwiki doesn't make local copies any more and instead a bot is used on Commons to protect the images via cascade transclusion, and even then T25133 is probably a better solution. Don't see this being a helpful feature to non-Wikimedia users either.

Seems it uses createpage as the restriction: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EntitySchema/+/0715a8062e3872bc29eba624b237b55b3a8df330/src/MediaWiki/Specials/NewEntitySchema.php#62. I guess a check for edit could be added but that's quite an edge case. Probably a bunch of other situations in MediaWiki where a user permission is checked that "depends" on another but the "prerequisite" permission isn't checked because that type of configuration is unsual.