[00:00:28] $wgProxyList = "$wmfConfigDir/../private/mwblocker.log"; [00:00:30] * Reedy looks [00:00:57] Pfft. That whole usef account has gone [00:01:20] What even writes to that file [00:01:24] Presumably nothing [00:03:52] TimStarling: Any ideas? [00:03:59] The fact that it's .log suggests something did at some point... [00:04:15] 414 mwblocker.log [00:04:20] I wonder how many hold any value today [00:05:42] maybe it is for the proxy blocker [00:05:48] incredible that it still exists though [00:05:55] -rw-r--r-- 1 demon wikidev 5834 Feb 4 2016 mwblocker.log [00:06:10] And even then.. That was " Adding mwblocker to private repo" [00:08:50] I'm looking [00:09:55] it actually might be... [00:11:01] the proxyblocker and proxyblockreason messages support this theory [00:12:58] no, Special:Blockme used the ipblocks table, it didn't write to mwblocker.log [00:15:45] it may date back to as early as 2004, that's when $wgProxyList was introduced [00:16:55] heh [00:17:16] Is it potentially related from when we didn't have globalblocking etc too? [00:17:42] If there was something autoscanning, and adding to a log file... [00:19:16] https://lists.gt.net/wiki/wikitech/13025?search_string=proxy%20blocker;#13025 [00:20:43] * Reedy forks T36261 into a task to use IPSet instead [00:21:08] https://en.wikipedia.org/wiki/User:Proxy_blocker [00:21:15] "This open proxy port scanner was in operation from March 2004 to January 2005." [00:21:23] I'm nostalgically refreshing my memory about this, but I think the solution is to just remove it [00:21:39] I was thinking that too, tbh [00:21:41] you can't indefinitely block an IP address (which is what this is), it doesn't make sense [00:21:58] And, our community is generally well tooled up nowadays.... [00:22:09] nobody uses the same IP address for decades [00:22:12] That if any are still open proxies, and become abusive again, they'll just get blocked [00:22:34] if they are open proxies, they need to be periodically rescanned, not just blocked forever [00:22:58] Well, that too :) [00:23:56] https://gerrit.wikimedia.org/r/345074 gets it out of CommonSettings.php [00:28:04] TimStarling: Shall I just deploy it? [00:29:18] one more minute... [00:29:21] TimStarling: random bug - is https://phabricator.wikimedia.org/T24559 still relevant as far as you know? I saw some movement last few months around wikidiff2, also wondering in general what its destiny is. [00:30:34] Reedy: ok you can merge it, I'll give it +1 [00:31:41] Krinkle: probably still relevant, yes [00:31:59] some WMDE folks are adding more features to wikidiff2, which will make it slower still [00:33:54] TimStarling: I lost track of which diff engines we have and what direction we want to go in. [00:34:11] I recall MaxSem also workink on it last year [00:34:16] We removed diff3 I think. [00:34:39] wgExternalDiffEngine [00:34:57] * * string: path to an external diff executable [00:34:57] * * false: wikidiff2 PHP/HHVM module if installed, otherwise the default PHP implementation [00:34:57] * * 'wikidiff', 'wikidiff2', and 'wikidiff3' are treated as false for backwards compatibility [00:36:31] I don't think a pure-PHP diff engine can replace wikidiff2 [00:36:45] because of performance [00:37:08] we can extend wikidiff2 or replace it with something else written in a fast language [00:37:25] wikidiff2 has had a lot of development from people other than me, which is nice [00:39:54] I think I've got it, Reedy [00:40:20] Go on? [00:41:00] I went to a webpage with a list of open proxies, then reformatted them into a flat text file and added $wgProxyList to read it [00:41:21] so vandals couldn't use the same open proxy list [00:41:28] aha [00:41:34] As a one time thing? [00:41:38] yes [00:42:02] in response to the vandalism mentioned on wikitech-l, which was the incentive for developing both $wgProxyList and the automated proxy scanner [00:42:14] both were added in the same commit [00:43:00] but I have an intermediate stashed diff from March 2004 showing the automated one being written first [00:44:41] I'm sure that must be it, a static copy of an open proxy list from March or April 2004 [00:45:02] Sounds plausible [00:45:20] And probably more than enough at the time to stop a decent amount of spam [00:47:44] Makes you wonder if there's been any complaints resulting from that list.... And they've gone unnoticed/unfixed [01:49:32] Reedy: yay, https://travis-ci.org/wikimedia is greener [19:34:37] anomie: anything for SoS? [19:36:18] tgr: Nothing new. Still waiting for reviews. [19:37:36] sorry about that... I'm almost finished, will probably be able to wrap up on Friday [19:39:40] anomie: was https://phabricator.wikimedia.org/T160563 resolved satisfactorily or are you still waiting for feedback on that? [19:44:28] tgr: At the moment I'm just going to leave it for someone else to do someday. [20:22:03] anomie: question about https://gerrit.wikimedia.org/r/#/c/302368 [20:22:18] I see there are a bunch of potential if conditions for which there are no indexes [20:22:49] so which ones are problematic? [20:25:19] SMalyshev: Any case that makes a query that has to fetch millions of rows to find the few to return is potentially problematic. [20:26:26] anomie: yeah sure but there are a lot of options there - rc_minor, rc_bot, rc_user, rc_patrolled, etc. [20:26:43] and I don't see indexes for all of them now [20:27:22] SMalyshev: It's probably only worth worrying about the ones that have index coverage now. [20:28:05] ok, I see rc_new, rc_namespace, rc_user_text, rc_bot [20:29:05] no rc_user though which is strange [22:05:45] AaronSchulz: are you available to talk about EtcdConfig? [22:18:54] I'll just write on T156924 [22:18:54] T156924: Allow integration of data from etcd into the MediaWiki configuration - https://phabricator.wikimedia.org/T156924 [22:38:59] any legoktm? [22:39:07] on the same topic