ecdsa-sha2-nistp256 are now accepted.

Change #1071123 merged by Slyngshede:

[operations/puppet@production] P:idm: Add ecdsa-sha2-nistp256 to allowed key types.

https://gerrit.wikimedia.org/r/1071123

Change #1071126 merged by jenkins-bot:

[operations/software/bitu-ldap@master] Git: Add missing .gitreview file.

https://gerrit.wikimedia.org/r/1071126

Change #1071126 had a related patch set uploaded (by Slyngshede; author: Slyngshede):

[operations/software/bitu-ldap@master] Git: Add missing .gitreview file.

https://gerrit.wikimedia.org/r/1071126

Change #1071123 had a related patch set uploaded (by Slyngshede; author: Slyngshede):

[operations/puppet@production] P:idm: Add ecdsa-sha2-nistp256 to allowed key types.

https://gerrit.wikimedia.org/r/1071123

This is still a problem. It seems like logging in to Bitu will set your email in LDAP to whatever your email was when you last logged in to that Bitu instance. Combine that with only logging in to idm-test very infrequently, and you'll have a very old email get activated again.

Change #1060092 merged by jenkins-bot:

[operations/software/bitu@master] Wikimedia: New management command for blocking users in systems.

https://gerrit.wikimedia.org/r/1060092

Thank you for reporting. I think I have some idea as to why the key updated failed, so I'll try to add a test case and see if we can replicate the problem and get it fixed.

In T372581#10072020, @SLyngshede-WMF wrote:

@Meno25 I manually updated your SSH key to the eddsa-key-20240812, the old key has been removed. I've also deleted the cached copies found in Bitu (idm.wikimedia.org). The new key "should" import correctly next time you access the SSH key section there.

Please test if you can login to Toolforge.

@Meno25 I manually updated your SSH key to the eddsa-key-20240812, the old key has been removed. I've also deleted the cached copies found in Bitu (idm.wikimedia.org). The new key "should" import correctly next time you access the SSH key section there.

In T372581#10071994, @SLyngshede-WMF wrote:

Hi, could you do a quick test for me? We had another user with a similar issue, but have yet to receive feedback regarding the fix.

On https://idm-test.wikimedia.org there's a version where the SSH key management have been reworked to handle an issue that seems really similar to yours. Could you try to login there and see if you can activate your key?

Hi, could you do a quick test for me? We had another user with a similar issue, but have yet to receive feedback regarding the fix.

Thank you for a very good bug report, it's appreciated

I've uploaded 0.11.0 to Debian unstable.

mwclient 0.11.0 is now released with this fixed on that side. It also comes with four years of other changes, so please test carefully before deploying :)

In T371977#10054698, @DavidBrooks wrote:

To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.

In T371977#10049711, @LucasWerkmeister wrote:

In T371977#10049550, @bd808 wrote:

In "fun" news, the wmfkeystoneauth and Bitu usage of mwclient is via the python3-mwclient Debian package, so it looks like we will probably need to build and host a .deb for the updated library when it is available.

If we’re going to be reinstating the writeapi removal in production soon-ish, I would guess that other users of the Debian package would also want a fixed version of the library so they don’t get an error when talking to Wikimedia wikis? (Easier said than done, of course. And I don’t know how many third-party users the Debian package actually has – I couldn’t find any other packages depending on it, at least, though that might just be me operating apt wrong.)

To the comment on breaking-or-not siteinfo, please note that the AWB break (now fixed) was due to the flag removed from userinfo. That may come to the same thing; I don't know the internals.

mwclient-side fix is merged and I intend to do a new mwclient release tomorrow, if nothing else comes up, and none of the other maintainers can think of a reason why not.

In T371977#10049882, @Krinkle wrote:

I specifically amended https://gerrit.wikimedia.org/r/c/mediawiki/core/+/392542, which removed the "writeapi" feature to not break the stable API for "siteinfo", by leaving this behind as constant and non-deprecated boolean field.

The AWB breakage is specifically: format=xml&action=query with a body &meta=userinfo&uiprop=blockinfo|hasmsg|groups|rights returns a rights element that no longer includes <r>writeapi</r> (English Wikipedia)

In T371977#10048477, @LucasWerkmeister wrote:

In T371977#10048450, @LucasWerkmeister wrote:

however, AutoWikiBrowser (AWB) also checks writeapi.

Eh… looking closer, it seems to check the writeapi right, not the siteinfo response member. So it’s not gonna be directly broken in the same way, I guess. Let’s untag them again.

"I told you so".

In T371977#10049711, @LucasWerkmeister wrote:

If we’re going to be reinstating the writeapi removal in production soon-ish, I would guess that other users of the Debian package would also want a fixed version of the library so they don’t get an error when talking to Wikimedia wikis? (Easier said than done, of course. And I don’t know how many third-party users the Debian package actually has – I couldn’t find any other packages depending on it, at least, though that might just be me operating apt wrong.)

In T371977#10049550, @bd808 wrote:

In "fun" news, the wmfkeystoneauth and Bitu usage of mwclient is via the python3-mwclient Debian package, so it looks like we will probably need to build and host a .deb for the updated library when it is available.

In T371977#10048887, @brennen wrote:

Change #1060468 had a related patch set uploaded (by BryanDavis; author: Lucas Werkmeister)

I'll deploy the above shortly.