[00:24:14] TimStarling: any objections to me merging https://gerrit.wikimedia.org/r/#/c/243895/ ? [00:26:42] I'll review it [00:26:51] cool [00:26:52] thanks [00:27:34] you should be flattered, the key header draft is very similar to what you proposed in 2008 [00:55:29] no credit given though [04:39:13] ori, I didn't say merge your own amendment without review [04:39:37] is there an issue with it? [04:39:49] oh, you added a comment [04:59:02] hasher: wonder what's up with https://gerrit.wikimedia.org/r/#/c/244383/ [05:05:49] gah [05:05:55] I ran into that earlier today with anomie's patch [05:06:02] [10:55:05] and it looks like someone enabled composer test on AbuseFilter without actually merging the change that adds it... [05:15:53] TimStarling: https://gerrit.wikimedia.org/r/#/c/244397/ [05:18:20] thanks [16:56:57] ori: Solar flares? Pshaw.....everyone knows it's the position of the moon. [16:57:26] ostriches: doesn't php have some built-in support for calculating that? [16:57:31] i vaguely recall something like that [16:57:53] I thought we used to have something like /usr/local/bin/potm or somesuch [16:57:55] A long time ago [17:00:41] emacs does, of course [17:41:34] Sigh. https://phabricator.wikimedia.org/T115032 [17:49:19] anomie: :( I think we can pin something with our crappy old phpunit version to work around that. Let me see if I can find the place I've seen that before [17:51:31] Out of interest... Do we have a phpunit version check in MW? [17:51:33] blerg. the workaround is for the hhvm bug [17:51:50] Just wondering with their stable version not supporting old php versions etc now [17:52:41] So people need to use oldstable to support PHP 5.3... And will need to continue to for a long time :/ [17:52:50] If there's a version check, it's happy to pass PHPUnit 4.7.6. [17:53:53] anomie: the hack I was thinking of is this one in monolog -- https://github.com/Seldaek/monolog/blob/master/composer.json#L29 [17:54:08] I wonder if there is a similar hack for the issue you are hitting? [17:55:00] If I add that to core composer.json, it whines that phpunit/phpunit 3.7.37 requires phpunit/phpunit-mock-objects ~1.2 [17:55:25] yeah. and 1.2.3 seems to be the latest 1.2.x tag [17:55:58] That probably works for monolog because it uses phpunit ~4.5 (line 20 at that link) [17:56:02] our testing dependencies are a pain in the ass [18:06:24] bd808: Hmm. "git update-index --skip-worktree composer.json" then remove phpunit from composer.json looks like it'll mostly work, except for pain and cursing whenever someone changes composer.json. [18:06:56] which only happens once a week :) [18:07:07] reedy@tin:~$ php phpunit.phar [18:07:07] This version of PHPUnit requires PHP 5.6; using the latest version of PHP is highly recommended. [18:07:12] fair enough [18:53:59] legoktm: how do you initialize an extension configuration setting to a computed value? [18:54:25] extension.json obviously can't do that and callbacks don't have accessto the configuration object [20:11:23] anomie: no fair. I had found a bug in your SessionManager stuff but you fixed it before I finished reading things and submitted a review ;) [20:11:39] bd808: Which bug was that? [20:11:44] array_merge() and nested arrays [20:12:30] It was in outputpage I think but you hoisted the nested array up as I was going to suggest [20:13:32] Yeah, I saw a new test failed that when I rebased [20:55:11] tgr: on T30085, with the current patch, wouldn't an attacker get the same response when trying to auth with an email address matching multiple accounts or 0 accounts? [20:56:04] Both would do the dummy hash, and would return WRONG_INPUT [20:56:15] csteipp: that's what I gather but haven't seen the current patch [20:56:31] there is discussion on the ticket on how to make that more user-friendly [20:57:23] e.g. if all those accounts have the same password then it's safe to tell that you didn't mistype the email but cannot log in due to some old account of yours that you probably have forgotten [20:57:36] probably safe to list those accounts, even [20:58:10] I mean if they have the same password and you provided it correctly [20:58:37] possibly even if they have different passwords but you provided one of them [20:58:40] Ah, yeah, I missed that. Good in theory, but then we have a massive timing attack... [20:59:17] that's what the discussion quoted in https://phabricator.wikimedia.org/T30085#1691937 was about [21:00:26] the general sentiment on IRC seemed to be not to be worried about theoretical timing attacks too much since it's impossible to have the exact same timing for 0 hit / 1 hit / multiple hits in the DB lookup [21:01:28] and rather benchmark the actual effect on timing and see if that's practical for an attacker [21:02:06] As I recall there were several people who wondered if the existence of a give user account was really a secret because of Special:ActiveUsers and related things [21:02:46] user accounts are not; email addresses are [21:03:39] user <-> email pairings are even more so [21:04:10] that seems like the real protected information [21:04:23] bd808: It depends, but in general, we don't consider usernames private. [21:05:01] It would be nice to keep the private on private wikis [21:10:19] csteipp: yeah, that makes sense. I was thinking too enwiki centric [21:12:00] So the timing attack would basically reveal that (0, 1, N) user account(s) on the wiki use a given email. What does that buy the attacker in theory? [21:14:12] I think T.im thought that only really told them if the email address was real or not and thought that was information easier to acquire by other means [21:19:28] bd808: for 0 vs 1, you can then brute force possible accounts. i.e., for user Foo I can guess "foo@gmail.com", "foo@hotmail.com", etc, then potentially harass them directly via email (instead of being limited to 5, iirc, emails a day via emailuser) [21:20:38] If you're just brute forcing off of a known list of emails (from the latest databreach), then 1 vs N might give information about which user account matched it. [21:21:07] If you know one user has a known test account, e.g. [21:21:50] I've personally always hated email address as a proxy for (or the only) user name [21:21:56] you can just make a list of email address guesses and send harassing mails to them directly [21:23:30] $DAYJOB-1 did that in their products and it caused a lot of stupid problems like Company A acquired by Company B and now their 300 users all want to change their usernames to their new email addresses [21:23:42] if you compare this to existing threats such as the user not realizing that they give away their email when answering to a query they got via Special:EmailUser then it doesn't make the life of an attacker much easier than it is already [21:24:45] We should just go with ostriches' perennial suggestion that we just get rid of user accounts all together and let everyone be anon :) [21:24:46] one fun concern I have run into in a commercial environment was families who have used a shared email address and then divorced [21:25:04] and then one party could look into the other's purchases or something [21:26:05] but on thw whole IMO usability vs. security is a tradeoff and the first outweighs the second by far here [21:27:36] I heard someone mention a fantastic idea! [21:27:44] Oh, it was bd808, and one of my fantastic ideas :p [21:29:20] Think of how much code an config we could nuke! [21:29:34] less code, less problems [21:29:38] obvious ^ [21:46:07] you should just go for distributed mediawiki then [21:46:32] and distribute it via email [21:46:38] no need for users at all [21:46:44] carrier pigeon, obvs. [21:46:51] > e-mail [21:47:14] which is not totally unlike how cutting edge online reference material was created 30 years ago [21:47:24] bd808: Stupid vagrant question. I have some old versions of boxes lying about, eg: [21:47:30] parallels/debian-8.1 (parallels, 1.0.2) [21:47:30] parallels/debian-8.1 (parallels, 1.0.3) [21:47:53] How do I kill the old 1.0.2 one? I know `vagrant box destroy parallels/debian-8.1` but I'm afraid it'll nuke both [21:48:29] add `--box-version 1.0.2` [21:48:36] Add, #til [21:48:47] vagrant box remove parallels/debian-8.1 --box-version 1.0.2 [21:49:28] * bd808 just ran the very secret `vagrant box remove --help` command [21:49:46] "Appears to still be in us by at least one vagrant" [21:49:47] LIES [21:49:53] * ostriches grabs a stabby-shaped device [21:50:17] * bd808 hands ostriches a freshly sharpened `rm -rf` [21:50:41] they're stored in ~/.vagrant.d/boxes if you're sure you want to delete it [21:51:09] just drop it in the virtualbox management panel? [21:51:48] that will nuke the virtualbox vm but not the base box image [21:51:55] I don't use virtualbox, and also it is lying...the box in question is using 1.0.3 :) [21:52:31] marxarelli: Folder names in ~/.vagrant.d/boxes/ are funny! [21:52:38] parallels-VAGRANTSLASH-debian-8.1 [21:52:42] VAGRANTSLASH! [21:52:50] my next band name [21:53:02] botched string interpolation no doubt [21:53:10] Actually, I bet it was on purpose. [21:53:11] my next band name [21:53:20] Since box names are foo/bar format. [21:53:26] And foo/bar would require....subdirectories! [21:53:31] no doubt songs played backwards [21:54:36] Gwen would always be getting back together with her boyfriend and becoming happy [21:55:04] * ostriches queues up his no doubt playlist [21:55:08] aww [21:56:14] no doubt lyrics are the ska version of country songs [21:56:21] You and meeeeee......we used to be......together...... [21:56:21] the good ones were anyway [21:56:25] Everyday together [21:56:26] Always [21:56:32] I really feeeeeellllll [21:56:39] That I'm losing....my best friend [21:56:49] forever [21:56:54] DON'T SPEAK [21:57:13] i know just what you're saying [21:57:31] It's hard to type the lyrics in real time as I listen....giving up [21:59:05] * ostriches copies Tragic Kingdom to his phone for the commute home