According to an email that went out logstash access now requires this new process to be followed. Appreciate if this can be handled as a priority as we need it for an ongoing incident.

May need enterprise features enabling for secure enclave and proxy.

For this patch, it's for trial implementation purposes and we will set the trust value threshold for zero so it will essentially not block any users.

Update - confirming with staff members whether this access is still required as they may still be actively doing volunteer work, will confirm back, so pause this request for now please

Talking to @sbassett about how to break this down:
API tracks Repositories which are what we want to scan, Tools and ToolsConfig which is how things like semgrep are defined and called (likely will need to be containerized in some way), Tasks which are combination of a repo/branch/files and running the tool against those which produces a task which is a scan of the code and results

To split this up (discussion between me and @sbassett)

1. Research the existing PHP rulesets that are in semgrep - default rules
2. Research historical vulnerabilities and what would be a good candidate for a new rule - e.g. message API (but in general there's a lot of good coverage there, but would be good to find these issues earlier), permissions layer (however this might be tricky), csrf
3. Review the rules we already contracted semgrep to write - semgrep functions that are potentially ones that can be used incorrect - can we refine which ones are most effective and less false positives, or use as inspiration for more? https://gitlab.wikimedia.org/repos/security/wikimedia-semgrep-rules especially https://gitlab.wikimedia.org/repos/security/wikimedia-semgrep-rules/-/blob/main/php/mw-php-sec-sniff.yaml

I was talking to @kostajh and it seems like StopForumSpam isn't superseded by IPoid because they aren't necessarily the same IPs (although someone would have to verify that), and IPoid isn't yet used for preventing actions although there is an epic for that: https://phabricator.wikimedia.org/T354599

Nothing left to do from my end

We're going to take some more time to understand the potential side effects of this issue and will resume next week.

@Esanders just talking about this with Reedy, we think the fix might be similar to how VisualEditor fixed it but we don't really have the javascript expertise to figure it out. Is there any chance we could get this fixed early Q4?

Now we're working on getting into hcaptcha into production for a trial, this bug is becoming more of a blocker because we'd really like to test it on edits. We aren't going to be ready for another quarter but if this was fixed we could do some more interesting experiments to show how well hcaptcha can protect against spam edits.

Just circling back on Scott's comment that the rate limit isn't configured in production, I chatted with @Reedy and its enabled by default without the config set.

Meeting setup on 22 Jan to discuss this

I responded to all open feedback, waiting to see if we get more comments over the next week (@Jly not sure if you saw this doc?)

Just circling back on this, the plan is still to implement (all the dependencies for) a limited-rollout of hcaptcha on a trial basis in Q3, for a rollout of the trial in Q4 and an assessment of how effective it was.

I changed the langauge and context which is to have an opinion on whether LibUp is not sufficient for security purposes for CI/CD.

We need to do something like this schema: https://schema.wikimedia.org/repositories/secondary/jsonschema/analytics/mediawiki/ip_reputation/score/current.yaml

Is this where the request gets blocked if the score if >x? If so we don't need to do that next quarter.

Can defer this until spoken to the decision science team for advice

We are planning to close this task by end of quarter unless we hear back from someone. We didn't get any information on priority or delivery schedule.

I am following up and seeing whether we can schedule a discussion with the Human Rights team, just a small update.

Confirmed Cleo was removed from security-team@ (I think that must have happened automatically)

Apologies I closed the ticket as I thought you forgot, then realized you were awaiting the sprint review meeting to close it, so put it back!

Document is ready for review: https://docs.google.com/document/d/1lnHCokqeFKL2Ie4LXensQi3Blla2DswO0HJ1p_qAg8c/edit?usp=sharing