Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 3 September 2014 01:19, Antoine Pitrou solip...@pitrou.net wrote: Keeping saying it doesn't make it magically true. Sure, but it *is* true, at the very least for HTTP. RFC 2818 (HTTP over TLS) has the following language in section 3.1: If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. The default behaviour of httplib is in contravention of the normative language of this specification and is therefore bugged. (For those unclear about the relevance of RFC 2818, it's normatively referenced by RFC 7230, which is the HTTP/1.1 spec.) This should silence the debate about whether or not httplib's behaviour is a bug or not. Besides, it can perfectly well be a bug fix *as well as* a break in backwards compatibility. This is definitely true, and this change is both. The only question that matters is whether we believe we're doing users a service by breaking their code. I'd argue, along with Glyph, Alex and Donald, that we are. I've been on the losing side of this debate a number of times though, and I expect I will be again. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
Hi all I am using buildbot now for some time and i would be willing to contribute on that. I had small work on openstack buildbot slave but had not the proper infrastructure to get more value out of it. I like that project and automation. Anyway, if i could be of help let me know (; Short to my person: i am christian staffa and actually living in germany. Chris Sent from my Sony Xperia™ smartphone Nick Coghlan wrote ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/christian.staffa%40gmx.de ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 3 Sep 2014 18:28, Cory Benfield c...@lukasa.co.uk wrote: This is definitely true, and this change is both. The only question that matters is whether we believe we're doing users a service by breaking their code. I'd argue, along with Glyph, Alex and Donald, that we are. I've been on the losing side of this debate a number of times though, and I expect I will be again. The default stdlib behaviour will change in 3.5, I don't think anyone is disputing that. While I earlier said that should depend on the sslcustomize PEP, I now think they should be made orthogonal so the SSL customisation PEP can focus on its potential for *increasing* security in properly configured environments rather than deliberately decreasing it after upgrading to Python 3.5 in improperly configured ones. The backwards compatibility argument only applies to Python 2 maintenance releases (where dreid indicated an intention to request backporting the change), and there I'm quite happy to take the position of use requests, Twisted or Python 3.5+ to get HTTPS done right. There are a variety of reasons not to use the Python 2 stdlib for modern networking, and making better tools more readily accessible to Python 2 users by backporting ensurepip is my preferred answer. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, 3 Sep 2014 20:34:32 +1000 Nick Coghlan ncogh...@gmail.com wrote: The backwards compatibility argument only applies to Python 2 maintenance releases (where dreid indicated an intention to request backporting the change), and there I'm quite happy to take the position of use requests, Twisted or Python 3.5+ to get HTTPS done right. or asyncio. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Tue, 02 Sep 2014 21:29:16 -0400 R. David Murray rdmur...@bitdance.com wrote: The top proposal so far is an sslcustomize.py file that could be used to either decrease or increase the default security. This is a much less handy solution than application options (eg, curl, wget) that allow disabling security for this cert or this CLI session. It also is more prone to unthinking abuse since it is persistent. So perhaps it is indeed not worth it. (That's why I suggested an environment variable...something you could specify on the command line for a one-off.) I'll be fine with not adding any hooks at all, and letting people configure their application code correctly :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, 03 Sep 2014 16:31:13 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 02 Sep 2014 21:29:16 -0400 R. David Murray rdmur...@bitdance.com wrote: The top proposal so far is an sslcustomize.py file that could be used to either decrease or increase the default security. This is a much less handy solution than application options (eg, curl, wget) that allow disabling security for this cert or this CLI session. It also is more prone to unthinking abuse since it is persistent. So perhaps it is indeed not worth it. (That's why I suggested an environment variable...something you could specify on the command line for a one-off.) I'll be fine with not adding any hooks at all, and letting people configure their application code correctly :-) Again, the problem arises when it is not *their* application code, but a third party tool that hasn't been ported to 3.5. I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 09/03/2014 08:58 AM, R. David Murray wrote: I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the application/utility to be able to talk over https to a router with an invalid certificate? This is an option when creating the ssl_context? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
As mentioned, I don't mind sysadmining a bit, if required. My primary joy would be helping code python, but can't seem to figure out the ideal place to start doing so. Therefore, helping out as sysadmin would be a good start. On Wed, Sep 3, 2014 at 4:58 PM, Cameron Simpson c...@zip.com.au wrote: On 03Sep2014 11:47, Stephen J. Turnbull step...@xemacs.org wrote: Nick Coghlan writes: Sorry, I haven't been a very good maintainer for that buildbot (the main reason it never graduated to the stable list). If you send me your public SSH key, I can add it (I think - if not, I can ask Luke to do it). Alternatively, CentOS 6 may exhibit the same problem. I wonder how many of these buildbots could be maintained by the kind of folks who show up on core-mentorship asking how can I help? Just a thought -- I wouldn't be surprised if the reaction is universal horror and the answer is Are you crazy? Zero! Z-E-R-O!! And of course most want to write code, not sysadm. I do both. Happy to help in a small way if wanted. Cheers, Cameron Simpson c...@zip.com.au Maintainer's Motto: If we can't fix it, it ain't broke. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ rajshorya%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
Ethan Furman ethan at stoneleaf.us writes: I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the application/utility to be able to talk over https to a router with an invalid certificate? This is an option when creating the ssl_context? -- ~Ethan~ Yes, it's totally possible to create (and pass to ``http.client``) an ``SSLContext`` which doesn't verify various things. My proposal is only about changing what happens when you don't explicitly pass a context. Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
On Sun, Aug 31, 2014 at 3:00 PM, Nick Coghlan ncogh...@gmail.com wrote: However, we still think we should start providing pip by default to Python 2.7 users as well, at least as part of the Windows and Mac OS X installers. serious +1 here. Just last night I was writing up notes for an intro to python class on getting started. (py2, :-( ) The go download get-pip.py and run it with python step(s) is a serious hiccup. Better than it's been for years, but sure would be nice to just install python then use pip to install packages As for the feature freeze of py2.7 -- this is really an addition to teh installers, not to python itself (or it can be seen that way, anyway) Thanks Ned for offering to back port for OS-X ! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 09/03/2014 10:15 AM, Alex Gaynor wrote: Ethan Furman writes: I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the application/utility to be able to talk over https to a router with an invalid certificate? This is an option when creating the ssl_context? Yes, it's totally possible to create (and pass to ``http.client``) an ``SSLContext`` which doesn't verify various things. My proposal is only about changing what happens when you don't explicitly pass a context. Excellent. Last question (I hope): it is possible to (easily) create an SSLContext that will verify against a self-signed certificate? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
[...] But it does mean a measure of trust in some external entity, or else some very careful rules (mainly firewall), which not every coder will know about. Just curious, is there a way to mount the infrastructure the oder way around? One sets a system polling for sources changes, if so it starts a build an sends per e-mail the results to some address. Thanks in advance! francis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, Sep 3, 2014 at 8:58 AM, R. David Murray rdmur...@bitdance.com wrote: I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. I'm with this sentiment (cautiously +1) -- and not just because of Twisted's experience or Glyph's passion. Network security is much more important now than it was five years ago -- and yet Python 2.7 is at least that old. My own experience has changed a lot: five years ago (when I worked at Google!) it was common to find internal services that required SSL but had a misconfigured certificate, and the only way to access those services was to override the browser complaints. Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- internal services here all redirect to SSL, and not a browser that can find fault with their certs. If I did get a complaint about a certificate I would fire off an email to a sysadmin alerting them to the issue. Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. I don't want to start preaching security doom and gloom (the experts are doing enough of that :-), but the scale and sophistication of attacks (whether publicized or not) is constantly increasing, and routine maintenance checks on old software are just one of the small ways that we can help the internet become more secure. (And please let the PSF sysadmin team beef up *.python.org -- sooner or later some forgotten part of our infrastructure *will* come under attack.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, 3 Sep 2014 10:54:55 -0700 Guido van Rossum gu...@python.org wrote: Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). I'm entirely against this. Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- internal services here all redirect to SSL, and not a browser that can find fault with their certs. Good for you. I still sometimes get warnings about expired certificates - and sometimes ones that don't exactly match the domain being fetched (for example, the certificate wouldn't be valid for that specific subdomain - note that CAs often charge a premium for multiple subdomains, which why small or non-profit Web sites sometimes skimp on them). You shouldn't assume that the experience of well-connected people in the Silicon Valley is representative of what people over the world encounter. Yes, where there's a lot of money and a lot of accumulated domain competence, security procedures are updated and followed more scrupulously... But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. Only if you are actually the one managing that certificate and the machine it's installed one... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Sep 3, 2014, at 1:54 PM, Guido van Rossum gu...@python.org wrote: On Wed, Sep 3, 2014 at 8:58 AM, R. David Murray rdmur...@bitdance.com mailto:rdmur...@bitdance.com wrote: I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. I'm with this sentiment (cautiously +1) -- and not just because of Twisted's experience or Glyph's passion. Network security is much more important now than it was five years ago -- and yet Python 2.7 is at least that old. My own experience has changed a lot: five years ago (when I worked at Google!) it was common to find internal services that required SSL but had a misconfigured certificate, and the only way to access those services was to override the browser complaints. Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- internal services here all redirect to SSL, and not a browser that can find fault with their certs. If I did get a complaint about a certificate I would fire off an email to a sysadmin alerting them to the issue. Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. +1, this makes me unreasonably happy. I don't want to start preaching security doom and gloom (the experts are doing enough of that :-), but the scale and sophistication of attacks (whether publicized or not) is constantly increasing, and routine maintenance checks on old software are just one of the small ways that we can help the internet become more secure. (And please let the PSF sysadmin team beef up *.python.org http://python.org/ -- sooner or later some forgotten part of our infrastructure *will* come under attack.) This is an ongoing effort amongst the Infra team, part of the process is moving infrastructure away from hand crafted servers towards servers managed by config management as well as making sure all our services are behind TLS as well. -- --Guido van Rossum (python.org/~guido http://python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, 03 Sep 2014 20:37:38 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 3 Sep 2014 10:54:55 -0700 Guido van Rossum gu...@python.org wrote: Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- internal services here all redirect to SSL, and not a browser that can find fault with their certs. Good for you. I still sometimes get warnings about expired certificates - and sometimes ones that don't exactly match the domain being fetched (for example, the certificate wouldn't be valid for that specific subdomain - note that CAs often charge a premium for multiple subdomains, which why small or non-profit Web sites sometimes skimp on them). You shouldn't assume that the experience of well-connected people in the Silicon Valley is representative of what people over the world encounter. Yes, where there's a lot of money and a lot of accumulated domain competence, security procedures are updated and followed more scrupulously... Heck, yesterday I got invalid certs from...I think it was roku.com, but in any case not some obscure little company...the actual cert was an akamai cert, which means something is configured wrong somewhere. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 03.09.2014 19:29, Ethan Furman wrote: Excellent. Last question (I hope): it is possible to (easily) create an SSLContext that will verify against a self-signed certificate? Yes: context = ssl.create_default_context(cafile=/path/to/selfsigned.pem) That works iff the certificate is valid, not expired and its CN or SAN matches the hostname of the service. When the hostname doesn't match then you have to set context.check_hostname = False Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman et...@stoneleaf.us wrote: On 09/03/2014 08:58 AM, R. David Murray wrote: I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the application/utility to be able to talk over https to a router with an invalid certificate? This is an option when creating the ssl_context? The immediately preceding paragraph that you didn't quote said that the context was 3rd party applications, not source code under your control. Yes, you can (usually) still hack the source, but there are good reasons to prefer to not do that, unfamiliarity with the codebase being just one of them. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
Antoine, I think we are well past the point where arguments can sway positions. There clearly is no agreement on this issue. So please treat my post as a BDFL tie-breaker. I will just give you one thing to ponder -- those small/non-profit websites that can't afford proper certs are exactly the ones that will be hosting malware soon. Sorry for them, and the certificate vendors certainly aren't in it for charity, but they must fix their certificate issues (and probably improve many other sysadmin practices). --Guido On Wed, Sep 3, 2014 at 11:37 AM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 3 Sep 2014 10:54:55 -0700 Guido van Rossum gu...@python.org wrote: Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). I'm entirely against this. Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- internal services here all redirect to SSL, and not a browser that can find fault with their certs. Good for you. I still sometimes get warnings about expired certificates - and sometimes ones that don't exactly match the domain being fetched (for example, the certificate wouldn't be valid for that specific subdomain - note that CAs often charge a premium for multiple subdomains, which why small or non-profit Web sites sometimes skimp on them). You shouldn't assume that the experience of well-connected people in the Silicon Valley is representative of what people over the world encounter. Yes, where there's a lot of money and a lot of accumulated domain competence, security procedures are updated and followed more scrupulously... But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. Only if you are actually the one managing that certificate and the machine it's installed one... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 03.09.2014 19:54, Guido van Rossum wrote: Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. I'm +1 for Python 3.5 but -1 for Python 2.7. The SSLContext backport will landed in Python 2.7.9 (to be released). No Python 2 user is familiar with the feature yet. But more importantly: None of the stdlib modules support the new feature, too. httplib, imaplib ... they all don't take a SSLContext object as an argument. PEP-466 does not include the backport for the network modules. Without the context argument there is simply no clean way to configure the SSL handshake properly. The default settings must stay until we decide to backport the context argument and have a way to configure the default behavior. Nick and me are planing a PEP. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
2014-09-03 21:26 GMT+02:00 Christian Heimes christ...@python.org: On 03.09.2014 19:54, Guido van Rossum wrote: I'm +1 for Python 3.5 but -1 for Python 2.7. The SSLContext backport will landed in Python 2.7.9 (to be released). No Python 2 user is familiar with the feature yet. But more importantly: None of the stdlib modules support the new feature, too. httplib, imaplib ... they all don't take a SSLContext object as an argument. PEP-466 does not include the backport for the network modules. Without the context argument there is simply no clean way to configure the SSL handshake properly. Thanks, you replied before I asked the question :-) (If certificates are validated by default, how do you disable the checks?) Sorry, I didn't follow the whole discussion and Python 2.7 changes related to security. Does Python 2.7 support loading (automatically) system certificate authorities? Like the Windows certificate store: https://docs.python.org/dev/whatsnew/3.4.html#whatsnew34-win-cert-store Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
OK, that changes my position for 2.7 (but not for 3.5). I had assumed there was a way to disable the cert check by changing one parameter to the urlopen() call. (And I had wanted to add that there should be a clear FAQ about the subject.) If this isn't possible that changes the situation. (But I still think that once we do have that simple change option we should do it, in a later 2.7 upgrade.) I apologize for speaking before I had read all facts, and I'll await what you and Nick come up with. --Guido On Wed, Sep 3, 2014 at 12:26 PM, Christian Heimes christ...@python.org wrote: On 03.09.2014 19:54, Guido van Rossum wrote: Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). But at least some of the time it will be a wake-up call and an expired certificate will be replaced, resulting in more security for all. I'm +1 for Python 3.5 but -1 for Python 2.7. The SSLContext backport will landed in Python 2.7.9 (to be released). No Python 2 user is familiar with the feature yet. But more importantly: None of the stdlib modules support the new feature, too. httplib, imaplib ... they all don't take a SSLContext object as an argument. PEP-466 does not include the backport for the network modules. Without the context argument there is simply no clean way to configure the SSL handshake properly. The default settings must stay until we decide to backport the context argument and have a way to configure the default behavior. Nick and me are planing a PEP. Christian -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 09/03/2014 12:10 PM, R. David Murray wrote: On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman et...@stoneleaf.us wrote: On 09/03/2014 08:58 AM, R. David Murray wrote: I'm OK with letting go of this invalid-cert issue myself, given the lack of negative feedback Twisted got. I'll just keep my fingers crossed. I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the application/utility to be able to talk over https to a router with an invalid certificate? This is an option when creating the ssl_context? The immediately preceding paragraph that you didn't quote said that the context was 3rd party applications, not source code under your control. Yes, you can (usually) still hack the source, but there are good reasons to prefer to not do that, unfamiliarity with the codebase being just one of them. I appreciate that there is a distinction, yet in most cases we have the source code available (it is the nature of Python) and if push comes to shove (and a bunch of other colloquialisms) then modifying that source code can get you up and running again. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 03.09.2014 21:37, Victor Stinner wrote: Thanks, you replied before I asked the question :-) (If certificates are validated by default, how do you disable the checks?) Sorry, I didn't follow the whole discussion and Python 2.7 changes related to security. Does Python 2.7 support loading (automatically) system certificate authorities? Like the Windows certificate store: https://docs.python.org/dev/whatsnew/3.4.html#whatsnew34-win-cert-store Yes! Alex and others have ported all SSL features back to Python 2.7. The SSL module in Python 2.7.9 will have the same feature set as Python 3.4. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 03.09.2014 21:37, Guido van Rossum wrote: OK, that changes my position for 2.7 (but not for 3.5). I had assumed there was a way to disable the cert check by changing one parameter to the urlopen() call. (And I had wanted to add that there should be a clear FAQ about the subject.) If this isn't possible that changes the situation. (But I still think that once we do have that simple change option we should do it, in a later 2.7 upgrade.) I apologize for speaking before I had read all facts, and I'll await what you and Nick come up with. You are welcome! :) I like to see cert checks in Python 2.7, too. Eventually Python 2.7 should have them enabled by default or at least have one very simple way to enable them globally. Right now we aren't there yet. Perhaps Python 2.7.10 or 2.7.11 will have the necessary bits and backports. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
In article CAMpsgwabYhXB0OG3UhdX=fucyonajgzpwd-g8stdaukjzpj...@mail.gmail.com, Victor Stinner victor.stin...@gmail.com wrote: 2014-09-02 23:03 GMT+02:00 Matthew Woodcraft matt...@woodcraft.me.uk: In any case I think PEP 475 should be explaining what is going to happen to signal.siginterrupt(). Will setting flag=True be supported? I first proposed to deprecate the function, but Charles-François thinks that it's unrelated to the PEP (it can be addressed later). The function will still be available and work. If so, will doing so change the behaviour of those parts of the stdlib which have already been modified to retry after EINTR? I think that the stdlib should not handle InterruptedError exception anymore in the Python code, to simplify the code. That seems good to me. I think it's worth writing in the PEP. But if Python is going to provide its own higher-level model of signal handling, then I think signal.siginterrupt() will need to be documented in terms of that model; it should be saying something along the lines of if a signal arrives while Python is blocking in a system call then InterruptedError will be raised, and I suppose it will need to say what happens if the signal handler also raised an exception. (I think it would be helpful if we could tell people if you want the old EINTR behaviour, just do this simple thing. And I suppose siginterrupt flag=True is a candidate for that.) Why do you want the old behaviour? Purely to avoid breaking existing programs, particularly in ways which will require effort to fix. I think Python's backward-compatibility rules are basically the behavior of an API must not change without going through the deprecation process. If we're going to be making an exception to that here, then it would be much better to say here's a simple change to make to keep your old program working, rather than please rewrite your fiddly signal-handling code to use more modern techniques, however much nicer those modern techniques are. Or perhaps it would be better to not make an exception at all, and instead add an 'interrupt_syscalls' boolean keyword argument to signal.signal(), while strongly recommending that people set it False. -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
Guido van Rossum guido at python.org writes: OK, that changes my position for 2.7 (but not for 3.5). I had assumed there was a way to disable the cert check by changing one parameter to the urlopen() call. (And I had wanted to add that there should be a clear FAQ about the subject.) If this isn't possible that changes the situation. (But I still think that once we do have that simple change option we should do it, in a later 2.7 upgrade.) I apologize for speaking before I had read all facts, and I'll await what you and Nick come up with. --Guido This probably doesn't surprise anyone, but I'm more than happy to do the back- porting work for httplib, and any other modules which need SSLContext support; does this require an additional PEP, or does it fit under PEP466 or PEP476? Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
2014-09-03 0:13 GMT+02:00 Victor Stinner victor.stin...@gmail.com: AMD64 OpenIndiana 3.x: a lot of tests fail with OSError(12, Not enough space) or MemoryError. It's probably on issue on the host. x86 OpenIndiana 3.x: MemoryError. TestReadline.test_init() also fails. I sent an email to Jesus Cea (owner of these buildbots). x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't have to this platform, I don't know how to fix it. I sent my SSH key to Nick (owner). x86 Windows Server 2003 [SB] 3.x: test_build_ext() of test_distutils hangs during 1 hang before being killed, it hangs something in the C compiler. I sent an email to the mailing list of the snakebite network. x86 XP-4 3.x: test_distutils fails because Visual Studio linker (link.exe) fails with the error 1181 (cannot open input file). test_capi.test_forced_io_encoding() fails with an assertion error because sys.__stdin__ is None. I sent an email to David Bolen (owner). ARMv7 3.x: Read-only file system, Mercurial fails... I sent an email to Gregory P. Smith (owner). x86 FreeBSD 7.2 3.x: test_io.test_interrupted_write_text() hangs. I skipped the test on FreeBSD 7.2 (even if the test pass on FreeBSD 6.4): http://bugs.python.org/issue22331 x86 FreeBSD 6.4 3.x: (...) test_multiprocessing_spawn fails whereas the test should be skipped. I skipped the test on FreeBSD 6.4: http://bugs.python.org/issue22332 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
Guido van Rossum writes: lot: five years ago (when I worked at Google!) it was common to find internal services that required SSL but had a misconfigured certificate, and the only way to access those services was to override the browser complaints. Today (working at Dropbox, a much smaller company!) I don't even remember the last time I had to deal with such a browser complaint -- I would tend to discount your recent experience, then. Smaller (and possibly even more important in this fast-developing area, younger) organizations are a lot more nimble about things like this. That is not intended to express an opinion about a backport, though. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Wed, Sep 3, 2014, at 13:37, Alex Gaynor wrote: Guido van Rossum guido at python.org writes: OK, that changes my position for 2.7 (but not for 3.5). I had assumed there was a way to disable the cert check by changing one parameter to the urlopen() call. (And I had wanted to add that there should be a clear FAQ about the subject.) If this isn't possible that changes the situation. (But I still think that once we do have that simple change option we should do it, in a later 2.7 upgrade.) I apologize for speaking before I had read all facts, and I'll await what you and Nick come up with. --Guido This probably doesn't surprise anyone, but I'm more than happy to do the back- porting work for httplib, and any other modules which need SSLContext support; does this require an additional PEP, or does it fit under PEP466 or PEP476? I imagine you could put it into 476. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 4 Sep 2014 04:39, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 3 Sep 2014 10:54:55 -0700 Guido van Rossum gu...@python.org wrote: Let's take the plunge on this issue for the next 2.7 release (3.5 being a done deal). I'm entirely against this. Yes, some people will find that they have an old script accessing an old service which breaks. Surely some of the other changes in the same 2.7 bugfix release will also break some other scripts. People deal with it. Probably 90% of the time it's an annoyance (but no worse than any other minor-release upgrade -- you should test upgrades before committing to them, and if all else fails, roll it back). Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. We can potentially deal with the more conservative part of the user base on the redistributor side - so long as the PEP says it's OK for us to not apply this particular change if we deem it appropriate to do so. That would make this a case of upstream asking us to do the kind of risk assessment that people pay us for, which is a kind of request I'm generally happy to get :) That way, if downstream users get upset, we can point them at their vendor support department, rather than having them take out their ire on upstream volunteers. Also, after thinking through the implications a bit more, my guess is that Fedora Software Collections will accept the change without any fuss, but the CentOS/RHEL side could be a more involved discussion. On the other hand, orgs with these kinds of problems aren't likely to have rolled out RHEL 7 or CentOS 7 yet either, so they're probably still back on Python 2.6 (RHEL 6) or even 2.4 (RHEL 5). 2.7.9 is going to be a somewhat interesting release that requires careful attention anyway (due to the completion of the PEP 466 backports), so if Guido's OK with it, sure, let's kill the HTTPS isn't problem for Python 2 as well. One additional wrinkle in that case: we will likely need to backport the SSLContext related changes to httplib as well. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 4 Sep 2014 06:39, Alex Gaynor alex.gay...@gmail.com wrote: Guido van Rossum guido at python.org writes: OK, that changes my position for 2.7 (but not for 3.5). I had assumed there was a way to disable the cert check by changing one parameter to the urlopen() call. (And I had wanted to add that there should be a clear FAQ about the subject.) If this isn't possible that changes the situation. (But I still think that once we do have that simple change option we should do it, in a later 2.7 upgrade.) I apologize for speaking before I had read all facts, and I'll await what you and Nick come up with. --Guido This probably doesn't surprise anyone, but I'm more than happy to do the back- porting work for httplib, and any other modules which need SSLContext support; does this require an additional PEP, or does it fit under PEP466 or PEP476? I suggest writing up a separate PEP for 2.7 that covers exactly what would need to be backported in order to make the same HTTPS handling change in Python 2. For 476, I suggest taking my list of modules that call _create_stdlib_cert and being completely explicit as to which ones are *not* changing (as that will help clarify the scope of the backport proposal). I learned that lesson with PEP 453 - it's well worth making the Python 3 PEP easier to accept by making it independent of the inevitably more controversial Python 2 backport PEP :) Cheers, Nick. Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On Thu, 4 Sep 2014 09:19:56 +1000 Nick Coghlan ncogh...@gmail.com wrote: Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. We can potentially deal with the more conservative part of the user base on the redistributor side - so long as the PEP says it's OK for us to not apply this particular change if we deem it appropriate to do so. So people would believe python.org that they would get HTTPS cert validation by default, but their upstream distributor would have disabled it for them? That's even worse... Of course, people could read distribution-specific package changelogs, but nobody does that. 2.7.9 is going to be a somewhat interesting release that requires careful attention anyway (due to the completion of the PEP 466 backports), so if Guido's OK with it, sure, let's kill the HTTPS isn't problem for Python 2 as well. Possible unvoluntary breakage due to a large backport is one thing. Deliberate breakage is another. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 09/03/2014 04:36 PM, Antoine Pitrou wrote: On Thu, 4 Sep 2014 09:19:56 +1000 Nick Coghlan ncogh...@gmail.com wrote: Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. We can potentially deal with the more conservative part of the user base on the redistributor side - so long as the PEP says it's OK for us to not apply this particular change if we deem it appropriate to do so. So people would believe python.org that they would get HTTPS cert validation by default, but their upstream distributor would have disabled it for them? That's even worse... I agree. If the vendors don't want to have validation by default, they should stick with 2.7.8. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
On 1 September 2014 08:00, Nick Coghlan ncogh...@gmail.com wrote: Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7 maintenance release in addition to including it with Python 3.4. That part of the proposal proved to be controversial, so we dropped it from the original PEP in order to focus on meeting the Python 3.4 specific release deadlines. This also had the benefit of working out the kinks in the bootstrapping processing as part of the Python 3.4 release cycle. However, we still think we should start providing pip by default to Python 2.7 users as well, at least as part of the Windows and Mac OS X installers. I suggested off-list that, as Python 2.7 release manager, Benjamin would be a good candidate for BDFL-Delegate for this proposal, and both Guido and Benjamin agreed. The PEP has been updated accordingly: http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a copy-and-paste error in the PEP status!) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 09/03/2014 05:00 PM, Ethan Furman wrote: On 09/03/2014 04:36 PM, Antoine Pitrou wrote: On Thu, 4 Sep 2014 09:19:56 +1000 Nick Coghlan ncogh...@gmail.com wrote: Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. We can potentially deal with the more conservative part of the user base on the redistributor side - so long as the PEP says it's OK for us to not apply this particular change if we deem it appropriate to do so. So people would believe python.org that they would get HTTPS cert validation by default, but their upstream distributor would have disabled it for them? That's even worse... I agree. If the vendors don't want to have validation by default, they should stick with 2.7.8. If good argument can be made for why we should make validation by default optional, then that point should be well made in Python's release notes, and some easy programmatic way to tell if validation is on or off (which may just be more docs saying call SSLContext and examine the results: xxx means you're validating, yyy means you are not). -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
On Thu, Sep 4, 2014 at 3:32 AM, francis franci...@email.de wrote: does mean a measure of trust in some external entity, or else some very careful rules (mainly firewall), which not every coder will know about. Just curious, is there a way to mount the infrastructure the oder way around? One sets a system polling for sources changes, if so it starts a build an sends per e-mail the results to some address. I'm more talking about how there's a (virtual) machine that I run, executing code sent to me by someone else (the Python devs). That machine needs a certain measure of access to the internet (to fetch code, and to run certain tests), and the easy and naive way to set it up is to give it full access to everything, which is the trust that I spoke of. Firewalling that box so it can't see anything it's not allowed to see is certainly possible, but that requires sysadmin skills, not coder skills, hence my comment. And it's very easy to make a mistake that you won't notice - everything works just fine, because normally that buildbot won't do anything it shouldn't. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad status of Python 3.x buildbots
I wonder if there is any interest in starting to use the opensuse build servers for continuous build and testing on redhat, fedora suse and (I think) debian: that will solve once for all the maintenance issues on those platforms (and provide a reliable build). Regards, Antonio ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
On Wed, Sep 3, 2014, at 17:03, Nick Coghlan wrote: On 1 September 2014 08:00, Nick Coghlan ncogh...@gmail.com wrote: Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7 maintenance release in addition to including it with Python 3.4. That part of the proposal proved to be controversial, so we dropped it from the original PEP in order to focus on meeting the Python 3.4 specific release deadlines. This also had the benefit of working out the kinks in the bootstrapping processing as part of the Python 3.4 release cycle. However, we still think we should start providing pip by default to Python 2.7 users as well, at least as part of the Windows and Mac OS X installers. I suggested off-list that, as Python 2.7 release manager, Benjamin would be a good candidate for BDFL-Delegate for this proposal, and both Guido and Benjamin agreed. The PEP has been updated accordingly: http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a copy-and-paste error in the PEP status!) ... and accepted. Let's make our users' lives' better!. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 4 September 2014 10:00, Ethan Furman et...@stoneleaf.us wrote: On 09/03/2014 04:36 PM, Antoine Pitrou wrote: On Thu, 4 Sep 2014 09:19:56 +1000 Nick Coghlan ncogh...@gmail.com wrote: Python is routinely updated to bugfix releases by Linux distributions and other distribution channels, you usually have no say over what's shipped in those updates. This is not like changing the major version used for executing the script, which is normally a manual change. We can potentially deal with the more conservative part of the user base on the redistributor side - so long as the PEP says it's OK for us to not apply this particular change if we deem it appropriate to do so. So people would believe python.org that they would get HTTPS cert validation by default, but their upstream distributor would have disabled it for them? That's even worse... I agree. If the vendors don't want to have validation by default, they should stick with 2.7.8. Yes, that's the way it would work in practice - we'd call it 2.7.8, and backport fixes from upstream 2.7.x as needed (as someone put it to me recently, a useful way to think of component version numbers in RHEL is as referring to the *oldest* pieces of code in that component). I've spent quite a bit more time considering the proposal, and I'm now satisfied that making this change upstream isn't likely to cause any major problems, due to the fact that folks who are likely to suffer from this change aren't likely to even be on 2.7 yet. While we managed not to be last this time, the RHEL/CentOS ecosystem is still a useful benchmark for the roll out of Python versions into conservative enterprise organisations, and the more conservative users within *that* ecosystem are likely to wait for the x.1 release (at the earliest) rather than upgrading as soon as x.0 is out. RHEL 7.0 only came out in June, so most of those conservative environments are still going to be on Python 2.6 in RHEL 6. While we shipped 2.7 support well before the release of RHEL 7 as part of Software Collections and OpenShift, the kinds of environments where properly validating SSL by default may cause problems aren't likely to be on the leading edge of adopting new approaches to software deployment like SCL and PaaS. Fixing the HTTPS validation defaults would have several significant positive consequences: - lowers a major barrier to Python adoption (and continued usage) for public internet focused services - fixes a latent security defect for Python applications operating over the public internet - fixes a latent security defect for Python applications operating in a properly configured intranet environment - reveals a latent security defect for Python applications communicating with improperly configured public internet services - reveals a latent security defect for Python applications operating in improperly configured intranet environments The debate is thus solely over how to manage the consequences of the last two, since going from silent failure to noisy failure looks like going from working to broken to someone that isn't already intimately familiar with the underlying issues. That question needs to be considered separately for 3 different versions: - 3.5 - 3.4 - 2.7 3.5 is not controversial, the answer is that the standard library's handling of HTTPS URLs should change to verify certificates properly. No ifs, buts, or maybes - Python 3.5 should automatically verify all HTTPS connections, with explicit developer action required to skip (or otherwise relax) the validation check. So far, we have assumed that 3.4 will get at most a warning. However, I have changed my mind on that, because Python 3 is still largely an early adopter driven technology (it's making inroads into more conservative environments, but it's still at least a few years away from catching up to Python 2 on that front). As a result, the kinds of environments RDM and I are worried about will generally *not* be using Python 3, or if they are, it will be for custom scripts that they can fix. I wouldn't suggest actually making that change without getting an explicit +1 from the Canonical folks (since 3.4 is in Ubuntu LTS 14.04), but I would now personally be +1 on just *fixing it* in 3.4.2, rather than doing a bunch of additional development work purely so we can make folks wait another year for the Python 3 standard library to correctly handle HTTPS. That leaves Python 2.7, and I have to say I'm now persuaded that a backport (including any required httplib and urllib features) is the right way to go. One of the tasks I'd been dreading as a follow-on from PEP 466 was organising the code audit to make sure our existing Python 2 applications are properly configuring SSL. If we instead change Python 2.7.9 to validate certificates by default, then the need to do that audit *goes away*, replaced by the far more mundane tasking of doing integration testing on 2.7.9, which we'd have to do *anyway*. Systematically
Re: [Python-Dev] Sad status of Python 3.x buildbots
On 4 September 2014 11:07, Antonio Cavallo a.cava...@cavallinux.eu wrote: I wonder if there is any interest in starting to use the opensuse build servers for continuous build and testing on redhat, fedora suse and (I think) debian: that will solve once for all the maintenance issues on those platforms (and provide a reliable build). It sounds like a good idea in principle, but I suspect there would be a lot of devils in those details. That doesn't make it a bad idea, just something that would need a volunteer to investigate further before we could form a real opinion. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
On 4 September 2014 12:21, Benjamin Peterson benja...@python.org wrote: On Wed, Sep 3, 2014, at 17:03, Nick Coghlan wrote: On 1 September 2014 08:00, Nick Coghlan ncogh...@gmail.com wrote: Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7 maintenance release in addition to including it with Python 3.4. That part of the proposal proved to be controversial, so we dropped it from the original PEP in order to focus on meeting the Python 3.4 specific release deadlines. This also had the benefit of working out the kinks in the bootstrapping processing as part of the Python 3.4 release cycle. However, we still think we should start providing pip by default to Python 2.7 users as well, at least as part of the Windows and Mac OS X installers. I suggested off-list that, as Python 2.7 release manager, Benjamin would be a good candidate for BDFL-Delegate for this proposal, and both Guido and Benjamin agreed. The PEP has been updated accordingly: http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a copy-and-paste error in the PEP status!) ... and accepted. Let's make our users' lives' better!. Huzzah! Over to you, Ned Donald. We can give Steve the good news for the Windows side of things as well :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
