Per @MSantos above - setting to lowest, stalled and back ordered for now, until we have a clearer idea on if this library will be used in Wikimedia production and if risk will be accepted or mitigated by the ostensible maintainers.

In T281527#7158003, @Catrope wrote:

There are only release candidates for version 1, which means code is constantly changing and hard to ensure project stability. It would be ideal to make sure once the 1.0 release is available, another follow up security review should be done to ensure there aren't any security issues.

In T284137#7151424, @Seb35 wrote:

Indeed, this task can become public. @Aklapper: could you remove the protection of this task?

Cool, thanks for the update, @Catrope. @Mstyles and I discussed this review today and I believe she plans on posting the report deliverable within the next day or so.

I've been sending supplemental security announcements for about a year and a half now with each quarterly-ish security release of core and bundled extensions/skins. This provides some... eventual visibility and disclosure for security issues related to non-bundled extensions and skins. There's also T101017, which the Security-Team had wanted to generalize to any user interested in such access (and not just the specific user within that task description), though that task has been de-prioritized for now. I would assume that if a general process is ever documented and implemented for T101017, that plus the continued supplemental announcements should likely be a good effort to better our security disclosures for non-bundled extensions and skins, though I think the Security-Team would be open to any other reasonable suggestions.

In T283175#7108004, @ayounsi wrote:

Yep, we can turn it on relatively quickly in an emergency. No monetary cost.

In T283987#7131714, @Aklapper wrote:

There is a text search on mediawiki.org. It lists https://www.mediawiki.org/wiki/Security/SOP/Security_Preview as left to do

Ok, I'm going to make this task public since I believe the serious issues (XSSes) have been sufficiently addressed for now.

Looking at the patched version, it appears that the XSS for the channel param should be fairly well-defended with htmlspecialchars. I might suggest performing the sanitization closer to the point of output (in the html string) but that's more an auditability concern than anything else.

Thanks, @MoritzMuehlenhoff.

@MoritzMuehlenhoff - ok, sounds good. +1 to the patch above, not sure about that Tox CI error though, seems unrelated to the patch. Would you or another SRE be able to puppet deploy that for us? Regarding a larger decommission of the VM - I'd like to self-assign this task and stall it on a date next quarter. If the Security-Team either decides to decommission the VM by then or hasn't made a decisions by then, we can go ahead and decommission it. Does that sound reasonable?

See related decom task: T284090

@Ahecht - are you comfortable if we make this task public now? We'd only want to do that if all of these issues have been satisfactorily addressed.

Making this public for now (largely for transparency and disclosure reasons) as it appears to impact very old versions of MediaWiki which are not being run in Wikimedia production, and should be fairly low-risk.

In T279690#7095168, @Aklapper wrote:

Task subtypes and fields on a form are different things. Set the "Security Issue" subtype, then edit the task itself.

We're going to try to accommodate this review this quarter (Q4 2021) given the visibility and importance of this project. We're going to perform a combination of analyses for this one, with a vendor assessment, a review of Vue's security model and a limited amount of application security analysis.

Update: The Abstract Wikipedia team and Security-Team worked through the vendor scoping doc on Monday, 2021-05-17 (thanks again, all). This document was then sent along to our vendor PM contact that afternoon. I also owe the vendor our Threat Modeling outline doc and Threat Dragon model for review, which I plan to provide them today or tomorrow.

@Daimona - so looking at the gerrit change set, we'd just need to remove that first htmlspecialchars in your opinion? Basically change this:

$link = WikiMap::makeForeignLink( $item['wiki'], $page,
str_replace( '_', ' ', htmlspecialchars( $page ) ) );
// Return only the title if no link can be constructed
return $link === false ? htmlspecialchars( $page ) : $link;

to:

$link = WikiMap::makeForeignLink( $item['wiki'], $page,
str_replace( '_', ' ', $page ) );
// Return only the title if no link can be constructed
return $link === false ? htmlspecialchars( $page ) : $link;

Also - if we don't really need that underscore faux-normalization, then we shouldn't need the third arg at all, per the docblock:

@Reedy - is this still an issue? https://wow.gamepedia.com/index.php?title=/example.org&action=edit&redlink=1 just redirects to https://wowpedia.fandom.com/wiki//example.org for me in Chrome 90.0.4430.85/MacOS 10.14.6.

Calling this resolved (all relevant hardening change sets in gerrit are merged) and making public.

Looks to be completed with the above change sets merged?

Stalling on need to answer questions in T256285#6255281.