[05:13:47] <ori>	 the man page for ssh_config says that "IdentityFile may be used in conjunction with IdentitiesOnly to select which identities in an agent are offered during authentication." I was a bit confused by that -- how do you use a file path to represent a key that is held by the agent?
[05:14:29] <ori>	 it turns out that you can use IdentityFile to point to the public key that is associated with the private key that is held by the agent
[05:29:56] <bd808>	 I think pointing via public key is only needed if your private key is held in a smart card
[05:30:10] <bd808>	 but good to know that there is a way to handle that
[05:31:14] <ori>	 yeah, this was for the yubikey
[15:33:44] <urandom>	 ori, AaronSchulz: https://gerrit.wikimedia.org/r/#/c/56567 <-- thank you!
[17:25:26] <legoktm>	 someone is porting composer to ruby: https://github.com/ikappas/php-composer
[17:27:44] <Reedy>	 whyyyyyy
[17:29:29] <MatmaRex>	 whatttt
[17:31:19] <legoktm>	 I'm not really sure: https://github.com/composer/semver/issues/30#issuecomment-162458985
[17:31:24] <legoktm>	 the gitlab link is a 500 for me
[18:35:29] <bd808>	 legoktm: https://github.com/gitlabhq/gitlabhq/pull/9301 -- looks like it is some kind of attempt to make gitlab act as a private Packagist registry?
[18:37:01] <legoktm>	 o.O
[18:47:22] <robla>	 there's someone that I recently spoke with who I think would be awesome for working on SecurePoll.  He's "homunq" on #wikimedia-analytics
[18:47:30] <robla>	 that seems like throwing him in the deep end, though
[19:13:05] <MatmaRex>	 ostriches: do you know why our Gerrit has the commit-msg hook at https://gerrit.wikimedia.org/r/tools/hooks/commit-msg and not https://gerrit.wikimedia.org/tools/hooks/commit-msg ? git-review looks at the latter URL
[19:13:14] <MatmaRex>	 legoktm: ^
[19:13:31] <MatmaRex>	 it's INCREDIBLY annoying
[19:14:15] <legoktm>	 in -releng he said you have to use it over ssh
[19:14:23] <MatmaRex>	 i know
[19:14:27] <MatmaRex>	 but this should work too
[19:15:56] <ostriches>	 MatmaRex: All of gerrit is at /r/
[19:16:36] <MatmaRex>	 but… tools assume the wrong URL
[19:16:42] <MatmaRex>	 is that not a problem for you? :/
[19:16:52] <Reedy>	 gerrit is actually redit
[19:20:14] <ostriches>	 Well the tool should know the correct url if you clone it from a proper url.
[19:20:17] <MatmaRex>	 ostriches: nothing in .gitreview points the tool to /r/.
[19:20:17] <ostriches>	 Perhaps someone could patch up git-review to do the right thing then?
[19:20:54] <ostriches>	 Or, you know, not use git-review. It's not a terribly nice tool.
[19:22:40] <MatmaRex>	 ostriches: legoktm: can we set up a rewrite rule for this in [puppet]/modules/gerrit/templates/gerrit.wikimedia.org.erb ?
[19:22:57] <MatmaRex>	 (can you?)
[19:22:59] <ostriches>	 Sure no reason we couldn't.
[19:32:18] <MatmaRex>	 ostriches: https://gerrit.wikimedia.org/r/257396 does it look like it'll work? i hate rewrite rules
[19:34:14] <ostriches>	 lgtm
[19:35:23] <MatmaRex>	 ostriches: then, can you deploy it? :P (or do i have to sign up for puppetswat or something?)
[19:37:04] <ostriches>	 I don't have root so nerpppp
[19:37:11] <ostriches>	 Either puppetswat or bribe someone
[20:09:03] <hashar>	 AaronSchulz: thank you to have finished UUIDv1 support for UUIDGenerator ( https://gerrit.wikimedia.org/r/#/c/56567 ) :-}
[20:43:34] <AaronSchulz>	 hasher: I wish that class was a library
[20:43:56] <AaronSchulz>	 though that would require librarizing some other stuff first and redoing the singleton() pattern
[20:44:26] <AaronSchulz>	 I guess we could have a MW specific factory class that has getInstance() instead of UIDGenerator::singleton
[20:44:47] <AaronSchulz>	 it always sucks when you have singleton() and then need to inject some configuration
[23:32:42] <Reedy>	 https://phabricator.wikimedia.org/T120757 "Overhaul how Maintenance scripts are run (especially in extensions)"
[23:34:23] <Reedy>	 Ah, a dupe
[23:36:53] <Reedy>	 TimStarling: https://lists.wikimedia.org/pipermail/mediawiki-l/2015-December/045042.html
[23:36:55] <Reedy>	 Very nice!
[23:37:47] <greg-g>	 "You are an essential
[23:37:51] <greg-g>	 part of their infrastructure." my favorite line
[23:38:04] <greg-g>	 (I guess two lines, dur)
[23:38:27] <Reedy>	 I suspect you only have to google a bit to find stories of owned wordpress installs etc
[23:38:35] <Reedy>	 Presumably there's been some MW ones, but seemingly not as common
[23:38:51] <Reedy>	 I wish we had like a pet security pen tester who could demonstrate things to people
[23:38:56] <TimStarling>	 MW is much more secure than wordpress or drupal
[23:38:57] <Reedy>	 I'm not saying owning their machines
[23:39:13] <greg-g>	 my wordpress install had spam for a couple weeks when I wasn't watching, pretty common
[23:39:15] <Reedy>	 But putting files where they shouldn't be etc
[23:39:24] <Reedy>	 well, there's spam and there's getting owned
[23:39:33] <TimStarling>	 I checked a CVE search for mediawiki, it looks like we haven't had a single shell execution vulnerability discovered that affects 1.13
[23:39:59] <Reedy>	 I know we have nowhere near as many security bugs as WP etc, and certainly, it's stuff like path disclosure, not machine owning
[23:40:18] <legoktm>	 As long as you don't install any shady extensions...
[23:40:35] <TimStarling>	 yeah, we've had loads of XSS vulnerabilities, but we have a policy of not allowing escalation from XSS to owning the machine
[23:41:40] <TimStarling>	 whereas drupal and wordpress historically have allowed the admin to control the server
[23:42:32] <TimStarling>	 so I think if you are running MW 1.13 on PHP 5.1 or something, then PHP 5.1 is actually your weakest point
[23:42:45] <TimStarling>	 since it has loads of exploitable heap corruption vulnerabilities
[23:44:37] <TimStarling>	 confirmed, 1.13 does call exif_read_data() which has had several vulnerabilities in it
[23:44:50] <Reedy>	 TBH, this seems like a good reason to keep with bumping to 5.5 etc... If you're unwilling or unable to upgrade your systems and/or find another host that will, why should we support you?
[23:45:07] <TimStarling>	 have you seen the survey results?
[23:45:20] <TimStarling>	 https://docs.google.com/forms/d/1Z-io754bUxVujh100D4xvIwkiBIFk9Ef0j4TYrJ2zMc/viewanalytics?usp=form_confirm
[23:45:46] <TimStarling>	 also the raw responses are shared with all staff: https://docs.google.com/spreadsheets/u/1/d/1kT4l4TiewtsJYNmx6UfX9xDqrhWBcpw1fKrgbd55oMc/edit
[23:46:34] <Reedy>	 "Very hard (would require begging or switching providers)	20	39.2%"
[23:46:36] <Reedy>	 That's interesting
[23:47:16] <Reedy>	 I wonder how many of those correlate to < PHP 5.5 etc
[23:49:26] <Reedy>	 Linux VPS or bare metal, and you have root access	Hard (over an hour)
[23:49:45] <Reedy>	 Linux VPS or bare metal, and you have root access	Very hard (would require begging  or switching providers)
[23:49:47] <Reedy>	 ...
[23:50:42] <TimStarling>	 I'll see if I can load the responses into a local mysql, that'll make it easier to do some intersections
[23:53:32] <legoktm>	 Reedy: probably they don't know how
[23:53:49] <Reedy>	 I wonder if asking "Technical expertise" would be useful or a red herring
[23:54:18] <legoktm>	 I think I said VPS + hard, mainly because before an OS upgrade I'd want to backup everything, and we currently don't do that very well.
[23:54:58] <Reedy>	 I guess if the provider doesn't provide snapshotting or similar
[23:55:20] <legoktm>	 me having root is different from having access to the VPS account :P
[23:55:40] <Reedy>	 Also true
[23:57:55] <Reedy>	 Saying that, for commercial software that we have to pay a licence fee to use, and maintenance... Not been upgraded in 16 months. Ask about doing it
[23:57:58] <Reedy>	 "Therefore we wouldn’t advise upgrading if it is working fine for you at the moment."
[23:58:07] <Reedy>	 "Basically if it’s not broken don’t fix it scenario."
[23:58:22] <Reedy>	 Just do as I fricken ask
[23:58:49] <Reedy>	 It's behaviour like that, that I'm still supporting a dos application running on a laptop that's falling apart
[23:59:08] <Reedy>	 it dualboots windows 95 and the dos app...