This is now merged into the master, 1.43, and 1.44 branches. I'm marking this as Resolved, but feel free to reopen or create a new task if there are additional issues.

Thank you for the bug report and the patch! It looks good.

Thank you for the patch!

Thank you! It never hurts to have a reminder of the policies.

I had to do some digging to recall the sequence of events. Here's the task that gave me +2 on core: T185440. That was actually after I became staff. Prior to that, I had +2 on a number of other repos, but not core, although I had contributed to core.

Thank you all for the support!

I fixed the location of the comment in the version history to 7.4.0 from 7.3.0, since that is where the change happened.

Hmm, I thought this commit as part of 7.3.0 introduced the problem?

I fixed the location of the comment in the version history to 7.4.0 from 7.3.0, since that is where the change happened.

The basic issue is extension version management, especially with respect to patches that bump the MediaWiki requirement. In my opinion, those should at minimum do a minor version bump to the extension version. In this case, the patch to change the MediaWiki requirement to MW 1.40 should have bumped the extension version to 7.5.0. However, such patches are often submitted and merged by developers other than the extension maintainer, and there are no universal rules for extension versioning to guide them. I've started to comment on those patches with that guidance when I see them, but I clearly missed noting that this patch bumped the MediaWiki requirement (even though I clearly saw the patch and back ported it to 1.43). I do think that establishing some norms for extension versioning would be helpful.

I will add the version bump. As a secure software engineering principle, it is important for a site maintainer to be able to easily confirm that they are using a version of the code that has a vulnerability patched.

Please also do a version bump to 6.2.1 in extension.json in all patched branches that did not get a MW version bump and a version bump to 6.3.0 in all branches that got a MW version bump from 1.39.0 to 1.40.0. Thank you!

I bumped the extension version to 7.5.0 in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PluggableAuth/+/1124093. I'm closing this as invalid, since I believe the issue was using incompatible extension versions.

I bumped the version number, since this introduces new behavior.

My guess is that you updated PluggableAuth unintentionally when upgrading MediaWiki from 1.39.11 to 1.39.12. This patch to PluggableAuth introduced namespacing for the class in question. The patch should have bumped the extension version, but did not, so, the extension will still report its version to be 7.4.0. I'm puzzled, however, at the fact that it did not report that the extension is incompatible with release 1.39, since the patch updated the core MediaWiki version requirement to 1.40. For use with 1.39, you should pull the extension from the REL1_39 branch.

Thank you for contributing this patch.

I'm glad you found the issue. Thank you for posting the solution here.

I would appreciate a bit more information on reproducing this issue. The original report states:

T378904#10552156 appears to be a separate issue affecting only Postgres. See T382116.

This was erroneously closed as a duplication of T378904. It appears to be a separate issue affecting only Postgres. See T378904#10552156.

I notice you have set

Thank you very much for submitting this task and the patch, @BlankEclair.

Reopening since the patch was only applied to the Release 1.42 branch. Was it fixed in another patch on master and the Release 1.43 branch?

I concur with this request. Please add @MarkAHershberger and @Osnard to the extension-CommentStreams group in gerrit and remove Jason Ji. Thank you.

PluggableAuthService::deauthenticate takes a string parameter. It uses the UserFactory to get a User object (which is a UserIdentity) passing in the string. The resulting UserIdentity is passed to PluggableAuthPlugin::deauthenticate. I'm not sure why VS Code is unhappy.

Those would all be great improvements over directly hacking the config.php file. As I recall, modifications were also necessary to a metadata.php file to include the server cert.

I agree in theory, but the aspect that makes this problematic is that once installed, config changes need to be made to the SimpleSAMLphp code, which would mean editing code in the vendor directory. That seems like a bad idea as well. Unless there have been changes made to SimpleSAMLphp since I last looked at it to allow some other method of configuration?

Thank you for reporting this and thank you for your patience. I'm just getting a chance to look at this now. It turns out that this bug is caused by the issue reported in T378904. It would help if you could test https://gerrit.wikimedia.org/r/1086541, the patch linked to that task, to verify that it fixes the issue for you. Thank you.

Thank you, @matmarex!!