On 3/22/2014 8:55 PM, Nick Coghlan wrote:
Unfortunately, "rudimentary SSL support" is worse than nothing.
I'm going to try to find a way to steal that line and get it into the
PEP. I'm not sure yet if my proposal is the *right* answer, but this
observation gets right to the heart of the proble
On 23 Mar 2014 11:47, "Donald Stufft" wrote:
>
>
> On Mar 22, 2014, at 9:33 PM, Brett Cannon wrote:
>
>>
>>
>> On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan
wrote:
>>>
>>> On 23 March 2014 10:08, Antoine Pitrou wrote:
>>> > On Sat, 22 Mar 2014 23:54:37 +0100
>>> > Thomas Wouters wrote:
>>> >>
On Mar 22, 2014, at 9:33 PM, Brett Cannon wrote:
>
>
> On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan wrote:
> On 23 March 2014 10:08, Antoine Pitrou wrote:
> > On Sat, 22 Mar 2014 23:54:37 +0100
> > Thomas Wouters wrote:
> >>
> >> Or not rely on the standard library for their security. Muc
On Mar 22, 2014, at 9:17 PM, Ben Darnell wrote:
> On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan 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 out to a few years by certain major
On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan wrote:
> On 23 March 2014 10:08, Antoine Pitrou wrote:
> > On Sat, 22 Mar 2014 23:54:37 +0100
> > Thomas Wouters wrote:
> >>
> >> Or not rely on the standard library for their security. Much as I
> realize
> >> it is necessary for rudimentary SSL s
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 b
On Mar 22, 2014, at 8:55 PM, Nick Coghlan 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 some of them in
On Sun, 23 Mar 2014 01:40:32 +0100
"Martin v. Löwis" 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
> >> crypt
On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan 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 out to a few years by certain major platform
> vendors), that approach *isn't* working
On 23 March 2014 10:40, "Martin v. Löwis" 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
>>> cryptography-related
On 23 March 2014 10:08, Antoine Pitrou wrote:
> On Sat, 22 Mar 2014 23:54:37 +0100
> Thomas Wouters 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,
>
> Unfortun
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 examp
On Sun, 23 Mar 2014 01:01:38 +0100, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 07:11:07 +1000
> Nick Coghlan wrote:
> > This PEP does *not* grant any general exemptions to the usual backwards
> > compatibility policy for maintenance releases. Instead, it is designed
> > to make it easier to prov
On 23 Mar 2014 10:18, "Christian Heimes" 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 difference.
> >
> >
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 Sun, 23 Mar 2014 10:59:22 +1100
Chris Angelico 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 :-)).
Regards
Antoi
On Sat, 22 Mar 2014 23:54:37 +0100
Thomas Wouters 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 than nothing.
On Sun, 23 Mar 2014 07:11:07 +1000
Nick Coghlan 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 consequences are differe
On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou wrote:
> On Sat, 22 Mar 2014 19:07:51 -0400
> Donald Stufft 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
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 wrote:
>
>> On 22 March 2014 23:49, Donald Stufft wrote:
>> In the case of requests they already have an optional dependency on
>> pyopenssl. It's just many people either don't kn
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 wrote:
>
> In the case of requests they already have an optional dependency on
> pyopenssl. It's just many people either do
On 22 March 2014 23:49, Donald Stufft 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 current flaws.
D
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 wrote:
On Sat, Mar 22, 2014 at 7:08 PM, Nick Coghlan 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 module from a thi
On Sat, Mar 22, 2014, at 16:34, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 09:08:29 +1000
> Nick Coghlan wrote:
> > On 23 March 2014 08:53, Ben Darnell wrote:
> > > I agree wholeheartedly with the sentiment behind this PEP, but I have
> > > concerns about the implementation. If we introduce new
On Sun, 23 Mar 2014 09:08:29 +1000
Nick Coghlan wrote:
> On 23 March 2014 08:53, Ben Darnell 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 appl
On Sat, 22 Mar 2014 19:07:51 -0400
Donald Stufft 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 09:07, Donald Stufft 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 see almost ev
On 23 March 2014 07:32, Benjamin Peterson 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 also address
On 22 March 2014 23:07, Donald Stufft 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 see almost ev
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
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
On 23 March 2014 08:53, Ben Darnell 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 like with the intr
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. A
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
On Sat, Mar 22, 2014 at 11:26 PM, "Martin v. Löwis" wrote:
> 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
> soft
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 unle
On 23 March 2014 08: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 people'
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.c
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 migra
On 23 March 2014 08:16, "Martin v. Löwis" 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 networking code t
In article
,
Nick Coghlan 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
> ==
>
> * What are the risks associated with allowing OpenSSL to be updated to
On 23 March 2014 08:23, "Martin v. Löwis" 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? Unfortuna
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
On 23 March 2014 08:14, "Martin v. Löwis" 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 shoulder a lot of
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 security-o
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 comi
"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" wrote:
>
> Am 22.03.14 22:17, schrieb Cory Benfield:
>> I am 100%, overwhelmingly in favour of this. Without this PEP, Python 2.7
>> i
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 mi
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 wrote:
>
> Does anyone really want to backport features to Python 3.1?
__
-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.
- --
=
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
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?
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
___
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, rath
On Sat, Mar 22, 2014, at 11:10, Antoine Pitrou wrote:
>
> Hello,
>
> I've created the 3.4 category in the buildbots setup:
> http://buildbot.python.org/all/waterfall?category=3.4.stable
>
> I've also retired 3.2 and 3.3 buildbots. Someone will have to update
> the text and URLs at https://www.p
Hello,
I've created the 3.4 category in the buildbots setup:
http://buildbot.python.org/all/waterfall?category=3.4.stable
I've also retired 3.2 and 3.3 buildbots. Someone will have to update
the text and URLs at https://www.python.org/dev/buildbot/.
Regards
Antoine.
_
57 matches
Mail list logo
