Am 26.03.2014 00:06, schrieb Nick Coghlan:
On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com
mailto:bcan...@gmail.com
mailto:bcan...@gmail.com
On Wed Mar 26 2014 at 2:15:39 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 26.03.2014 00:06, schrieb Nick Coghlan:
On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon
On 25 March 2014 12:25, MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-03-25 01:29, Ben Darnell wrote:
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com
mailto:ros...@gmail.com
Am 25.03.2014 08:51, schrieb Nick Coghlan:
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.
Perhaps it should just be called Python 2.7 Enhanced Security (Python
2.7 ES).
The PEP currently calls the proposed unmodified fork of 2.7
On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote:
The opting in could be done at the distro level. Red Hat could ship a
thing called /usr/bin/python that runs SEPython, and that package
could be identified and
On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote:
Exactly the same. If someone wants to distribute SEPython (that
someone might be python.org itself, or ActiveState, or anyone else who
has an interest in it),
On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote:
Exactly the same. If someone wants to distribute SEPython (that
someone might be python.org itself, or ActiveState, or anyone else who
has an interest in it), they're welcome to do so; and it could be done
either as an all-in-one
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote:
The opting in could be done at the distro level. Red Hat could ship a
thing called /usr/bin/python that runs SEPython, and that package
could be identified and numbered in such a way that it's clearly a
drop-in replacement for
On 25 March 2014 09:01, Chris Angelico ros...@gmail.com wrote:
So by that model, current 2.7 is fully compliant, and anything that
doesn't actively conflict with that is also compliant. Any script that
is written for the current 2.7 is guaranteed also to run on any
compliant SEPython; and
On Tue Mar 25 2014 at 4:21:51 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 25.03.2014 08:51, schrieb Nick Coghlan:
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.
Perhaps it should just be called Python 2.7 Enhanced Security (Python
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the name of security and have a link
to the last backwards-compatible release then I agree as well.
I am not sure how this meme got started,
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com
mailto:bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the name of security and have a link to
the last
On 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net wrote:
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com
mailto:bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the
On 3/25/2014 6:15 PM, Nick Coghlan wrote:
I am not sure how this meme got started, but let me be clear: the
proposed policy DOES NOT provide blanket permission to break backwards
compatibility in the affected modules. It only allows ADDING new
features to bring these modules into line with
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote:
As has already been pointed out, this can already happen, but in an
ad-hoc way. Making it official or semi-official would mean that a
script written for Debian's Python 2.7.10 would run on Red Hat's
Python 2.7.10, which would surely
On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote:
As has already been pointed out, this can already happen, but in an
ad-hoc way. Making it official or semi-official would mean that a
script written for
On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw ba...@python.org wrote:
I want to stick to our no-Python-2.8 pledge
I don't understand this dogmatic adherence to a no 2.8 pledge. Back
when it was made, I don't think the issue of SSL vulnerabilities was
understood (at least not to the current
On 24 March 2014 23:49, Skip Montanaro s...@pobox.com wrote:
So what's the big deal? Why can't we be pragmatic and call this thing
(whatever it turns out to be) 2.8? Is this pledge and its rationale
written down in a PEP somewhere, so I can study the reasons behind
what appears at this point
On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan ncogh...@gmail.com wrote:
For example, RHEL7 and derivatives are already locked in to 2.7 until
2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
way to keep those combination of RHEL and the Python 2 standard
library from
On Sun, 23 Mar 2014 21:31:12 -0400, Barry Warsaw ba...@python.org wrote:
On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote:
Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the
standard lib. Then you can go back to the standard 2.7 (if you want
to) by unsetting PYTHONPATH.
On 25 March 2014 00:18, Skip Montanaro s...@pobox.com wrote:
On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan ncogh...@gmail.com wrote:
For example, RHEL7 and derivatives are already locked in to 2.7 until
2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
way to keep those
On 25 March 2014 00:36, Nick Coghlan ncogh...@gmail.com wrote:
On 25 March 2014 00:18, Skip Montanaro s...@pobox.com wrote:
The PEP does not permit backwards compatibility breaks in maintenance
releases
Well, ssl.create_default_context() will use the same this is a
dynamic best practices API
On 24 March 2014 08:44, Nick Coghlan ncogh...@gmail.com wrote:
The position I am coming to is that the enhanced security release should
be the default one that we publish binary installers for, but we should also
ensure that downstream redistributors can easily do Python 2.7 with legacy
SSL
Le 24/03/2014 15:21, R. David Murray a écrit :
In the context of that last sentence, I think it is worth noting the
stance that 3.4 is taking[*] about security backward compatibility,
since many people may not be aware of it (we only just finished making
the documentation clear).
If you use
On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 24 March 2014 08:44, Nick Coghlan ncogh...@gmail.com wrote:
The position I am coming to is that the enhanced security release should
be the default one that we publish binary installers for, but we should also
ensure
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com wrote:
As has already been pointed out, this can already happen, but in an
ad-hoc way. Making it official or semi-official would mean that a
script written for
On 23.03.2014 02:33, Brett Cannon wrote:
Now I have been reading this thread on my phone and I only have cursory
understanding of what failure ssl has had as of late, so this might be
stupid, but what if in Python 3.5 we made it so people passed in an
explicit SSL object into the relevant APIs
Hi,
2014-03-22 22:11 GMT+01:00 Nick Coghlan ncogh...@gmail.com:
In particular, the exception will apply to:
* the ``ssl`` module
* the ``hashlib`` module
* the ``hmac`` module
* the ``sha`` module (Python 2 only)
* the components of other networking modules that make use of these modules
Hi,
2014-03-23 11:17 GMT+01:00 mar...@v.loewis.de:
Quoting Victor Stinner victor.stin...@gmail.com:
The drawback is that applications would be benefit immediatly from
this work, they should be modified to use the new module. But usually,
developers who care of security are able to do these
On 23 Mar 2014 20:33, Victor Stinner victor.stin...@gmail.com wrote:
Sorry, it's maybe not fair to take the worst example (OpenStack) :-)
I suspect the Fedora/RHEL/CentOS ecosystem is going to make OpenStack look
like a relatively simple port, and backwards compatibility constraints mean
that
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy tjre...@udel.edu wrote:
The download page for the final 2.7.z maintenance release could say
something like We recommend that you move to the most recent Python 3
version if at all possible. If you cannot do that and you want to use Python
to run a
On 22 March 2014 21:11, Nick Coghlan ncogh...@gmail.com wrote:
Full PEP included inline below, and available in more readable form at
http://www.python.org/dev/peps/pep-0466/
Disclaimer: I pretty much don't use 2.x, or write server-type
software, so my practical requirement for the changes
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
Instead, I think the PEP should propose a special series of server
enhancement releases that are based on the final 2.7 maintenance release
(2.7.8 or 2.7.9) but which have have a different
On Sun, 23 Mar 2014 07:29:07 +
Cory Benfield c...@lukasa.co.uk wrote:
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
Instead, I think the PEP should propose a special series of server
enhancement releases that are based on the final 2.7
On Mar 23, 2014, at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 23 Mar 2014 07:29:07 +
Cory Benfield c...@lukasa.co.uk wrote:
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
Instead, I think the PEP should propose a special
On 3/23/2014 11:37 AM, Donald Stufft wrote:
On Mar 23, 2014, at 11:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 23 Mar 2014 07:29:07 +
Cory Benfield c...@lukasa.co.uk wrote:
This is an interesting idea. My biggest problem with it is that, at least
with the ssl library,
On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote:
But enforcing secure by default can by construction break backwards
compatibility, which is the very reason we are so conservative with
such changes.
Also, many developers who are stuck on Python 2 have already evaluated,
designed, and
On 3/23/2014 3:29 AM, Cory Benfield wrote:
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
Instead, I think the PEP should propose a special series of server
enhancement releases that are based on the final 2.7 maintenance release
(2.7.8 or 2.7.9)
On 24 Mar 2014 09:27, Barry Warsaw ba...@python.org wrote:
On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote:
But enforcing secure by default can by construction break backwards
compatibility, which is the very reason we are so conservative with
such changes.
Also, many developers who are
On 3/23/2014 9:00 AM, Skip Montanaro wrote:
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy tjre...@udel.edu wrote:
The download page for the final 2.7.z maintenance release could say
something like We recommend that you move to the most recent Python 3
version if at all possible. If you cannot
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release protocol) that it should be a drop-in
replacement for earlier 2.7 micro
On Mar 23, 2014, at 7:03 PM, Barry Warsaw ba...@python.org wrote:
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release
On Mon, Mar 24, 2014 at 11:03 AM, Barry Warsaw ba...@python.org wrote:
Python 2.7.x will always be the standard stdlib. We would never release a
specific Python 2.7 + security stdlib release, but downstream developers
would be able to overlay this forked stdlib on top of the standard one.
On 3/23/2014 8:03 PM, Barry Warsaw wrote:
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release protocol) that it should be a
On 3/23/2014 7:48 PM, Nick Coghlan wrote:
Agreed. That's a key part of why the proposal is mainly about syncing
certain key modules with their Python 3 counterparts, rather than
piecemeal backports. That way, all you need to know is the SSL, hashlib
and hmac modules are kept in sync with Python
On Mar 23, 2014, at 8:31 PM, Jesse Noller jnol...@gmail.com wrote:
On Mar 23, 2014, at 7:03 PM, Barry Warsaw ba...@python.org wrote:
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the
On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote:
Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the
standard lib. Then you can go back to the standard 2.7 (if you want
to) by unsetting PYTHONPATH.
It'd be nice if SEPython defined a modified sys.version for clarity,
but
On Mar 23, 2014, at 9:31 PM, Barry Warsaw ba...@python.org wrote:
On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote:
Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the
standard lib. Then you can go back to the standard 2.7 (if you want
to) by unsetting PYTHONPATH.
On Mon, Mar 24, 2014 at 1:34 PM, Donald Stufft don...@stufft.io wrote:
Right now users have a singular method for determining what the runtime
environment looks like for Python, the version. There are processes around
selecting different Python versions for things, upgrading etc. This isn’t
a
Folks,
I have just posted a proposal to change the way we treat enhancements
that relate to Python's support for network security enhancements. I
now see these as categorically different from most other enhancements,
as they have implications for the evolution of internet security as a
whole,
Thanks for putting this together Nick.
I suspect it goes without saying that I'm wildly +1 on this as a whole. I'm in
favor of leaving it somewhat implicit as to exactly which networking modules
concern the health of the internet as a whole.
Alex
___
On Sat, Mar 22, 2014, at 14:11, Nick Coghlan wrote:
Folks,
I have just posted a proposal to change the way we treat enhancements
that relate to Python's support for network security enhancements.
I think the PEP should also address security-mode releases. Do the
same exceptions apply?
Does
On 22 March 2014 at 21:11:24, Nick Coghlan
(ncogh...@gmail.com(mailto:ncogh...@gmail.com)) wrote:
Folks,
I have just posted a proposal to change the way we treat enhancements
that relate to Python's support for network security enhancements. I
now see these as categorically different from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/22/2014 05:11 PM, Nick Coghlan wrote:
In addition to any other module specific contents, this section MUST
enumerate key security enhancements and fixes (with CVE identifiers
where applicable), and the
Incomplete sentence.
Tres.
- --
I think the pep doesn't mandate that someone does. It still requires someone to
care enough to actually write the patch. It just allows such a patch to be
merged.
On Mar 22, 2014, at 5:32 PM, Benjamin Peterson benja...@python.org wrote:
Does anyone really want to backport features to
Am 22.03.14 22:17, schrieb Cory Benfield:
I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7
is a security liability, any it becomes nothing short of irresponsible to
use Python 2.7 for any form of networking code that hits the open
internet.
Agreed (although this might
Just use Python 3.4 ignores the reality of production software. I wish it
were that simple because I love 3.4
On Mar 22, 2014, at 6:16 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 22.03.14 22:17, schrieb Cory Benfield:
I am 100%, overwhelmingly in favour of this. Without this PEP,
Am 22.03.14 22:11, schrieb Nick Coghlan:
Title: Network Security Enhancement Exception for All Branches
I'm -0 on the general idea, and -1 on the inclusion of the 2.7 branch
into the policy.
The PEP trades security concerns against stability and maintainability.
I see a maintenance threat
Am 22.03.14 23:05, schrieb Donald Stufft:
I think the pep doesn't mandate that someone does. It still requires someone
to care enough to actually write the patch. It just allows such a patch to be
merged.
Does it actually? Unfortunately, I never got around to writing the PEP
on
On 23 March 2014 08:14, Martin v. Löwis mar...@v.loewis.de wrote:
Am 22.03.14 22:11, schrieb Nick Coghlan:
Finally, doing this in the 2.7 branch likely involves more effort
than I'm personally willing to provide.
Believe me, I'll be escalating these concerns at work this week. We
have to
Am 22.03.14 23:21, schrieb Donald Stufft:
Just use Python 3.4 ignores the reality of production software. I wish it
were that simple because I love 3.4
But I think so does the PEP (i.e. ignore the reality of production
software). The risk of breaking existing installations (which might
not be
On 23 March 2014 08:23, Martin v. Löwis mar...@v.loewis.de wrote:
Am 22.03.14 23:05, schrieb Donald Stufft:
I think the pep doesn't mandate that someone does. It still requires someone
to care enough to actually write the patch. It just allows such a patch to
be merged.
Does it actually?
In article
cadisq7czsp1flv31izz01_9avgyzsc1j6+d2t5aup2byu97...@mail.gmail.com,
Nick Coghlan ncogh...@gmail.com wrote:
I have just posted a proposal to change the way we treat enhancements
that relate to Python's support for network security enhancements.
+1
[...]
Open Questions
On 23 March 2014 08:16, Martin v. Löwis mar...@v.loewis.de wrote:
Am 22.03.14 22:17, schrieb Cory Benfield:
I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7
is a security liability, any it becomes nothing short of irresponsible to
use Python 2.7 for any form of
Am 22.03.14 23:33, schrieb Nick Coghlan:
Hard to maintain legacy software is a fact of life, and way too much
of it is exposed to the public internet. This PEP is about doing what
we can to mitigate the damage caused both by other people's mistakes,
and also the inherent challenges of
On 22.03.2014 22:11, Nick Coghlan wrote:
PEP: 466
Title: Network Security Enhancement Exception for All Branches
+1
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 22 2014)
Python Projects, Consulting and Support ... http://www.egenix.com/
On 23 March 2014 08:40, Martin v. Löwis mar...@v.loewis.de wrote:
Am 22.03.14 23:33, schrieb Nick Coghlan:
Hard to maintain legacy software is a fact of life, and way too much
of it is exposed to the public internet. This PEP is about doing what
we can to mitigate the damage caused both by
I agree wholeheartedly with the sentiment behind this PEP, but I have
concerns about the implementation. If we introduce new APIs into the ssl
module then we will see packages and applications that depend on Python
2.7.7+, just like with the introduction of bool in 2.2.1. This will be a
mess
On Sat, Mar 22, 2014 at 11:26 PM, Martin v. Löwis mar...@v.loewis.dewrote:
Am 22.03.14 23:21, schrieb Donald Stufft:
Just use Python 3.4 ignores the reality of production software. I wish
it were that simple because I love 3.4
But I think so does the PEP (i.e. ignore the reality of
On Sat, Mar 22, 2014, at 15:40, Martin v. Löwis wrote:
Am 22.03.14 23:33, schrieb Nick Coghlan:
Hard to maintain legacy software is a fact of life, and way too much
of it is exposed to the public internet. This PEP is about doing what
we can to mitigate the damage caused both by other
As someone who is deeply biased towards improving the packaging tool chain and
getting people to use it I think that most people will simply use the Stdlib
even if a more secure alternative exists. Infact one does exist and I still see
almost everyone using the stdlib ssl instead of pyopenssl.
On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote:
I agree wholeheartedly with the sentiment behind this PEP, but I have
concerns about the implementation. If we introduce new APIs into the ssl
module then we will see packages and applications that depend on Python
2.7.7+, just
Am 22.03.14 23:39, schrieb Ned Deily:
Regarding the python.org binary installers, I think past practice has
been for us to update third-party libraries as necessary in maintenance
releases when there is good cause and with the concurrence of the
release manager, so I don't see this as a big
Am 23.03.14 00:02, schrieb Benjamin Peterson:
As (I believe) previously discussed and documented in PEP 373, this date
currently will be May 2015.
Ah! Thanks for reminding me. I think PEP 466 then needs to take a
position on that, as well. By the past schedule, this probably means
two more bug
On 22 March 2014 23:07, Donald Stufft don...@stufft.io wrote:
As someone who is deeply biased towards improving the packaging tool chain
and getting people to use it I think that most people will simply use the
Stdlib even if a more secure alternative exists. Infact one does exist and I
still
On 23 March 2014 07:32, Benjamin Peterson benja...@python.org wrote:
On Sat, Mar 22, 2014, at 14:11, Nick Coghlan wrote:
Folks,
I have just posted a proposal to change the way we treat enhancements
that relate to Python's support for network security enhancements.
I think the PEP should
On 23 March 2014 09:07, Donald Stufft don...@stufft.io wrote:
As someone who is deeply biased towards improving the packaging tool chain
and getting people to use it I think that most people will simply use the
Stdlib even if a more secure alternative exists. Infact one does exist and I
still
On Sat, 22 Mar 2014 19:07:51 -0400
Donald Stufft don...@stufft.io wrote:
As someone who is deeply biased towards improving the packaging tool chain
and getting people to use it I think that most people will simply use the
Stdlib even if a more secure alternative exists. Infact one does exist
On Sun, 23 Mar 2014 09:08:29 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote:
I agree wholeheartedly with the sentiment behind this PEP, but I have
concerns about the implementation. If we introduce new APIs into the ssl
module
On Sat, Mar 22, 2014, at 16:34, Antoine Pitrou wrote:
On Sun, 23 Mar 2014 09:08:29 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 23 March 2014 08:53, Ben Darnell b...@bendarnell.com wrote:
I agree wholeheartedly with the sentiment behind this PEP, but I have
concerns about the
On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
The issue isn't really the ssl module itself - it's the other modules
that *depend* on the ssl module (like httplib, urllib, poplib, ftplib,
imaplib). You could technically try to monkeypatch or shadow the
stdlib ssl
In the case of requests they already have an optional dependency on pyopenssl.
It's just many people either don't know they should use it, are unable to use
it, or unwilling to use the python packaging tool chain because of its current
flaws.
On Mar 22, 2014, at 7:42 PM, Ben Darnell
On 22 March 2014 23:49, Donald Stufft don...@stufft.io wrote:
In the case of requests they already have an optional dependency on
pyopenssl. It's just many people either don't know they should use it, are
unable to use it, or unwilling to use the python packaging tool chain
because of its
Also important to remember that pip itself uses the OpenSSL binding in the ssl
module so there is a chicken and egg problem.
On Mar 22, 2014, at 7:49 PM, Donald Stufft don...@stufft.io wrote:
In the case of requests they already have an optional dependency on
pyopenssl. It's just many
They detect for ssl to have the SSLContext and use it if it's available.
On Mar 22, 2014, at 7:54 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 March 2014 23:49, Donald Stufft don...@stufft.io wrote:
In the case of requests they already have an optional dependency on
pyopenssl. It's just
On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Mar 2014 19:07:51 -0400
Donald Stufft don...@stufft.io wrote:
As someone who is deeply biased towards improving the packaging tool chain
and getting people to use it I think that most people will simply use
On Sun, 23 Mar 2014 07:11:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
It is similar to the previous IDLE policy exception PEP, where we
decided that cross version consistency of IDLE superseded the general
policy against backporting enhancements to maintenance branches.
But the
On Sat, 22 Mar 2014 23:54:37 +0100
Thomas Wouters tho...@python.org wrote:
Or not rely on the standard library for their security. Much as I realize
it is necessary for rudimentary SSL support (for example) to exist in the
standard library,
Unfortunately, rudimentary SSL support is worse
On Sun, 23 Mar 2014 10:59:22 +1100
Chris Angelico ros...@gmail.com wrote:
Is it really that bad to have something depend on 2.7.10 rather than
2.7.0?
It makes our whole release and versioning scheme very confusing
(hopefully people will not have to read Nick's PEP to understand
it :-)).
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
cryptography-related, but that shouldn't make a difference.
(for example the dreaded XML issues have never been properly
On 23 Mar 2014 10:18, Christian Heimes christ...@python.org wrote:
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
cryptography-related, but that shouldn't make a
On Sun, 23 Mar 2014 01:01:38 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 23 Mar 2014 07:11:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
This PEP does *not* grant any general exemptions to the usual backwards
compatibility policy for maintenance releases. Instead, it is
Am 23.03.14 01:15, schrieb Christian Heimes:
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
cryptography-related, but that shouldn't make a difference.
(for example the
On 23 March 2014 10:08, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Mar 2014 23:54:37 +0100
Thomas Wouters tho...@python.org wrote:
Or not rely on the standard library for their security. Much as I realize
it is necessary for rudimentary SSL support (for example) to exist in the
On 23 March 2014 10:40, Martin v. Löwis mar...@v.loewis.de wrote:
Am 23.03.14 01:15, schrieb Christian Heimes:
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
On Sun, 23 Mar 2014 01:40:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Am 23.03.14 01:15, schrieb Christian Heimes:
On 23.03.2014 01:01, Antoine Pitrou wrote:
This is a bit limited. There are remotely-exploitable security issues
which are still open on the bug tracker; they are not
On Mar 22, 2014, at 8:55 PM, Nick Coghlan ncogh...@gmail.com wrote:
Moving the affected modules out of the standard library proper and
bundling the critical ones along with pip instead is indeed another
alternative. However, that approach introduces additional issues of
its own - I'll cover
I'm a bit under the weather and I'm not sure what to think of this yet.
With that provision, and trying to be brief:
I agree that there are security concerns about Python 2.7 that can't be
addressed by recommending Python 3.4 instead. I also agree that the ban on
new features in old releases can
On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 23 March 2014 10:08, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Mar 2014 23:54:37 +0100
Thomas Wouters tho...@python.org wrote:
Or not rely on the standard library for their security. Much as I
realize
On Mar 22, 2014, at 9:17 PM, Ben Darnell b...@bendarnell.com wrote:
On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan ncogh...@gmail.com wrote:
What we have essentially found is that where we could basically get
away with an 18 month update cycle for improved network security
support (extended
1 - 100 of 103 matches
Mail list logo
