If un-audited packages with large numbers of dependencies participate in the build process, it becomes hard to guarantee the security or stability of the final output.

@Lydia_Pintscher - We've tentatively scheduled this review for our 4th quarter, which began April 1st and will continue until June 30th, 2021. We should have this review completed by the end of this quarter at the latest. Please feel free to let us know if you have any additional questions or feel free to review our current security readiness reviews SOP.

This all sounds good and thanks for the above summary! Looking at the related change sets, I see:

1. https://gerrit.wikimedia.org/r/676638 (merged)
2. https://gerrit.wikimedia.org/r/677030 (merged)
3. https://gerrit.wikimedia.org/r/677039 (+2'd, should be merged soon)
4. https://gerrit.wikimedia.org/r/677037 (active)
5. https://gerrit.wikimedia.org/r/677289 (active)

Once the remaining active patches land, they should address all remaining issues surfaced within the review and reduce the overall risk rating to low. And I'll be happy to resolve this task at that point.

In T279451#6981071, @ssastry wrote:

So, how do we want (a) roll this out into production (b) get this into the security release planned for release this week (c) get this into a parsoid/js security release?

@Reedy, @sbassett your input would be helpful here for (a) and (b) especially.

@bd808 - sounds good, we'll await an update from your team. We'll also plan to keep this in our Q4 column for now, with the assumption that we'll complete the review towards the end of this quarter. If the project gets pushed back to Q1 or Q2, that shouldn't be a problem.

Hey @bd808 - I know you had mentioned on IRC that your team was deciding on whether to pursue another round of new features for Toolhub this quarter or to just freeze the code for a bit. Were you closer to making a decision? The Security-Team tentatively has this review scheduled for this quarter (Q4 2021) but we can bump it out if you decide to pursue more features this quarter. Thanks.

@Volker_E @Jdlrobson - as the ostensible current requesters of this review, is there anything on your or your teams' end blocking this review? The Security-Team would like to attempt to complete this review this quarter (Q4 2021), if possible. Also - this will not be a line-by-line code review of Vue3, but more of a vendor review focused upon higher-level security models and best practices.

In T279451#6977914, @ssastry wrote:

Maybe worth hiding https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/677297/1#message-b9eae79b4f5b009c0aea6c24a01df33204c41406 and arlo's followup comments? Or does it just draw more attention to this?

In T279449#6976975, @matmarex wrote:

How is it possible though that stopforumspam.com is serving two different versions of that file, seemingly randomly? This is definitely not increasing my trust in them. Anyway…

In T279449#6976866, @matmarex wrote:

I disabled the extension on Patchdemo on all existing wikis, and by default for newly created wikis (you can still enable it for testing if you want): https://github.com/MatmaRex/patchdemo/issues/284

Huh, the patch at T270453#6723168 didn't work for me? Anyhow, I made another one:

Re-deployed master patch to wmf.37. Tracking again at T276237.

In T277336#6968559, @bcampbell wrote:

I can take them up on their offer to set up a test environment for us that we can access on their end if that would be useful for you. Would that be part of the vendor review that you mentioned? Thanks.

Hey @Aklapper - I reviewed https://phabricator.wikimedia.org/maniphest/query/advanced/ and the Security-Team related searches all just seem to point to various workboard columns, etc. Any protected tasks within those searches should still be protected. I don't know how or why these searches were added to that left nav, but I'm pretty sure they can be removed if they are cluttering things up.

Ah, now I remember T265923, and how frustrating Phabricator's complete lack of collective bot ownership is. I suppose the best we can do is have @Reedy grab the api token and keep it safe within our team vault.

In T279140#6968315, @sguebo_WMF wrote:

Nice catch! I am using a token linked to my account. I'd be grateful if I could be given the relevant bot's credentials and added as a maintainer. Let me know if there's anything I need to do for that.

In T279140#6968184, @sguebo_WMF wrote:

I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.

In T279140#6968080, @sguebo_WMF wrote:

Honestly, I just erred on the side of caution and made it non-public from the beginning. I'm glad to make it public if there are not strong objections.

A few thoughts:

1. Is there a reason this task can't be public? Some of the relevant data concerning this project might be sensitive, but Phabricator should keep that information secure from public audiences. For example, if I reference a protected security bug (T268377), Phabricator should hide that effectively within a public view.
2. The Vuln- tags should be relatively up-to-date, though there may be a few we'd want to add and some could potentially have their descriptions updated.
3. Regarding the technical stack - I'd imagine wmcs would be the likely hosting environment? We do have a couple of existing, security-related cloud instances (see here) and there are at least a couple (1. 2) of security-related toolforge projects.
4. I would imagine for this dashboard to offer the most value, it would need to be able to robustly filter data on a project, team, user, date/time and risk level. Some of that data is available via Phabricator as part of the task, but some (especially team ownership and risk) is not, at least not at the moment.

Security Review Summary - T266513 - 2021-03-30
Last commit reviewed: 8aeaef361d

@AnneT - I'm about 75% complete with the review and should have it completed by tomorrow or this Friday. Apologies for the delay - lots of end-of-quarter items needing attention.

Thanks for investigating and getting this fixed. Unless someone has an issue with exposing a toolforge IP (can't imagine anyone would), we should be able to make this public next week. Thankfully this appears to be a case where something broke and while, technically making things _more_ secure, it introduced a Vuln-DoS for those on various exemption lists for an extended period of time.

In T270713#6944605, @daniel wrote:

What's the status here? Is this fixed in master?

In T266904#6936613, @aaron wrote:

I rebased the patch above. Once this is merged, I can consider this task closed.

@bd808 - Ah, the "wait a few minutes" trick seems to have worked, thanks! I'll add a note to the task description above.

I and one of our vendors are having an issue building and running the docker-based development environment as described within the task description:

$ git clone "https://gerrit.wikimedia.org/r/wikimedia/toolhub"
$ cd toolhub
$ make init

I can get the make init to complete successfully, but when I try to access the web app at http://localhost:8000, I see the following error:

OSError at /
Error reading /srv/app/vue/dist/webpack-stats.json. Are you sure webpack has generated the file and the path is correct?
Request Method:	GET
Request URL:	http://localhost:8000/
Django Version:	2.2.17
Exception Type:	OSError
Exception Value:	
Error reading /srv/app/vue/dist/webpack-stats.json. Are you sure webpack has generated the file and the path is correct?
Exception Location:	/opt/lib/poetry/toolhub-2uZo5AhP-py3.7/lib/python3.7/site-packages/webpack_loader/loader.py in load_assets, line 31
Python Executable:	/opt/lib/poetry/toolhub-2uZo5AhP-py3.7/bin/python3
Python Version:	3.7.3
Python Path:	
['/srv/app',
 '/usr/lib/python37.zip',
 '/usr/lib/python3.7',
 '/usr/lib/python3.7/lib-dynload',
 '/opt/lib/poetry/toolhub-2uZo5AhP-py3.7/lib/python3.7/site-packages']

Am I missing something here? Some additional env config or build steps maybe? This was on MacOS Mojave 10.14.6 with Docker Engine v20.10.5.

In T277690#6939438, @CBogen wrote:

Nevermind, I thought this was a different task, sorry about that!

Backlogged and stalled to await completion of review template.

In T278014#6935629, @Grunny wrote:

Thanks, @sbassett ! Just for my reference on if I find any more of these in core or WMF deployed extensions, is it OK to push straight to Gerrit, and I assume we'd still want a ticket created for reference?

Thanks again for the report and patch. Making this public and pushing through gerrit as low-risk.

Thanks again for the report and patch. Making this public and pushing through gerrit as low-risk.

In T277336#6927071, @bcampbell wrote:

@sbassett Estimated deployment date is end of fiscal year. Is that a realistic goal for your team? Per my request, New Vector enabled the encryption tool on one Slack channel bridged to Element, #matrix-encryption-test, but I don't have any visibility into the backend. Would server logs suffice or do you need some sort of real-time access to the bridge to see what's going on?

In T277009#6928372, @IN wrote:

Is this mission over now?

In T274158#6924307, @Daimona wrote:

@sbassett Could you please make this public? Seems like I can't.

Update: I still plan to complete this security readiness review by the end of this quarter, but it might not be completed until quite literally the end of this quarter.