I kept these as separate patches for the backports so as to (hopefully) make reverting the first patch easier, if and when that's needed. These don't cleanly apply to REL1_35 and REL1_31, mainly due to directory/file name refactoring, but I can work on new patches for those, post them here and then push them up to gerrit for review/merge.
+1 to the updated patch above, I assume that'll go through gerrit once T275669 is public (which I plan to do today, along with the backports). Do we have any idea what other projects this might need to be run on besides loginwiki, testwiki and enwiki?
Wed, Feb 24
+1 to the patches above. I assume Linker::userLink( $row->cul_target_id, $row->cul_target_text ) in LogPager doesn't need a trim because of https://gerrit.wikimedia.org/g/mediawiki/core/+/21ab535b83b97866cb9b79dcede95e8b7c32858f/includes/Linker.php#914. I guess feel free to deploy these unless you want @Reedy or I to do so instead.
Tue, Feb 23
@Aklapper - a number of items from the Security-Team's perspective. For starters: there's no estimated deployment date which is a hard requirement for us to schedule reviews. It also doesn't satisfy a number of requirements for higher priority or status as described within the "What type of project or code triggers this review process?" and "How are these requests prioritized?" sections of the current security readiness review SOP. There are also questions above as to whether this extension would be the best approach for the current indicated problem. Given all of that, this review will have to be very low-priority for the Security-Team. If you'd like to change the task to "Open", I guess that's fine, though it won't really change how the Security-Team currently views this task.
Mon, Feb 22
Pull request created: https://github.com/MatmaRex/patchdemo/pull/241
The first patch (0001-SECURITY-Escape-the-wikitext-of-parse-warning-messag.patch) has been deployed to wmf.31. Logstash seems fine and the issue seems resolved testing the formerly problematic previews on enwiki Wikipedia:Sandbox. I'm going to track this issue on the next security release tracking task, just so we don't forget about it, in case it causes any issues later. @matmarex - it should be fine to push the second patch up to gerrit now, I'll make this task public shortly.
Fri, Feb 19
Thu, Feb 18
I reviewed this task for completeness and PII. Making public now per request from @RhinosF1.
Wed, Feb 17
Some initial thoughts:
- I think the initial standard is: don't. Given the outcomes of the VueJS task force and commitments of various teams at this point, Rollup is likely to be the low-risk, paved-road approach for any JS-related build steps, e.g. T272879 and also a part of SX's current risk mitigation plan at T260236#6825798.
- I'm not saying this is a perfect approach, but requiring human-readable (kinda) webpack artifacts with any relevant gerrit cs with the steps I performed and outlined here should be mostly feasible for now. A couple of questions remain as to 1) how long we plan to support this kind of stuff until we... mandate? migration to Rollup and 2) how similar a manual review process Rollup artifacts might require.
Hey all - thanks for submitting this review request. As discussed a bit with @Jdforrester-WMF, the security readiness review of the WikiLambda extension will be my primary focus/deliverable for Q3 for the Abstract Wikipedia project. The code currently seems to be in a reasonable state of completion for such a review, though as a lot of code for this project is likely to be quite volatile, I imagine this and the related services might undergo a few different reviews depending upon various deltas. Of course I'd like to keep those to a minimum as much as possible. For the forthcoming node services (orchestrator, executor), I'd imagine those to be ready for review sometime in Q4. Since they are based upon the existing (and what we believe to be reasonably-mature) service-template-node code, I'll likely be most concerned with the various measures to best protect against potential vulnerabilities specifically related to the execution of user-submitted code - though it is important to note that any system which allows for such a feature will always be inherently vulnerable, at least from a conceptual standpoint.
Added to Q4 planning column for Q4 review.
Added to Q4 planning column for Q4 review.
Tue, Feb 16
Fri, Feb 12
@Arrbee et al - Great! I'll link the mitigation plan document within the relevant risk registry entry. Hopefully said registry will become a bit cleaner and feature better automation once it is migrated to our new GRC platform (Archer). But for now this is still a very manual process for the Security-Team. The mitigation plan the Language Team has put together looks good (thanks!) though I did want to provide feedback for a few items:
- It would be great if @Reedy and myself could be added to any gerrit change sets which include unminified webpack artifacts and any other relevant JS code as was recently done for WVUI, pre-merge/pre-deployment.
- For any vuln-checking/SAST/etc that may occur in CI/CD for SX and its dependencies, it would be great if those results could be 1) protected somewhere and/or 2) relevant change sets were not merged until any resultant risk was either mitigated (by bumping dependencies to known secure versions) or by formal risk acceptance. I understand the first suggestion is, at best, extremely inconvenient given gerrit and its current configuration.
- I would imagine that SX could leverage T272879, once completed, though I'm not sure what the timeline estimate is for that task.
- A more specific target deployment date.
- An intended production support plan, including any potential Foundation team sponsorship.
- A working test environment, be that in Mediawiki-Docker, a standalone docker, a cloud installation, patchdemo, perhaps even a beta deployment, etc. While we can in theory just manually install the extension against a local copy of mediawiki, it helps us quite a bit to have an existing development environment with potentially real data to test against.
Thu, Feb 11
Wed, Feb 10
Tue, Feb 9
All - I believe there are some fairly significant misunderstanding around items related to:
- How the Security-Team performs various security reviews
- What is included within Security-Team review deliverables
- What the Security-Team will and will not review based upon current resources and priorities
- The concepts of risk assessment and risk ownership as they relate to various Security-Team reviews
- How to best communicate with the Security-Team through our official, documented processes
and likely a few others. We're going to have a few team discussions on some of the comments here with the hope of providing some clarifications to reset certain incorrect expectations and assumptions.
Mon, Feb 8
Could there be a cache-related security issue here?
Resolving for now. The current fix (tx @Reedy) will likely need some adjustment if/when this repo migrates to Gitlab.
Fri, Feb 5
Thu, Feb 4
Wed, Feb 3
@SBisson - Thanks for the update. We're pretty much booked this quarter for reviews (with our new SOP, we're trying to be realistic given current resources and limit the total volume of security reviews to 6 per quarter) so perhaps this could be scheduled for next quarter (cc @Jcross).
Tue, Feb 2
Update: I'm still hopeful to have this review completed by the end of this week (2021-02-05). @Volker_E - thanks for the version bumps, I'll pull those down for the review if they haven't been merged yet. Also - with the webpack build step still being in place, I'm going to rate the overall risk of wvui in its current state as at least medium, which will require managerial/directory acceptance of the risk, per our risk managment policy, as publicly summarized here: T249039#6309061.
Mon, Feb 1
Note: I committed the deletion of the two wmf.28 Wikibase patches under /srv/patches on the deployment server (5578144525) since wmf.28 was rolled back and as noted by gerritbot above, https://gerrit.wikimedia.org/r/658323 and https://gerrit.wikimedia.org/r/658324 were merged.
Update: unfortunately, it looks like the pilot program mentioned above likely will not happen until Q4 2021.
Placing into back orders for now. The Security-Team needs to discuss how useful the continued maintenance of peek is for our project management function.