Per conversations w/ @Daimona and @JFishback_WMF today, provided soft +1 with qualifiers on r498773.

Strong support (for their work on phan-taint-check-plugin alone)

Yep, that's what the patch is already doing using LOCATE + SQL conditional.

I'd definitely be fine with hiding the whole row if afh_flags contains 'hidden'

@bd808 - there'd been some long-running (and kind of incomplete) work on this here, I believe: T103011, particularly T103011#3536648. And some more work here: T169097. Regarding r498773, specifically, it looks like @Bawolff had labeled that Safe to replicate but requires view-based redaction. I'll plan to book some time today or tomorrow with @JFishback_WMF to further review.

Will try to look at this soon and get some comments/questions up. Would also love for @Reedy to do the same if he has a minute, once he's back next week.

I assume we'd be interested in the All Site Data files here, namely the IPv4 and IPv6 Combined files. These have the following sizes:

Thanks, @MarcoAurelio (and everyone else). Resolving this for now.

@DannyS712 - Sorry for the delay, I'd been working on another incident. And it potentially had some implications for this revert, so I wanted to think a bit more on it. For now, I think this is still fine to revert as long as we keep an eye on it. I've gone ahead and +2'd the patch.

Looks like it's just an fopen() call. Not sure if it'd be easier to leave $wgSFSIPListLocation as a local file and set up the cron to pick up whatever SFS files we'd like with something like:

export https_proxy=http://webproxy.eqiad.wmnet:8080
0 0 0 0 0 curl https://www.stopforumspam.com/downloads/listed_ip_365_ipv6.zip -o /path/to/local/file

Or if we need to pull down the daily SFS updates and merge those...

@MarcoAurelio - weird, it looks like javascript thinks some instances of username and/or cuCount are objects as opposed to strings. Clearly getStatsTable() is expecting them to always be strings. Here's a fix for getStatsTable() I came up with, tested here. It type-checks a bit and then JSON.stringify()'s any unexpected data types.

function getStatsTable( entries ) {
	var html =
        '<table class="wikitable sortable">\n'
        + '<tr>'
        + '<th> Username </th>'
        + '<th> Count </th>'
        + '</tr>\n';

Ok, a quick review:

1. In general, these kinds of user-scripts can become an especially ripe attack vector if they are 1) used by privileged users 2) are used by several users and loaded via one entry-point. The first case is certainly true, given the CU right required for queryCheckUserLog(). The second case isn't true so far as I'm only seeing one other user loading it, according to mwgrep. Still, something to be mindful of.
2. getStewards() - fine, only pulling public data via the API.
3. queryCheckUserLog() - fine, must have CU to view the CU log.
4. appendToPage() - fine by itself, if text is trusted/sanitized. See next items below...
5. getStatsTable() - even though we are pulling from a trusted source (mw API), it is a best practice to sanitize data at all sinks. Wrapping something like mw.html.escape() around entry.name and entry.count would be a good idea here.
6. init() - again, even though we are pulling from a trusted source (mw API), it is a best practice to sanitize data at all sinks. Wrapping something like mw.html.escape() around username and data within the onError handler would be a good idea. totalCount, within the $.when.apply block, should be fine since it's locally-derived from numerical data and is also being passed to jquery.text().

@DStrine @AndyRussG - ok, a few more comments with minor issues added to the other three patch sets from T226963#5321539 (r497611, r519959, r516459). And then a more serious concern here. There may be issues with my local testing, but I was getting some... unexpected results with BannerMessage::sanitize().

Update: Comment and +1 added to r519974. Still having a look at r497611, r519959 and r516459.

@DStrine @AndyRussG - I don't think anyone's been able to look at this as the Security-Team is currently very short-staffed with recent departures and leaves of absence. I'll try to review today and provide some feedback here.

Approved by the Security-Team and @JBennett. I'd add them, but I don't have the privs for Security, so a Phab admin will need to as @Reedy and @chasemp are technically away on leave right now.

Approved by the Security-Team and @JBennett. I'd add them, but I don't have the privs for Security, so a Phab admin will need to as @Reedy and @chasemp are technically away on leave right now.

Thanks, @Dzahn!