Per the issues link on https://petscan.wmflabs.org/, petscan issues should be reported at https://github.com/magnusmanske/petscan_rs/issues and not here.

Do you have any (even rough) estimates of when the new system using loginwiki would be ready to be used? I feel like if we're going to mass-message people about this it would be nice to have anything more than "sometime hopefully relatively soon".

I backported this to 1.43.0-wmf.2 so this is now fixed on Wikimedia sites. Leaving the task open until the backport issue to REL1_42 issue is resolved so this stays visible in the MW-1.42-release board.

The current version at least seems to work in practice good enough on my PHP 8.2 dev wiki and T325358: Include newer web-auth/webauthn-lib which supports php8.2 (needs newer fgrosse/phpasn1) should have fixed it in CI so I'm not sure why this is failing now.

I scheduled this for Saturday at 14:00.

Done for the mediawiki group.

In T363548#9747981, @RoySmith wrote:

The patch description describes a bug in persist() and how it is being replaced by updateKey() but the old code is still in place because of a dependency from WebAuthn. Does this mean that there still exists a different scenario that exposes this problem when the buggy code is invoked by WebAuthn?

This seems like a regression from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OATHAuth/+/964988 - using a scratch token updates the key data to mark that as used and the not-great implementation of OATHUserRepository::persist() gives all keys new IDs means that the removeKey call in TOTPDisableForm won't find the key to delete.

I've been looking at this error recently:

Apr 25 12:51:08 cloudvirt2001-dev nova-compute[2572868]: 2024-04-25 12:51:08.870 2572868 ERROR ovsdbapp.backend.ovs_idl.transaction [-] OVSDB Error: {"details":"cannot delete QoS row 4f1bdbb2-2063-4789-9603-b53982670743 because of 1 remaining reference(s)","error":"referential integrity violation"}

Those are running in containers, and the user does exist in the container:

taavi@cloudweb1004 ~ $ sudo docker exec -it striker.service id 900
uid=900(runuser) gid=900(runuser) groups=900(runuser)

Is debdeploy not handling that correctly?

The weight configured for php-parallel-lint is low enough that LibUp will only push that when there's something else to update with it.

Since /data/project is a symbolic link to /mnt/nfs/labstore-secondary-tools-project on Toolforge, some tools such as pnpm will write /mnt/nfs/labstore-secondary-tools-project instead of /data/project to the file, so that it cannot be executed in the container.

Which database is the query running against? fawiki? And are you running it on the analytics or web replicas?

In T363057#9738950, @Townie wrote:

I have corrected the logo in a new file. Could you please deploy this fixed file? Thanks a ton!

You found what I did a few moments ago :-)

01:21:54 <taavi> uh, does https://meta.wikimedia.org/wiki/Special:CentralAuth/Taavi give a DBQueryError to anyone else?
01:22:09 <taavi> ah
01:22:10 <taavi> Wikimedia\Rdbms\DBQueryError: Error 1049: Unknown database 'kuswiki'
01:22:26 <taavi> so I created an account via mwdebug, and then turned it off, so now Special:CA fails until the patch is live everywhere
01:23:29 <zabe> yeah, it should no longer appear as soon as the patch is live

This task does not seem to have anything to do with email handling internals in MediaWiki?

Those would be issues in the SVG files provided (e.g. if I open the original file for https://commons.wikimedia.org/wiki/File:Text_logo_Viquip%C3%A8dia_750000.svg in a new tab, the text is clipped off). I can either deploy fixed files if those are uploaded to commons or revert back to the original logo.

Please email ca@wikimedia.org with the details.

Password reset have been disabled for a few months now, email addresses since I deployed that patch last week, and I just sent https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1023432 to disable password changes while logged in. After that we have SSH key changes, and T359820: Add developer account (un)blocking support to Bitu (which I forgot about earlier) as the only remaining functionality that writes anything to LDAP - there isn't anything in the login process that should need write access.

The logo change is now live (as of about an hour and a half ago, forgot to comment here!). I set myself a reminder for May 8th to revert it back.

In T362872#9734678, @aborrero wrote:

In both cases, they don't mention anything about mutation. I assume this means that they cannot backfill (backmutate?) resouces that made it to the system before the policy was updated.

B: Fishbowl wiki hosted on wikikube, accounts in ldap. This option could be a final state OR a temporary state on the way to the SUL option.
Con (long-term): Allowing r/w ldap access from wikitech/wikikube may continue to introduce surprising edge cases for product maintenance.

This should be fixed on the next run.

Turns out that's a bug with the output parsing if the run crashes early enough. Now fixed with https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/39.