Some thoughts:

In T232697#5487002, @Aklapper wrote:

Is there a reason that this task should remain non-public? Duplicate https://phabricator.wikimedia.org/T232704 is also public.

In T227209#5488002, @ssastry wrote:

Thanks! That sounds good. Should I rebase the security branch with latest changes to master?

Given that this still appears to be the most recent spambot attack task, I thought I'd provide a small update here. I wrote some python that generates basic stats on new account creations and whether or not IPs associated with those users (as found within logstash) appear within StopForumSpam's various black lists. Here are some of the results for some of the recent, affected projects (e.g. T227416#5348535 etc):

Update: @Reedy and I are having a look at this and T230140 and should have some reports soon. We're going to timebox to maybe two weeks or so - hopefully that doesn't push back too much on any targeted deployment dates.

Hey @Jdlrobson - I just wanted to check in and see if there had been any updates on your end (re: the current likelihood of using preact) and if you had a chance to chat with the Performance Team about this yet. I still owe you some security best practices around using preact, which I can hopefully provide sometime soon. Thanks.

Per T131207#2164035, it looks like this is how AF does it:

if ( ExtensionRegistry::getInstance()->isLoaded( 'CheckUser' )
      && strpos( $wgAbuseFilterNotifications, 'rc' ) === false
) {
      $rc = $entry->getRecentChange();
      CheckUserHooks::updateCheckUserData( $rc );
}

I'm guessing the relevant place to do something similar in CA is probably in GlobalRenameUser.php around here, since there's a ManualLogEntry there where we could call getRecentChange() as the rename was processed. Or at least this seems the simplest way to do the CU logging piece without getting more advanced as discussed in T131207#2212568.

@Reedy - lol, wasn't commanding, just noting :)

@Reedy Er, REL1_32 still appears un-merged as it needs the 301-checking in dispatch()?

All- @Tchanders' access was approved last week and I guess @Reedy actually added them to the project already. Let us know if anything else is needed.

@Urbanecm - I'm not sure I even have perms to change subtypes, don't know much about that feature to be honest. I'd probably recommend reaching out to a Phab admin (@Reedy, @Aklapper, et al) to confirm.

@Urbanecm That'd be functionally equivalent in some ways, though seems to have originally been for a different purpose. Also, editing Hiera configs and using the Horizon tool isn't quite as user-friendly as the UI for w.wiki (and most other url shorteners) IMO.

In T231518#5471564, @Vojtech.dostal wrote:

I would love if we could use a URL shortener for Wmflabs

@Bstorm - just +1'd the patch with a comment. ipb_sitewide is low risk IMO.

@Urbanecm - Task IDs and even protected Phabricator project names should be fine, as those aren't published or accessible for unprivileged Phabricator/anon users. It's really just some of the sensitive details within certain protected tasks which should never be made public or discussed on related public tasks. Thanks.

Discussed with the Security-Team this morning - we're fine making this task public as long as no sensitive issues from the related protected tasks are discussed here.

In T231608#5455253, @Mooeypoo wrote:

I will remind everyone that we're talking about a WMF employee here.
I can understand high scrutiny in general, but I don't see a how adding an employee to the access group is not something -- honestly -- that we do automatically. If there ever is a reason that a specific employee of the Foundation should not be exposed to security tickets (current or old) then we have a bigger issue about whether or not they should be employed to begin with.

In T231608#5455246, @Niharika wrote:

(where? IRC?)

@Niharika - I think you've illustrated part of the point here: that individuals can be added to Security -protected tasks on a case-by-case basis, as opposed to the entire collection of previous and future tasks. As noted, anyone with Security access can do this, when a demonstrated need arises. The higher bar is merely an effort to more tightly control access to Security tasks, i.e. has the requester only ever worked on a couple of protected tasks or have they worked on several with a likely need for access to future tasks (and potentially older tasks).

@Niharika - Yes. We've lately been trying to limit access even further to Security to those who absolutely need it (as opposed to just kind of want it.) Given @Tchanders's role on the AH team and the tasks you've provided, I think they probably meet these requirements, but again, we'll confirm this at our Security-Team check-in next week.

@Tchanders - the Security-Team will discuss this at our team meeting next Tuesday (September 4th). In the meantime, can you post a few recent security-protected tasks here where you recently needed individual access? Thanks.

The Security-Team is trying to get away from providing a "pass" or "thumbs up" for code during security reviews, as it assumes a level of accountability on our part which we cannot sustain. So we are adopting the more standard system of risk classification and risk ownership for our security reviews. This entails us performing a risk analysis during the review process and then assigning and communicating a level of risk to the requesters/owners of the code. The levels of risk we're using within our analyses are:

Backports complete in gerrit, resolving task for now.

@WMDE-leszek @RazShuty - Just talked with @JBennett. Looks like everything is official re: risk ownership, so I'm going to resolve this task for now. Thanks everyone for all of the patience on working through this review and risk ownership assessment.

In T227591#5425595, @Mholloway wrote:

We're talking with them about what we're doing, and will follow up with them when we're code-complete.

Hey @ssastry - thanks for cutting the security review branch. @Reedy and I will plan to review that soon and reach out to @Arlolra with any questions.

@MarcoAurelio - +1'd both of these. I should be able to security-deploy these sometime today. Is it time to consider a project closure request?

In T229718#5419932, @TTO wrote:

Re number 6, there are already many avenues to deface the wiki if you have edit access to the MediaWiki: namespace. Editing MediaWiki:Sitenotice would have a similar effect as creating a page notice. I don't think the fact that this extension adds another avenue is of any special concern.

Update: CVE-2019-15124.

Patch tested locally, worked fine. Deployed patch to wmf/1.34.0-wmf.17 and tested. I'll request another CVE for this one. Once I have the id, I'll make this task public and backport to master and supported release branches in gerrit.

Proposed patch, same mitigation as T229541:

@Urbanecm - looks like other spambot incidents have been made public in the past, so I think it's fine to do so here. Nothing terribly secret on this particular task.