fake-gitlab-bot: - Initial commit for repo, mostly app structure - https://gitlab.wikimedia.org/repos/security/semgrep-merge-tool/-/merge_requests/1

Just added them to acl*security_releng, which should give them implicit membership within acl*security. Which should be all they need.

In T308659#8037779, @Lucas_Werkmeister_WMDE wrote:

I think we’re done here (but please reopen if the task should still be open for security release process purposes).

In T308659#8036319, @MoritzMuehlenhoff wrote:

This appeared in the CVE feed as https://www.cve.org/CVERecord?id=CVE-2022-34750

Security Review Summary - T302472 - 2022-06-27
Last commit reviewed: 7cf228480a

In T294362#8030286, @kostajh wrote:

@sbassett we are aligned on not wanting this to drag on. That said, I think deploying the config patch to switch to the API would be better to do on Monday, so we have more time to deal with any issues that come up. So I'll plan on that, if that sounds OK to you.

Hey @Lucas_Werkmeister_WMDE - The security team is attempting to get the next supplemental security release (T305209) out within the next week or two, and we were hoping to include this bug. I know there was some discussion above about polishing the two existing security patches a bit more. Would you still prefer to do that or should we try to push what exists now up to gerrit, get them merged so we can remove the patches from production and have something available for the supplemental release? I'd perfer that approach but I'm also fine with waiting and keeping this bug locked down for a while longer, perhaps until next quarter's supplemental security release, but likely not after that.

@kostajh - Sounds good, thanks for the update. A few extra days beyond the deadline is fine. We just don't want that turning into weeks or months, so if the work appears to be heading in that direction due to unknowns, etc, please let us know so that we can recalibrate on the grant. Also - the AppSec team is still planning to complete T304885 by the end of this current quarter, or thereabouts.

Ok, I've made this task public since there isn't really a security issue here. We can leave it open for a while to see if anybody would like to implement the version selection functionality.

In T301389#8011635, @SBisson wrote:

About the various vulnerable or outdated packages, it looks like there's no need to do anything about it now. Let me know if I missed anything.

In T310887#8012730, @Legoktm wrote:

Could you be a bit more specific on which Docker image exactly you're using (by providing a link)? Unfortunately there are at least 2 or 3 different projects that at one point or another could be considered "MediaWiki's official Docker image"

This picked cleanly to all supported releases. If those test fine, I'll plan to merge them and this task can be resolved.

Security Review Summary - T301389 - 2022-06-16
Last commit reviewed: 96c13a2676

I ended up merging the changes to security-api's docker-compose.yml as a convenience. This way a default, named network is established for easier integration with mediawiki-docker or other containerized environments in the future.

In T310535#8009874, @brennen wrote:

@sbassett: With that patch merged, this should take effect once runners are re-registered. I can probably get to that after train.

Testing the link within the description (unauth'd) I'm not even able to generate a timeout error. I'm seeing some higher run times, in the 30 to 40 second range, but at worst, this seems like it may occasionally trigger some low-risk resource exhaustion. I concur that this should be declined for now, unless it can be demonstrated that the action api url in question consistently causes significant resource exhaustion to the point of being a much more significant and viable DoS vector.

In T310718#8009379, @brennen wrote:

Bit slammed at the moment but this probably dupes T310535: GitLab runners: allowed_images patterns need to be loosened to include subdirectories.

So we have a new, interim director of security at this time: @Jcross. I plan to bring this issue to them soon for reconsideration. And hopefully have an answer before T305731 is fully-resolved.

Hey Release-Engineering-Team - guessing the releng path might need to be explicitly allow-listed as well? So: docker-registry.wikimedia.org/releng/*? And maybe docker-registry.wikimedia.org/dev/* as well? Assuming those are images we wish to allow within Gitlab CI.

In T298784#8000642, @Zabe wrote:

@sbassett I see that @Dsharpe has been offboarded. Is there someone else I can ask now?

In T308471#8000544, @Zabe wrote:

But OutputPage::setPageTitle() calls Sanitizer::removeSomeTags, is that not enough?