Just quickly running semgrep supply-chain against these codebases, it found that wikimedia/service-runner@master had two dependency vulnerabilities with undetermined reachability and that wikimedia/service-template-node@master had two dependency vulnerabilities with undetermined reachability and one with confirmed reachability.

I'd also note that the Vega dependency was the primary reason we disabled ext:Graph (twice). And that while Vega's expressions layer has since been hardened, it likely still poses more risk for our use-cases than other options.

@aude service-template-node is indeed quite dated and fairly unmaintained. And it would be difficult to recommend it for new projects, from a security perspective. Sadly, I don't think there has been consensus on a replacement option. It would be nice to consolidate around something as having a dozen new frameworks that essentially do the same thing is not ideal. You might want to reach out to @tchin as they have been working on at least one replacement option (T360924, T362774, et al).

Hey @Tgr - I'd like to set up an initial threat-modeling/concept-review session (or two) for this work with you and any other relevant folks, this quarter. Are there any other technical folks that you're aware of who would likely be helpful during or interested in participating in such exercises? Thanks.

I've confirmed this user has Phab MFA enabled:

In T365525#10005016, @MusikAnimal wrote:

Yes, we could use a different branch but for Gerrit I think that means we have to rely on relation chains and just not merge, right? Indeed that would seriously hamper development. So I think we will go with a feature flag -- but I believe that is going to be necessary anyway because in order to do the security review, we need the extension deployed to the Beta cluster, but also simultaneously not deploy to production.

Hey all - just back from jury duty. I don't have any major concerns with this and am inclined to rate it a low risk, unless @acooper has any additional concerns.

One minor note about this release: T363773#9971646

Anything here preventing this task from being made public? I'm not seeing anything but wanted to double-check.

Hey @mpopov - per the minutes from our recent quarterly review planning session, @acooper was going to follow up on this and a couple other review requests as it relates to acceptance and scheduling.

I assume we can make this task public now, since the fixes were handled publicly in gerrit and are now merged? This issue will be reannounced within the next supplemental security release, due out around September 30th, 2024.

In T365525#9988592, @MusikAnimal wrote:

My question for you: If we (i.e. my manager) agree to accept all security risks, how likely if at all would it be to ship the extension with just translations, then we slowly add code to it over time? This would make the transition considerably easier, and allow us to address some issues we have now such as T370230: Migrate translations to Community Requests. When we have enough code moved over for the extension to run standalone, we can ask for a proper security review. Until then, we could have all code (other than the translations) behind a feature flag, which we will not enable until the security review is complete. How does that sound? I know this is highly unusual but I thought it was at least worth inquiring :)

In T367440#9990781, @mmartorana wrote:

As for issue number 1, I couldn't find an effective solution. One option could be to display only high and critical vulnerabilities. However, I prefer keeping the full table in its raw format. What are your thoughts?

@Mstyles - I'd like to attend the meeting if it works with my schedule. Can you send me an invite?

In T303433#9945363, @kostajh wrote:

• Enable a global abuse filter for showing a CAPTCHA on all projects
• Create two local abuse filters on enwiki and jawiki

Which doesn't sound that bad. Just trying to avoid the need to build new software for this, if it can be easily solved with something we've already got.

In T303433#9945321, @kostajh wrote:

I see, thanks. The example patch in the task description is enabling CAPTCHA for just one wiki. Are there circumstances where we want to set $wmgEmergencyCaptcha across all projects without involving SREs? If not, then the AbuseFilter + showcaptcha consequence seems like it would suffice for the use case described in this task.

In T367205#9941551, @SDeckelmann-WMF wrote:

Hey! I get the emails, so no relaying required :)

And, done.

In T367205#9938963, @Aklapper wrote:

Per Security's SOP, "Set up Two-Factor Authentication for your Phabricator account under Settings → Authentication → Multi-Factor Auth" is required.
This has not happened thus reopening this ticket.

Write-up of some of this quarter's work is here: T335892#9936225

Hey all -

I've gone ahead and made T366554 public as, at worst, I think it's a low-risk issue.

In T355161#9919029, @Iniquity wrote:

@sbassett Hi! Are you able to check the extension next quarter?

Example of a template keeping track of cumulative bash error codes: https://gitlab.wikimedia.org/repos/security/gitlab-ci-security-templates/-/blob/7102fe1332c371f52d5e0800701d60a81a7e104c/php-security-checker/php-security-checker-ci.yml#L24-L70

@Chocapikk1337 - you've now been added to our hall of fame: https://security.wikimedia.org/hall-of-fame/

Stalled on completion date. If that's not proper, we can set the status to something else. The Security-Team also has a calendar invite set for this next year.

In T337305#9916137, @Grunny wrote:

Was I caught up in this cleanup by chance @sbassett? I noticed my access seems to be gone. If so, could I be readded? I use the access for Fandom for pre-release access and checking for any crossover with our bug bounty program we run.

In T340189#9911190, @Ladsgroup wrote:

Given that more than ninety days have passed since this bug got fixed, we don't have any logs of who might have accessed the private files. I suggest closing this and filing follow ups for fixing setZone and other issues?

In T364302#9908817, @Bugreporter wrote:

Note: github.com/wikimedia is not the only place that Wikimedia codes are located - see https://www.mediawiki.org/wiki/Gerrit/GitHub#Other_GitHub_organizations. Some are semi-official, such as toolforge related repos which may be co-maintained by WMF and volunteers. There are a number of WMDE repos too which is used in production.

Security Review Summary - T360070 - 2024-06-17
Last commit reviewed: be78eb0148

For active, I was just meaning "not archived", per gerrit's definition.

Quick update on this: I plan to post the review next Monday or Tuesday (2024-06-16 or 2024-06-18). I haven't really found anything concerning at all.

Ok, if we can keep it simple but all-encompassing, then I'd probably go with something like: "Any active code repository hosted under gerrit.wikimedia.org, gitlab.wikimedia.org or github.com/wikimedia that is not a fork of an upstream project or otherwise unmaintained by the WMF or Wikimedia Community".

In T335892#9891420, @sguebo_WMF wrote:

@sbassett, as a next step I'd probably use your idea of detecting TPR use by searching for things like import, importScript, mw.loader.load, xmlhttprequest, jquery.load, url for css, et al. Glad to hear if you think there's a cleaner way to avoid false positives.

In T364302#9893759, @Mstyles wrote:

"Vulnerabilities in MediaWiki core (https://gerrit.wikimedia.org/r/admin/repos/mediawiki/core,general), skins and extensions hosted on gerrit.wikimedia.org, gitlab.wikimedia.org or github.com/wikimedia along with wikimedia microservices hosted here: https://gerrit.wikimedia.org/r/admin/repos/q/filter:mediawiki/services"

At the very least I think we'd also want to include MediaWiki skins (as opposed to just extensions) since WMF folks are largely the maintainers of Vector et al. Personally, I think we'd also want to include things like the various Wikimedia microservices that support some production-deployed MediaWiki extensions, etc. as we are pretty much the sole maintainers of those. Beyond that, we do write a lot of additional, proprietary Wikimedia code (SRE, Data Engineering, etc.) but we've never traditionally requested many CVEs for many of those codebases, so maybe we aren't worried about those as much. I'd also prefer to at least have the ability to issue CVEs for non-Wikimedia-deployed extensions and skins, as many of those comprise the quarterly supplemental security releases that we still manage.