Log file Viewer
#pypa logs for Sunday the 26th of June, 2016
[00:23:27] <dstufft> count: Can't puppet & co release a backported 1 line patch to resolve a security issue?
[01:34:54] <count> dstufft: the problem is that it's not a online patch, as the whole infra for cert validation etc has to get in place,
[01:35:28] <dstufft> count: if they want to maintain the current semantics they can just disable HTTPS validation if they want.
[01:35:48] <count> dstufft: and existing systems relying on this working are currently broken regarding their auto-update functionality (when using 'latest' for a pip package version)
[01:44:01] <dstufft> in either case, even if it did work I'd probably be against it-- the goal here is to get people to hardcode HTTPS urls for "API" routes (to essentially mimic the functionality of HSTS) not to silently switch people to HTTPS on each and every request and incur an additional request/response cycle
[01:44:27] <dstufft> ideally that comes along with also correctly validating certificates if they need to do extra work to do that, but I can't control that
[01:45:08] <count> dstufft: yeah. my interest is in un-fscking a few hundred sysadmins through little fault of their own ;)
[01:47:16] <dstufft> count: yea, and I am sypathetic to this cause. We've had valid HTTPS available for > 3 years now and I don't think that waiting another 6 months, or 1 year, or 2 years is going to meaningfully change anything here (for puppet specifically it might becuase they happened to make an unrelated change that inadvertingly fixed this in a new version of their tool and presumably if we wait some amount of time more people will be on that version instead
[01:48:21] <count> I'm already writing a ticket for them to provide a new minor for their supported majors ;)
[01:50:55] <dstufft> but in the general case, people who currently have http://.... hard coded aren't going to switch to https:// without something to prompt them, and we don't really have a better lever to tell them to do that except by breaking them
[01:51:47] <dstufft> we do the redirect for "ui" routes largely because we have HSTS there so the HTTP -> HTTPS redirect happens once (or typically not at all since we pre-load too) and then the browser ensures it's always HTTPS from there on out
[01:52:44] <dstufft> unftortunately for something like the puppet case, there's no mechanism like HSTS except switching the value from http:// to https://
[01:56:53] <dstufft> count: https://s.caremad.io/NZrLBaqMgg/ last 3 weeks, yellow is 4xx red is 5xx the 403 on HTTPS change happened on the 15th
[01:58:36] <dstufft> (for some sense of scale, we've averaged 101M requests a day in that some time frame)
[01:58:56] <dstufft> but average is a bit misleading because our weekends are always noticably less than weeksdays
[01:59:22] <dstufft> count: yea, it's one of those things I think that 95% of people just don't notice, but for the 5% of people who do it sucks until they get it fixed
[01:59:53] <dstufft> and I wish I had a better way to communicate to people "hey you should change this", but sadly there's no generic way to push a deprecation warning on a random HTTP respond
[02:06:45] <count> dstufft: I think 301 would be quite prudent here, but clients may (but should not) decide to not follow it .. their problem, then.
[02:07:15] <count> dstufft: the 4xx series as 'client-side request' error is a valid alternativ, though, from my point of view *shrug*
[07:24:35] <tdsmith> a data point for distutils-sig?: brew install doesn't upgrade, brew upgrade foo is eager
[20:37:44] <thm> a "pip install svn+https://... installs a package with version x.y.dev0" - shouldn't it use the subversion rev number?