T384232: QA for SUL3 on testwikis has a checklist for testing the auth stack that can be reused.

On an aside, would be great to get T373388: Merge CentralAuth locks into GlobalBlocking done and reduce the feature duplication various kinds of admin interfaces require.

See also T387860: Clean up SUL3 global opt-in flag.

We'll need to wrap up T376021: Migrate WebAuthn on Wikimedia wikis to central domain first as it's using that feature. And probably add some logging just in case some gadget etc. uses it.

If we are backporting the core change, maybe there should be an email about it? It's a UX improvement but it's also a significant change in a key security feature, so I think site admins should get some sort of warning.

In T402206#11105660, @Jgiannelos wrote:

Would it make sense to have a deployment of rest gateway in deployment-prep to replicate the same functionality ?

That's a scary error. I guess an existing session is somehow being reused in ApiTestCase::doApiRequest()?

We should test current PHP versions and possibly upstream this.

In T261260#6500683, @Tgr wrote:

FWIW this was fixed at some point in PHP (could not reproduce it with PHP 8 beta).

In T401771#11087181, @JJMC89 wrote:

providing MW users navigation instructions on changing their password will also be more complicated since you must know if the extension is installed on their wiki.

I think we can call this done.

The patches are merged, and I added the code snippet to https://www.mediawiki.org/wiki/InstantCommons#Temporary_solution. I think we are done here.

Fatal error: Uncaught Error: Class "MediaWiki\Http\Telemetry" not found in /srv/mediawiki/php-master/includes/Request/HeaderCallback.php:67

But just to be sure, you could check the normal CI pipeline: create a patch where you change the default value of $wgPHPSessionHandling to disable, label it as a test patch (we usually prefix the commit message with something like [DNM] or [POC]), create an empty CentralAuth patch that depends on it (I think CentralAuth is the only Wikimedia extension that heavily interacts with session handling), upload them to Gerrit and see if they pass CI.

Yeah, my bad. I actually saw the error in warn mode, not disable mode:

1) MediaWiki\Tests\Session\SessionBackendTest::testResetIdOfGlobalSession
Use of $_SESSION was deprecated in MediaWiki 1.27. [Called from session_write_close in (internal function)]

Could also limit allowing a larger subnet to the case when the user has used several different /64s in the last three months.

Updated T400881#11072676 and the patch to put MediaWiki first.

Yeah that works as a one-off solution. Would be nice to have something more systematic though. JS editing isn't the only action where we'll have this problem.

@EMill-WMF will decide how to handle those users, based on data from {T401742}.

I think the problem is that the session cookie lasts longer than the LoginNotify cookie, so (unless the user manually logs out etc) it won't actually help with the next login. I filed T402089: Make LoginNotify cookie expiry longer than login cookie expiry (with "remember me") about that.

The new error message to use, per @EMill-WMF:

This email service is not supported. Please choose another email provider.

@Aqurs1 thank you for your patience! The account creation was blocked by a secret filter that was set up during a past attack (private task for reference: {T163756}), but a part of the filter ended up quite generic: it disallowed some email providers, including the one used in this login attempt. We'll fix the filter to provide a non-misleading reason.

@Joe which format do you think would be more useful?

ForeignAPIRepo/2.1 (https://example.org) MediaWiki/1.45.0

or

MediaWiki/1.45.0 (https://example.org) ForeignAPIRepo/2.1

I don't know enough about mailservers to have an opinion on the options (other than that (1) sounds very painful since all we'd get is an integer), but I wouldn't worry much about logging email addresses - they are logged in other parts of the call stack anyway.

In T399742#11037889, @Tgr wrote:

We could either put it in WikimediaEvents (not a great place but the rest of the Wikimedia-specific EmailAuth logic is already there), or make it non-Wikimedia-specific (ie. do not hardcode Zendesk).

I think what we should do is:

• Document in the clientlogin and createaccount APIs that the set of authentication request objects returned by the API / the set of dynamic parameters are not subject to the API stability policy (we'll make a best effort to not break things unnecessarily but reserve the ability to make sudden changes in case of security incidents etc), you should either build your app in a fully generic way or be aware that it might break.
• For clientlogin, explain/link to alternatives (a bit tricky because it will depend on whether the wiki has OAuth installed but oh well).
• Make the API docs for the various AuthenticationRequest objects explicitly say how to respond to the request ("respond by submitting a token dynamic parameter with the emailed verification code" etc).

In T348388#11072365, @Grey_ghost wrote:

When I log in on Wikipedia or Wikisource on my computer with Firefox, I'm only logged in to Wikipedia or Wikisource.

So far:
exit code 74 (EX_IOERR): 72
exit code 65 (EX_DATAERR): 7
exit code 64 (EX_USAGE): 1

(This doesn't add a referer, which would be a lot more complicated. The patch does add it for future versions. Although not sure how useful it is since it just duplicates the URL from the UA.)

LocalSettings code snippet that in theory works going back to 1.34 (although I haven't tested it on old versions):

$wgUseInstantCommons = false;
$wgForeignFileRepos[] = [
	'class' => ForeignAPIRepoWithFixedUA::class,
	'name' => 'wikimediacommons',
	'apibase' => 'https://commons.wikimedia.org/w/api.php',
	'url' => 'https://upload.wikimedia.org/wikipedia/commons',
	'thumbUrl' => 'https://upload.wikimedia.org/wikipedia/commons/thumb',
	'hashLevels' => 2,
	'transformVia404' => true,
	'fetchDescription' => true,
	'descriptionCacheExpiry' => 43200,
	'apiThumbCacheExpiry' => 0,
];

We could make sure all CentralAuthUser calls are noop when the username is invalid, and then relax the restrictions for getInstanceByName() etc.

In T399648#11050152, @Tgr wrote:

Since the selection of the default happens in OATHAuth but passkeys are handled in WebAuthn, we'll need a hook for this.

A shortcoming of MediaWiki is that there is no separate admin interface that could be access-controlled more harshly, so anything that's implemented as a special page will be subject to the usual XSS etc. concerns.

Which test do you mean? At a glance, I don't see anything destructor-related in SessionBackendTest.
In general, if the test checks some behavior that's still relevant after the refactoring, it should ideally be kept, otherwise not.

Seems to be working:
Could not send confirmation email: Sendmail exited with non-zero exit code 74
Thanks a lot @jhathaway and @Scott_French for fixing the error reporting issue!

No, the script doesn't try to copy client hints. It does try to copy IPs, it just (reportedly) doesn't always work.

In T400249#11059388, @matmarex wrote:

there are no __destruct calls logged as yet

If it works as intended, I think the only change is Logstash error messages (link) getting more informative.

Thanks! We are definitely interested. By monitoring do you just mean checking if this error becomes less frequent / the error message becomes more useful (can do) or testing email sending after the deployment (can do as well if you ping me)?

Objects with a destructor are garbage collected as soon as nothing references them anymore (not sure PHP actually guarantees this, but seems to hold in practice), and the most likely way a reference survives the end of a test is via the User -> Request -> Session reference chain. So resetting that during teardown seems like the simplest fix, although it only treats the symptom.

So basically we need a ForeignAPIRepo subclass that overrides httpGet() with something along the lines of

$version = MW_VERSION;
$contact = Title::newMainPage()->getCanonicalUrl(); // or use $wgEmergencyContact?
$options['userAgent'] = "InstantCommons MediaWiki/$version ($contact)";
return parent::httpGet( $url, $timeout, $options, $mtime);

There is no way to declaratively add arbitrary headers, so if we really need a referer, that will be more complex.

I don't think MW-Vagrant meaningfully pins a Vagrant version, it's up to the host machine. I have Vagrant 2.4.3 (which is about six months old) and haven't encountered any problems related to the Vagrant version. Not sure what's the relationship between the vagrant gem version and the actual Vagrant version, but we can probably just bump it. (The last FLOSS licenced version is 2.3.7 so it would make sense to standardize on that.)

I think we should fix this by the time we switch to PHP 8.3. It would be nice to move to library versions which were tested on that version. At least for lcobucci/jwt (which is pinned to an old version because the old version of oauth-server requires that) that's not the case today. (We can fix that without unforking, by just merging in some upstream changes, but I'm not sure it would be less effort, and we'd just be rolling the ball forward.)

MediaWiki-Platform-Team will pick up the core part of this. Note that the soonest a change to the InstantCommons code could make a difference is after the next MediaWiki release (so in about 3 months). Many sites will only upgrade when the next LTS version is released (in about 15 months).

T399057: Introduce allowlists into the CDN (text) filtering has some discussion of planned rate limiting classes.

When the images are hotlinked (but the downstream wiki still needs to fetch metadata), adding a username would reveal IP / username combinations to the upstream wiki via timing correlations. Can't violate privacy much more than that.

Search for the relevant libraries. Turns out firebase/php-jwt is used in ContentTranslation (for authenticating with cxserver) and CheckUser (for paging-related URL parameters, to prevent data leak).

The dashboard for the session write logs is here.

That's fair. Let us know if we can help something (e.g. an IP throttling exemption).

That sounds like an error in the job runner rather than the job? The job was scheduled, the status was set to In progress, but then the job runner crashed and never actually executed the job?

Well, more specifically, it would prevent storing recovery codes via one-way hashes. Encrypting them would still be a meaningful security improvement.

This would prevent the recovery-codes part of T145915: OATHAuth OTP shouldn't be stored in cleartext in the DB.

Probably blocked on T232336: Separate recovery codes into a separate 2FA module.

Base56 and base58 are some common ways to generate characters which are hard to mistake for each other. We could use the uppercase-only version of one of those.

Similar older task: T332385: Improve descriptions for our 2FA methods in 2FA management page

Replaced "FIDO" with WebAuthn - I think the intent was the same but FIDO is less well-specified. Let me know if I misunderstood.