Great, I think this is the final scope: "Any code repository hosted under gerrit.wikimedia.org, gitlab.wikimedia.org or github.com/wikimedia that is not archived or a fork of an upstream project or otherwise unmaintained by the WMF or Wikimedia Community"

I like that, but I do think that we might either have to remove active or define what that means. Do we mean active in the last 6 months? Last year?

There needs to be clarity on what projects we will manage or not. Originally when we started this project we did say Mediawiki core, skins, and extensions, but if you want to open it up that's fine with me. I'm fine to say vulnerabilities in software maintained by the Wikimedia Foundation or something like that.

It can't be a minimal list, it needs to be an exact list of what we will issue CVEs for. I'm only saying this because I met with Mitre, and they want a canonical list of what we will and will not cover. We can also say something like, "Scope The GitLab application, any project hosted on GitLab.com in a public repository, and any vulnerabilities discovered by GitLab that are not in another CNA’s scope" but then that might be more broad than we want. Go has one that says, "Vulnerabilities in software published by the Go Project (including the Go standard library, Go toolchain, and the golang.org modules) and publicly disclosed vulnerabilities in publicly importable packages in the Go ecosystem, unless covered by another CNA’s scope". So we could say something very similar to that.

How about

I met with Mitre today and there are two issues to address before we can have the official onboarding meeting with the whole team.
They wanted to get very clear on the scope and we need to have a proper advisory page.

@Physikerwelt thank you for reporting this. This issue looks like it's referring to CVE-2023-39663 which only affects versions of Mathjax under and including 2.7.9. The current version of Mathjax for WMF production is 3.2.2 so WMF systems are not affected. I'm marking this as resolved, but if you have any other questions or comments, please let us know.

legal approved terms of service in coupa. I'm meeting with Mitre this week to talk about our scope and advisory page. There might need to be some udpates. More to come

@acooper I filled out a coupa request with legal

Mitre responded on May 15, but I was OOO so I filled out the CNA registration form today. I did reach out to legal about the terms of service as well. The next steps are for Mitre to schedule a meeting to discuss the program more. If anyone is interested in the onboarding materials, there is information about the onboarding process and the CNA Rules.

Security Review Summary - T361690 - 2024-15-05
Last commit reviewed: 54d3a6d

@jsn.sherman I'll aim for the end of May for this review, but in case I'm not able to post it, you can go ahead and get the pilot rolling

@jsn.sherman thank for letting me know, is there a deadline that I should know about for the review? If not, I will post mid June.

Supplemental announcement is out!

Subject: MediaWiki Extensions and Skins Security Release Supplement (1.39.7/1.40.3/1.41.1)

@ashley Since MediaWikiChat is not deployed in WMF production, this patch can be pushed through github.

security issue access has been granted

@Samwalton9-WMF this review will be scoped to the extension only, the models will be out of scope for this review. Is it possible that this tool will replace existing auto moderator tools? For the timeline, does that mean the review can start in May? We're planning to do this review this quarter.

It looks like it's not too bad to convert from CycloneDX to SPDX, so even if we decide to go with CycloneDX we can still get the SPDX data if we want it. CycloneDX seems to have more tooling and also provides a license scanner to look at the licenses @Jdforrester-WMF was referencing.

Resolving this ticket as the report has been delivered and reviewed by the team

Team has confirmed that there are no action items from the report

security issue access has been granted.

Report has been released, gone over with the team and subtasks created so I'm resolving this ticket.

The report has been released to team members. Still checking in about any fixes due to the report

@SCampos-WMF thank you, I'll check back

I updated the existing patch to used escaped instead of parsed. If we agree to move forward with this, I can upload this on gerrit so that we can address this issue faster.

pushing the rebased patch to gerrit for the supplemental release: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/1013359

Reassigning to Cleo to figure this out with the privacy team

I did do a review for the Matomo upgrade as well since that was requested. I'm reopening this ticket in case you have any questions.

security issue access granted!

@Aklapper would you be able to update the @priv_eng_sync user so that it points to the email address above? If that's not possible, then I'll go ahead and have that account deleted.

@SGupta-WMF could you please enable Two-Factor Authentication for your Phabricator account under Settings → Authentication → Multi-Factor Auth and read the warning under https://www.mediawiki.org/wiki/Phabricator/Help/Two-factor_Authentication_Resets ?

Security Review Summary - T351657 - Matomo Campaign Plugin- 2024-03-06

email address we want to try: x+1143023741172261@mail.asana.com

@Dreamy_Jazz I'm glad that the patch works. I think adding the hard-coded message once this uploaded is fine. There was an issue with deployment which I wanted to note here: https://phabricator.wikimedia.org/T276237#9598800

In T357760#9553901, @Dreamy_Jazz wrote:

Proposed patch:

T357760.patch4 KBDownload

Note: Due to https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Guidelines_for_creating_patches, this patch has a hardcoded message which is used when the list of subpages is truncated.

Moved the privacy engineering sync to a separate ticket

@sbassett this looks really good! glad it's fast since the other methods were not as fast.

Security issue access has been granted