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.
Mon, Jun 21
Thu, Jun 17
Tue, Jun 15
Mon, Jun 14
Fri, Jun 11
Thu, Jun 10
Wed, Jun 9
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.
Tue, Jun 8
Mon, Jun 7
Thu, Jun 3
Wed, Jun 2
Ok, I'm going to make this task public since I believe the serious issues (XSSes) have been sufficiently addressed for now.
Tue, Jun 1
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.
@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.
Thu, May 27
Wed, May 26
Tue, May 25
Mon, May 24
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.
May 21 2021
May 18 2021
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;
$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:
May 17 2021
@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?