Re: [Python-Dev] python 3.4 and pywin32

[Thomas Heller]

Am 22.03.2014 00:25, schrieb Nick Coghlan:

On 22 March 2014 05:46, Thomas Heller  wrote:

With python 3.4 and pywin32 version 218 it is only possible
to import win32com or win32api when pywintypes has been imported before.

I have no idea if this is a bug in pywin32 or in Python 3.4.
Does anyone know more?


Do you have a traceback for the failed imports? There were certainly
non-trivial changes to the import system in 3.4, but without knowing
more details about the failures, it's hard to say what the culprits
might be.


I have created http://bugs.python.org/issue21050.

Thomas

___
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 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 24 Mar 2014 15:25, "Chris Angelico"  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 be an advantage.

And having it break on the official Windows and Mac OS X binaries would
benefit end users, how?

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" releases if they so choose. I'm happier forcing end users to
rely on a redistributor to opt in to a lower security option than I am to
knowingly publish too many additional releases with network security
infrastructure that is (at best) rapidly approaching its use by date.

Cheers,
Nick.

>
> 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/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 466: Proposed policy change for handling network security enhancements

[Chris Angelico]

On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan  wrote:
>
> On 24 Mar 2014 15:25, "Chris Angelico"  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 be an advantage.
>
> And having it break on the official Windows and Mac OS X binaries would
> benefit end users, how?

It wouldn't. And if python.org doesn't publish a Windows binary, then
either the exact same thing will happen, or there'll be one unofficial
SEPython-like build. With only a semi-official SEPython 2.7.10, there
could still be installers for all platforms - if nothing better, a
two-stage installer that fires off the unchanged one and then plonks
its own files elsewhere.

> 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" releases if they so choose. I'm happier forcing end users to rely on a
> redistributor to opt in to a lower security option than I am to knowingly
> publish too many additional releases with network security infrastructure
> that is (at best) rapidly approaching its use by date.

That's how it'd be with an official 2.7 security-enhanced release, and
that would be fine. But even not going that far would have its
benefit; as long as there's a clear definition of what "SEPython
2.7.10" (or whatever it's called) is, a source-only release of those
files would at least help to unify what would otherwise be a mess. But
going the whole way and making a binary installer for an
enhanced-security Python would definitely unify it a lot more.

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] PEP 466 (round 2): Network security enhancements for Python 2.7

[M.-A. Lemburg]

On 23.03.2014 08:07, Nick Coghlan wrote:
> Open Questions
> ==
> 
> * What are the risks associated with allowing OpenSSL to be updated to
>   new feature versions in the Windows and Mac OS X binary installers for
>   maintenance releases? Currently we just upgrade to the appropriate
>   OpenSSL maintenance releases, rather than switching to the latest
>   feature release. In particular, is it possible Windows C extensions may
>   be linking against the Python provided OpenSSL module?

Python's _ssl/_hashlib modules link statically against OpenSSL in
Python 2.7, so the OpenSSL DLLs are not exposed to other extensions.

The OpenSSL version used for 2.7.6 is 0.9.8y.

Upgrading to 1.0.0 or 1.0.1 will likely need a few minor tweaks, but
not cause general breakage - at least that's my experience with
the egenix-pyopenssl distribution.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 24 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-03-29: PythonCamp 2014, Cologne, Germany ...   5 days to go
2014-04-09: PyCon 2014, Montreal, Canada ...   16 days to go
2014-04-29: Python Meeting Duesseldorf ... 36 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 466 (round 2): Network security enhancements for Python 2.7

[Antoine Pitrou]

Le 24/03/2014 10:10, M.-A. Lemburg a écrit :

On 23.03.2014 08:07, Nick Coghlan wrote:

Open Questions
==

* What are the risks associated with allowing OpenSSL to be updated to
   new feature versions in the Windows and Mac OS X binary installers for
   maintenance releases? Currently we just upgrade to the appropriate
   OpenSSL maintenance releases, rather than switching to the latest
   feature release. In particular, is it possible Windows C extensions may
   be linking against the Python provided OpenSSL module?


Python's _ssl/_hashlib modules link statically against OpenSSL in
Python 2.7, so the OpenSSL DLLs are not exposed to other extensions.


I suppose you mean under Windows. Under Linux (and probably OS X too), 
the _ssl module is linked dynamically with OpenSSL:


$ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
linux-vdso.so.1 =>  (0x7fff3f1de000)
	libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 
(0x7fd8853ea000)
	libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fd88501)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fd884df1000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000)
/lib64/ld-linux-x86-64.so.2 (0x7fd885868000)

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 466 (round 2): Network security enhancements for Python 2.7

[M.-A. Lemburg]

On 24.03.2014 13:33, Antoine Pitrou wrote:
> Le 24/03/2014 10:10, M.-A. Lemburg a écrit :
>> On 23.03.2014 08:07, Nick Coghlan wrote:
>>> Open Questions
>>> ==
>>>
>>> * What are the risks associated with allowing OpenSSL to be updated to
>>>new feature versions in the Windows and Mac OS X binary installers for
>>>maintenance releases? Currently we just upgrade to the appropriate
>>>OpenSSL maintenance releases, rather than switching to the latest
>>>feature release. In particular, is it possible Windows C extensions may
>>>be linking against the Python provided OpenSSL module?
>>
>> Python's _ssl/_hashlib modules link statically against OpenSSL in
>> Python 2.7, so the OpenSSL DLLs are not exposed to other extensions.
> 
> I suppose you mean under Windows. 

Yes. Should have included that detail in the email :-)

> Under Linux (and probably OS X too), the _ssl module is linked
> dynamically with OpenSSL:
> 
> $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
> linux-vdso.so.1 =>  (0x7fff3f1de000)
> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 
> (0x7fd8853ea000)
> libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
> (0x7fd88501)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7fd884df1000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000)
> /lib64/ld-linux-x86-64.so.2 (0x7fd885868000)

Right, and it's using the system library, not a private copy - which
can be both good and bad depending on how recent the system's library
version is.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 24 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-03-29: PythonCamp 2014, Cologne, Germany ...   5 days to go
2014-04-09: PyCon 2014, Montreal, Canada ...   16 days to go
2014-04-29: Python Meeting Duesseldorf ... 36 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 466 (round 2): Network security enhancements for Python 2.7

[Nick Coghlan]

On 24 March 2014 22:39, M.-A. Lemburg  wrote:
> On 24.03.2014 13:33, Antoine Pitrou wrote:
>> Under Linux (and probably OS X too), the _ssl module is linked
>> dynamically with OpenSSL:
>>
>> $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
>> linux-vdso.so.1 =>  (0x7fff3f1de000)
>> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 
>> (0x7fd8853ea000)
>> libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
>> (0x7fd88501)
>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
>> (0x7fd884df1000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000)
>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000)
>> /lib64/ld-linux-x86-64.so.2 (0x7fd885868000)
>
> Right, and it's using the system library, not a private copy - which
> can be both good and bad depending on how recent the system's library
> version is.

Even if *we* statically linked OpenSSL on Linux, you can bet distro
vendors would switch it back to dynamic linking. Hence the comment in
the PEP about vendor provided OpenSSL updates mitigating some of the
concerns on Linux (defaulting not all of them though - it's still far
too easy for developers to make mistakes and too hard from them to do
the right thing from a security perspective).

You also reminded me that I need to dig around for and reference Ned's
email about the status of OS X and reference that (OpenSSL upgrades
were a casualty of Apple's anti-GPL crusade, so the OS X installers
were switched to static linking somewhere along the line).

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

[Python-Dev] PEP 466 (round 3): Python 2 network security enhancements

[Nick Coghlan]

And time for round 3 :)

Notable changes:

- removed the higher level networking modules from the scope of the
PEP. They made people nervous, and aren't actually needed to achieved
the desired result (at the higher levels, it's much easier for third
party pure Python modules like requests to step in and fill the gap,
as long as the core SSL infrastructure has been updated)
- dropped the sha module from the exemption and explicitly noted that
both the sha and md5 modules have been deprecated since Python 2.5
- conditional exemptions are now only granted for things that the
security infrastructure depends on, rather than the other way around
- answered the OpenSSL question based on MAL and Ned's feedback
- added the "2.7-legacy-ssl" branch to the proposal (along with some
pointed comments about the development priorities implied by
preferring this branch to the one with the improved security
infrastructure)
- made it even clearer that I consider the situation commercial
redistributor's responsibility to clean up, based on the support
commitments they have made to their users. The PEP is primarily about
changing one specific aspect of our maintenance policies so that the
onus is clearly pushed back on them to fill the gap between what their
customers want and what upstream volunteers are prepared to do for
free - we shouldn't give them the opportunity to hide behind the
excuse that we won't let them fix it upstream.

Cheers,
Nick.


PEP: 466
Title: Network Security Enhancement Exception for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Mar-2014
Post-History: 23-Mar-2014


Abstract


Most CPython tracker issues are classified as errors in behaviour or
proposed enhancements. Most patches to fix behavioural errors are
applied to all active maintenance branches.  Enhancement patches are
restricted to the default branch that becomes the next Python version.

This cadence works reasonably well during Python's normal 18-24 month
feature release cycle, which is still applicable to the Python 3 series.
However, the age of the standard library in Python 2 has now reached a point
where it is sufficiently far behind the state of the art in network security
protocols for it to be causing real problems in commercial use cases
where upgrading to Python 3 in the near term may not be practical.

Accordingly, this PEP relaxes the normal restrictions by allowing
enhancements to be applied in Python 2.7 maintenance releases for standard
library components that have implications for the overall security of the
internet. In particular, the exception will apply to:

* the ``ssl`` module
* the ``hashlib`` module
* the ``hmac`` module
* the components of the ``random`` and ``os`` modules that the above
  modules rely on for cryptographic randomness
* the version of OpenSSL bundled with the binary installers for Windows
  and Mac OS X

Changes to these modules will still need to undergo normal backwards
compatibility assessments, but otherwise they will be kept entirely aligned
with the latest feature release of their Python 3 counterparts. This is
designed to make it easier to implement secure networked software in
Python, even for software that currently needs to remain compatible with
the Python 2 series (which includes a lot of network infrastructure
software).

The development branches will be arranged in such a way that even though
any further Python 2.7 releases published by the core development team
provide updated network security infrastructure, it will remain possible
for downstream redistributors to publish "Python 2.7 with legacy SSL
infrastructure" if they choose to do so.

While this PEP does not make any changes to the core development team's
handling of security-fix-only branches that are no longer in active
maintenance, it *does* recommend that commercial redistributors providing
extended support periods for the Python standard library either adopt a
similar approach to ensuring that the secure networking infrastructure
keeps pace with the evolution of the internet, or else disclaim support
for the use of older versions in roles that involving connecting
directly to the public internet.


Exemption Policy


Under this policy, the following network security related modules are
granted a blanket exemption to the restriction against adding new features
in maintenance releases, for the purpose of keeping their APIs aligned with
their counterparts in the latest feature release of Python 3:

* the ``ssl`` module
* the ``hashlib`` module
* the ``hmac`` module

This exemption applies to *all* proposals to backport backwards compatible
changes in these modules to Python 2.7 maintenance releases. This choice is
made deliberately to ensure that the "feature or fix?" argument isn't simply
replaced by a "security related or not?" argument. These particular modules
are inh

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Skip Montanaro]

On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw  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 level). Now we're in a pickle.
We need to find some way to release something that brings the SSL (and
related) feature set up-to-date. In this thread and Nick's PEP have
read about a few ways this might be accomplished (I probably missed a
couple):

* separate the security-dependent bits out into a separate
"semi"-stdlib which would be served from PyPI
* continue with 2.7.x but admit that there will be some possible
backward incompatibilities with earlier 2.7 versions in the affected
modules
* change the name somehow and jump to two-digit micro version numbers

It seems to me the PyPI option should be a non-starter, as it's
unlikely that you will get the bulk of the 2.7 installations to update
to that version, and if people do install it, they wind up with
possible backward incompatibilities. The second option goes against
the drop-in history of micro releases. The third seems just like
"weasel words" to avoid saying "2.8." Also, a careful reading of the
Zen of Python suggests these solutions might violate a number of its
aphorisms (explicit is better than implicit, simple is better than
complex, practicality beats purity).

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 to be blind adherence? Did someone
administer a blood oath at a recent PyCon?

Pledge-be-damned-ly y'rs,

Skip
___
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 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 24 March 2014 23:49, Skip Montanaro  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 to be blind adherence?

There's a ton of work involved in creating a new feature release, and
there's no way we're going to go through that much drudgery for the
legacy Python 2 series without someone paying for it. Even the more
limited network security infrastructure update proposal in this PEP is
conditional on corporate contributors agreeing to do the heavy
lifting.

> Did someone
> administer a blood oath at a recent PyCon?

As discussed in the PEP, a Python 2.8 release wouldn't actually solve
this problem, so there's no reason for commercial redistributors to
contribute to making it happen.

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 holding back the evolution of internet security standards
is to find a way solve the problem *within* the 2.7 line in such a way
that I can then make the case for also backporting it to 2.6 in a
RHEL6 point release.

I think the proposal currently in round 3 of the PEP is something I
can sell to the Platform Engineering team as a necessary update to
make in a relatively timely fashion (I don't think the situation is
critical yet, but give it another year or two and I'll be a lot more
concerned). By contrast, trying to handle this via a Python 2.8
release would mean I would still have to advocate for us to adopt the
policy in the PEP independently of upstream, and that's not a good
outcome for anyone.

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 466: Proposed policy change for handling network security enhancements

[Skip Montanaro]

On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan  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 holding back the evolution of internet security standards
> is to find a way solve the problem *within* the 2.7 line in such a way
> that I can then make the case for also backporting it to 2.6 in a
> RHEL6 point release.

Thanks for the explanation. I'm still a bit confused though. If there
are backward compatibility issues with the proposed changes (whatever
they turn out to be), are the commercial redistributors still going to
balk at releasing these changes to their customers? From the reading
I've done (this thread and your second iteration of the PEP), it seems
like application developers will have to make some changes to take
advantage of these updated security bits. Is there some path forward
that really makes everything a drop-in improvement, requiring no
change to application code, and breaking nothing that already works?

Skip
___
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 466: Proposed policy change for handling network security enhancements

[R. David Murray]

On Sun, 23 Mar 2014 21:31:12 -0400, Barry Warsaw  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.
> >
> >It'd be nice if SEPython defined a modified sys.version for clarity,
> >but otherwise, it'd be a vanilla Python 2.7.
> 
> That's certainly more in the direction of what I think is an appropriate
> upstream solution.
> 
> The thing is, there isn't one single "what's best for users" resolution.
> There are many, many competing requirements and I think it will be difficult
> to satisfy everyone.  I'm particularly sensitive to complaints of unexpected
> changes between micro releases.

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 create_default_context() to get your context object, you get a
"best practices" level of security *that may change between maintenance
releases*.  If you want things to not change between maintenance releases,
you create your own context object and set its controls appropriately.

In other words, the programmer opts in to maintenance release security
improvements by using create_default_context.  I presume that whatever
comes out of this PEP will use the same approach.

Note: thanks again to Christian Heimes and Antoine Pitrou for this
work.  Without Christian's work, I think we wouldn't even be having
this conversation.  Antoine's earlier work laid essential groundwork,
but by itself I'm not sure that would have been enough to result in calls
for a backport.  It took both of them, with some help from others as well.

--David

[*] I actually don't know if this was discussed on python-dev previously
because I've got a backlog of messages I'm not caught up on.  If it
hasn't been, then doubly good to mention it now, since the first 3.4
maintenance release hasn't happened yet :)
___
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 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 25 March 2014 00:18, Skip Montanaro  wrote:
> On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan  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 holding back the evolution of internet security standards
>> is to find a way solve the problem *within* the 2.7 line in such a way
>> that I can then make the case for also backporting it to 2.6 in a
>> RHEL6 point release.
>
> Thanks for the explanation. I'm still a bit confused though. If there
> are backward compatibility issues with the proposed changes (whatever
> they turn out to be), are the commercial redistributors still going to
> balk at releasing these changes to their customers? From the reading
> I've done (this thread and your second iteration of the PEP), it seems
> like application developers will have to make some changes to take
> advantage of these updated security bits. Is there some path forward
> that really makes everything a drop-in improvement, requiring no
> change to application code, and breaking nothing that already works?

The PEP does not permit backwards compatibility breaks in maintenance
releases, thus people are solely concerned about the increased risk of
regressions created by backporting all of the Python 3 enhancements to
these modules to Python 2.7 and then ensuring that the default
behaviour remains the same as earlier Python 2.7 releases.

I think those folks have their priorities back to front, hence
http://www.python.org/dev/peps/pep-0466/#handling-lower-security-environments-with-low-risk-tolerance
:)

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 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 25 March 2014 00:36, Nick Coghlan  wrote:
> On 25 March 2014 00:18, Skip Montanaro  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" policy as it does in 3.4. But everything
that already exists in 2.7.6 will remain compatible with that
behaviour by default.

The policy change in the PEP won't automagically make networked
software secure - it will just make it a heck of a lot *easier* to
write in Python 2 (or the common subset of Python 2 and Python 3) by
backporting the Python 3.4 enhancements to a 2.7 maintenance release,
and, depending on the relative timing of the releases, likely the
Python 3.5 enhancements to a later maintenance release.

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 466: Proposed policy change for handling network security enhancements

[Cory Benfield]

On 24 March 2014 08:44, Nick Coghlan  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" releases if they so choose. I'm happier forcing end users to rely on a
> redistributor to opt in to a lower security option than I am to knowingly
> publish too many additional releases with network security infrastructure
> that is (at best) rapidly approaching its use by date.

I'm with you here Nick, the default should really be "Python 2.7 with
working TLS", not "Python 2.7 with broken TLS" (my only-slightly
tongue-in-cheek proposed names for the releases). My concern with
having Chris' proposal of an opt-in SEPython release is about
discovery. I suspect most people will never find out about the
SEPython release, meaning that most people will remain on insecure
Python 2.7 distributions. If that happens, requests is essentially
required to continue to support our current TLS model for 2.7 for as
long as we support 2.7, and this PEP would give us no benefit at all.
We're obviously not the only stakeholder here, but it's worth noting.

Cory
___
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 466: Proposed policy change for handling network security enhancements

[Antoine Pitrou]

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 create_default_context() to get your context object, you get a
"best practices" level of security *that may change between maintenance
releases*.  If you want things to not change between maintenance releases,
you create your own context object and set its controls appropriately.


Indeed. Note that this works because create_default_context() is a new 
API, hence it was ok to choose this particular maintenance policy. 
Maintenance policy of 3.4 as a whole (i.e. all other APIs) hasn't changed.


(but some other aspects of SSL configuration, e.g. the default cipher 
list, is also amenable to changes in bugfix releases, as Donald's latest 
commits exemplify; in this case it should stay within the limits of 
reasonable backwards compatibility, i.e. not break any common use case)


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 466 (round 2): Network security enhancements for Python 2.7

[Ned Deily]

In article 
,
 Nick Coghlan  wrote:
> You also reminded me that I need to dig around for and reference Ned's
> email about the status of OS X and reference that (OpenSSL upgrades
> were a casualty of Apple's anti-GPL crusade, so the OS X installers
> were switched to static linking somewhere along the line).

AFAIK, Apple's decision to deprecate OpenSSL has nothing to do with the 
GPL, since OpenSSL isn't GPL-licensed, but rather with OpenSSL API 
compatibility issues:

http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-techno
te-about-openssl-on-os-x

-- 
 Ned Deily,
 n...@acm.org

___
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 466 (round 2): Network security enhancements for Python 2.7

[M.-A. Lemburg]

On 24.03.2014 18:23, Ned Deily wrote:
> In article 
> ,
>  Nick Coghlan  wrote:
>> You also reminded me that I need to dig around for and reference Ned's
>> email about the status of OS X and reference that (OpenSSL upgrades
>> were a casualty of Apple's anti-GPL crusade, so the OS X installers
>> were switched to static linking somewhere along the line).
> 
> AFAIK, Apple's decision to deprecate OpenSSL has nothing to do with the 
> GPL, since OpenSSL isn't GPL-licensed, but rather with OpenSSL API 
> compatibility issues:
> 
> http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-techno
> te-about-openssl-on-os-x

What a strange reasoning. Do they really believe that ABIs don't
change when bumping the library version from 0.9.8 to 1.0.0 ?

OpenSSL's history w/r to backwards compatibility up until 0.9.7 wasn't
the greatest, but since 0.9.8 it has gotten to a level that's very
reliable.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 24 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2014-03-29: PythonCamp 2014, Cologne, Germany ...   5 days to go
2014-04-09: PyCon 2014, Montreal, Canada ...   16 days to go
2014-04-29: Python Meeting Duesseldorf ... 36 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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 466 (round 2): Network security enhancements for Python 2.7

[Nikolaus Rath]

Nick Coghlan  writes:
> Maintainability
> ---
>
> This policy does NOT represent a commitment by volunteer contributors to
> actually backport network security related changes from the Python 3 series
> to the Python 2 series. Rather, it is intended to send a clear signal to
> potential corporate contributors that the core development team are willing
> to review and merge corporate contributions that put this policy into
> effect.

As I understand, at least for smaller patches it is actually more work
to apply a patch than than to write it. With that in mind, are there
really sufficient volunteer resources available to review and merge
these corporate contributions if they come? The issue tracker certainly
does not lack issues with unreviewed and/or unapplied patches...


Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«
___
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] cpython (3.3): Make the various iterators' "setstate" sliently and consistently clip the

[Kristján Valur Jónsson]

Hi there.
I didn’t see the original email in python-dev, sorry about that.

The “setstate” of the iterators is primarily used when unpickling them.  This 
is code that was added during the PyCon sprints 2012, IIRC.
Some iterators already did the silent clipping.
One did not (rangeiter), it raised a valueerror, but it did so at the wrong 
index, so that an iterator could not be set to the “exhausted” state.
Others did no checking, allowing the value to be set to an state that would 
cause undefined behavior.

The change is to prevent the last case.  It is there purely for paranoid 
reasons.  There should be no reason why a iterator should be unpickled such 
that its range and position would be mismatching and no reason to bloat the 
code with diagnostic error code for that, but still, guarding us from undefined 
states is essential.

If you think I should be adding exceptions for this, then I can do that.

The reason this didn’t go through the tracker is that this is code from myself 
and the Stackless sprint that didn’t itself go through the tracker at the time. 
 There really Is no one more qualified to verify this code than myself ☺

K

From: Larry Hastings [mailto:la...@midwinter.com] On Behalf Of Larry Hastings
Sent: 24. mars 2014 01:33
To: Kristján Valur Jónsson
Subject: Fwd: Re: [Python-Dev] cpython (3.3): Make the various iterators' 
"setstate" sliently and consistently clip the



Still no reply on this...?  I'd like to see your answer too.


/arry

 Original Message 
Subject:

Re: [Python-Dev] cpython (3.3): Make the various iterators' "setstate" sliently 
and consistently clip the

Date:

Sat, 08 Mar 2014 08:01:23 +0100

From:

Georg Brandl 

To:

python-dev@python.org



Am 06.03.2014 09:02, schrieb Serhiy Storchaka:

> 05.03.14 17:24, kristjan.jonsson написав(ла):

>> http://hg.python.org/cpython/rev/3b2c28061184

>> changeset:   89477:3b2c28061184

>> branch:  3.3

>> parent:  89475:24d4e52f4f87

>> user:Kristján Valur Jónsson 
>> 

>> date:Wed Mar 05 13:47:57 2014 +

>> summary:

>>Make the various iterators' "setstate" sliently and consistently clip the

>> index.  This avoids the possibility of setting an iterator to an invalid

>> state.

>

> Why indexes are silently clipped instead of raising an exception?

>

>> files:

>>Lib/test/test_range.py|  12 ++

>>Modules/arraymodule.c |   2 +

>>Objects/bytearrayobject.c |  10 ++--

>>Objects/bytesobject.c |  10 ++--

>>Objects/listobject.c  |   2 +

>>Objects/rangeobject.c |  31 +++---

>>Objects/tupleobject.c |   4 +-

>>Objects/unicodeobject.c   |  10 ++--

>>8 files changed, 66 insertions(+), 15 deletions(-)

>

> And it would be better first discuss and review such large changes on

> the bugtracker.



Agreed.  Kristjan, could you please explain a bit more about this change

and use the tracker in the future?



Georg



___

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/larry%40hastings.org


___
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 466: Proposed policy change for handling network security enhancements

[Chris Angelico]

On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield  wrote:
> On 24 March 2014 08:44, Nick Coghlan  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" releases if they so choose. I'm happier forcing end users to rely on a
>> redistributor to opt in to a lower security option than I am to knowingly
>> publish too many additional releases with network security infrastructure
>> that is (at best) rapidly approaching its use by date.
>
> I'm with you here Nick, the default should really be "Python 2.7 with
> working TLS", not "Python 2.7 with broken TLS" (my only-slightly
> tongue-in-cheek proposed names for the releases). My concern with
> having Chris' proposal of an opt-in SEPython release is about
> discovery. I suspect most people will never find out about the
> SEPython release, meaning that most people will remain on insecure
> Python 2.7 distributions. If that happens, requests is essentially
> required to continue to support our current TLS model for 2.7 for as
> long as we support 2.7, and this PEP would give us no benefit at all.
> We're obviously not the only stakeholder here, but it's worth noting.

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 vanilla Python. If backward compatibility is
done carefully (which, from everything I'm seeing here, is the way
it's to be done), there should be absolutely no downside to using
SEPython, except for portability (because now you're depending on it
for security), and corner cases like testing.

Alternatively, it can be done as a separate package: install "python"
to get Python, and install "python-security-patches" or "python-tls"
to get the tweaks - once that's installed, /usr/bin/python becomes
SEPython. Programs can depend on that package to ensure security. That
does have a partial discoverability problem (possibly even worse, as
you could test on a computer that has x, y, z installed, and then
deploy on a brand new computer, and nothing there ever depended on
SEPython, so you're vulnerable without knowing why), but that could be
ameliorated by simply advising people to type "yum install python-tls"
if they want to run any Python programs that use TLS. But I'd be
inclined to the first option; its biggest downside is that installing
"python" installs something other than the "standard stdlib", which
IMO isn't a big problem if (a) it's 100% backward compatible, and (b)
it's semi-official anyway.

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] PEP 466 (round 2): Network security enhancements for Python 2.7

[Nick Coghlan]

On 25 Mar 2014 04:00, "Nikolaus Rath"  wrote:
>
> Nick Coghlan  writes:
> > Maintainability
> > ---
> >
> > This policy does NOT represent a commitment by volunteer contributors to
> > actually backport network security related changes from the Python 3
series
> > to the Python 2 series. Rather, it is intended to send a clear signal to
> > potential corporate contributors that the core development team are
willing
> > to review and merge corporate contributions that put this policy into
> > effect.
>
> As I understand, at least for smaller patches it is actually more work
> to apply a patch than than to write it. With that in mind, are there
> really sufficient volunteer resources available to review and merge
> these corporate contributions if they come? The issue tracker certainly
> does not lack issues with unreviewed and/or unapplied patches...

At least to start, this would likely be about seeking more upstream time
for existing core contributors.

Beyond that, PEP 462 covers another way for corporate users to give back -
if they want to build massive commercial enterprises on our software, they
can help maintain and upgrade the infrastructure that makes it possible in
the first place.

It's potentially worth reading some of the board candidate statements for
this year, particularly mine and Van's:

https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014

The lack of paid development time for CPython compared to similarly
critical projects like the Linux kernel and OpenStack is of grave concern
to me personally from a volunteer burnout perspective, and it was a problem
at least Van and I were already specifically wanting to address over the
next year or so. Over the course of writing the PEP I realised that the
situation with the Python 2 network security modules is a perfect example
of the kinds of problems that the current lack of upstream engagement and
investment can cause.

Cheers,
Nick.

>
>
> Best,
> -Nikolaus
>
> --
> Encrypted emails preferred.
> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
>
>  »Time flies like an arrow, fruit flies like a Banana.«
> ___
> 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 466 (round 2): Network security enhancements for Python 2.7

[Donald Stufft]

On Mar 24, 2014, at 5:38 PM, Nick Coghlan  wrote:

> 
> On 25 Mar 2014 04:00, "Nikolaus Rath"  wrote:
> >
> > Nick Coghlan  writes:
> > > Maintainability
> > > ---
> > >
> > > This policy does NOT represent a commitment by volunteer contributors to
> > > actually backport network security related changes from the Python 3 
> > > series
> > > to the Python 2 series. Rather, it is intended to send a clear signal to
> > > potential corporate contributors that the core development team are 
> > > willing
> > > to review and merge corporate contributions that put this policy into
> > > effect.
> >
> > As I understand, at least for smaller patches it is actually more work
> > to apply a patch than than to write it. With that in mind, are there
> > really sufficient volunteer resources available to review and merge
> > these corporate contributions if they come? The issue tracker certainly
> > does not lack issues with unreviewed and/or unapplied patches...
> 
> At least to start, this would likely be about seeking more upstream time for 
> existing core contributors.
> 
> Beyond that, PEP 462 covers another way for corporate users to give back - if 
> they want to build massive commercial enterprises on our software, they can 
> help maintain and upgrade the infrastructure that makes it possible in the 
> first place.
> 
> It's potentially worth reading some of the board candidate statements for 
> this year, particularly mine and Van's:
> 
> https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014
> 
> The lack of paid development time for CPython compared to similarly critical 
> projects like the Linux kernel and OpenStack is of grave concern to me 
> personally from a volunteer burnout perspective, and it was a problem at 
> least Van and I were already specifically wanting to address over the next 
> year or so. Over the course of writing the PEP I realised that the situation 
> with the Python 2 network security modules is a perfect example of the kinds 
> of problems that the current lack of upstream engagement and investment can 
> cause.
> 
> Cheers,
> Nick.
> 
> >
> >
> > Best,
> > -Nikolaus
> >
> > --
> > Encrypted emails preferred.
> > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
> >
> >  »Time flies like an arrow, fruit flies like a Banana.«
> > ___
> > 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/donald%40stufft.io

I'd like to just go on a brief tangent here.

While I totally agree that it would be incredibly awesome if more companies put
dedicated time into developing and maintaining CPython I don't think pushing
all the blame on to them is accurate.

The attitude towards security issues and backwards compatibility has a somewhat
equal share in the causes of the aging security infrastructure of the 2.x line.
Now this PEP, if accepted, does a lot to resolve the largest offenders of this
policy (and there has been some signs lately that perhaps going forward this
will be better) but I think it is not doing anyone a favor if we just point
fingers *over there* and claim the fault lies with someone else doing or not
doing something.

I *don't* want to disparage anyone or anything of that like, mostly to say that
while of course increased resources from corporate users would help the 
situation
immensely but that additionally there is a reasonably sized contingent of
influential members who still want to treat Python as a hobbyist project and
not a critical piece of the infrastructure of the Internet as a whole. I
*don't* want to get help from downstream users, especially on important but
"boring" or hard issues such as security, and then have them feel shutdown and
unable to actually get anything done as others who have attempted to resolve
some of these issues in the past have had happen to them.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Python-Dev] RFE 20469: ssl.getpeercert() should include extensions

[Andrew M. Hettinger]

I thought I'd wait until the 3.4 release before I bothered asking about
this: http://bugs.python.org/issue20469

I don't think I'm qualified to actually be writing code for the ssl module,
but is there anything else that I can do to help?

I could probably put together a demonstration-case if that would be
helpful.___
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] RFE 20469: ssl.getpeercert() should include extensions

[Terry Reedy]

On 3/24/2014 6:51 PM, Andrew M. Hettinger wrote:

I thought I'd wait until the 3.4 release before I bothered asking about
this: http://bugs.python.org/issue20469

I don't think I'm qualified to actually be writing code for the ssl
module, but is there anything else that I can do to help?

I could probably put together a demonstration-case if that would be
helpful.


Yes. Comment on issue. 'test needed' is intentionally listed as the 
first stage.


--
Terry Jan Reedy

___
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 466 (round 2): Network security enhancements for Python 2.7

[Terry Reedy]

On 3/24/2014 7:04 PM, Donald Stufft wrote:


On Mar 24, 2014, at 5:38 PM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:



Beyond that, PEP 462 covers another way for corporate users to give
back - if they want to build massive commercial enterprises on our
software, they can help maintain and upgrade the infrastructure that
makes it possible in the first place.

It's potentially worth reading some of the board candidate statements
for this year, particularly mine and Van's:

https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014


I read all of them.


The lack of paid development time for CPython compared to similarly
critical projects like the Linux kernel and OpenStack is of grave
concern to me personally from a volunteer burnout perspective,


I am glad to read that. Some of the expert professional core developers 
scoff at me being burned out from News Merge Hell and push race losses.


>> and it

was a problem at least Van and I were already specifically wanting to
address over the next year or so. Over the course of writing the PEP I
realised that the situation with the Python 2 network security modules
is a perfect example of the kinds of problems that the current lack of
upstream engagement and investment can cause.



I'd like to just go on a brief tangent here.

While I totally agree that it would be incredibly awesome if more
companies put
dedicated time into developing and maintaining CPython I don't think pushing
all the blame on to them is accurate.


For all I know, PSF has not yet asked in the right way, whatever that 
would be.



will be better) but I think it is not doing anyone a favor if we just point
fingers *over there* and claim the fault lies with someone else doing or not
doing something.


I agree that we should better figure out what to go going forward.


I *don't* want to disparage anyone or anything of that like, mostly to
say that
while of course increased resources from corporate users would help the
situation
immensely but that additionally there is a reasonably sized contingent of
influential members who still want to treat Python as a hobbyist project and
not a critical piece of the infrastructure of the Internet as a whole.


I find that surprising as I do not personally know any such people. To 
me, Python is both. My only objection is to corporatists who want to 
exclude amateur and hobbyist projects, for instance from PyPI (which I 
believe started as a hobbyist project).


I personally would like someone paid full-time to upgrade the commit 
infrastructure, as soon possible. to make current committers more 
productive and make becoming a committer more attractive. Then I would 
like 2 people paid, one for doc issues, one to code, to work on the 
backlog of contributed patches. I know that are people who are not 
contributing any more because their previous contributions have sat 
unattended to.



I
*don't* want to get help from downstream users, especially on important but
"boring" or hard issues such as security, and then have them feel
shutdown and
unable to actually get anything done as others who have attempted to resolve
some of these issues in the past have had happen to them.


Just from reading pydev, I am not familiar with such events and cannot 
comment.


--
Terry Jan Reedy

___
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 466: Proposed policy change for handling network security enhancements

[Ben Darnell]

On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan  wrote:

>
> On 24 Mar 2014 15:25, "Chris Angelico"  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 be an advantage.
>
> And having it break on the official Windows and Mac OS X binaries would
> benefit end users, how?
>
> 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" releases if they so choose. I'm happier forcing end users to
> rely on a redistributor to opt in to a lower security option than I am to
> knowingly publish too many additional releases with network security
> infrastructure that is (at best) rapidly approaching its use by date.
>

I am strongly against allowing downstream distributors that choice.  Unless
the security-enhanced variant of Python 2.7 quickly and completely
overtakes all previous versions, we will be creating a compatibility
problem between the two variants of Python 2.7.  I believe that the changes
motivating this PEP can be made with minimal backwards-incompatibility risk
and (if the PEP is accepted) we should use all the leverage at our disposal
to drive adoption.  The risk is not backwards incompatibility, it is
ambiguity of what Python 2.7 means. If changes under this PEP would result
in any distributors rationally remaining at Python 2.7.6, then the result
of any such changes should be labelled Python 2.8.

-Ben


> Cheers,
> Nick.
>
> >
> > 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/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/ben%40bendarnell.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 466: Proposed policy change for handling network security enhancements

[MRAB]

On 2014-03-25 01:29, Ben Darnell wrote:

On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:


On 24 Mar 2014 15:25, "Chris Angelico" mailto: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 be an advantage.

And having it break on the official Windows and Mac OS X binaries
would benefit end users, how?

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" releases if they so choose. I'm happier
forcing end users to rely on a redistributor to opt in to a lower
security option than I am to knowingly publish too many additional
releases with network security infrastructure that is (at best)
rapidly approaching its use by date.


I am strongly against allowing downstream distributors that choice.
  Unless the security-enhanced variant of Python 2.7 quickly and
completely overtakes all previous versions, we will be creating a
compatibility problem between the two variants of Python 2.7.  I believe
that the changes motivating this PEP can be made with minimal
backwards-incompatibility risk and (if the PEP is accepted) we should
use all the leverage at our disposal to drive adoption.  The risk is not
backwards incompatibility, it is ambiguity of what Python 2.7 means. If
changes under this PEP would result in any distributors rationally
remaining at Python 2.7.6, then the result of any such changes should be
labelled Python 2.8.


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").
___
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 466 (round 3): Python 2 network security enhancements

[Terry Reedy]

On 3/24/2014 9:43 AM, Nick Coghlan wrote:

And time for round 3 :)


And round 3 of my response: contrary to what I said before, I now think 
that the base proposal should be the simplest possible: selectively (and 
minimally) waive the 'no-enhancement in maintenance release policy' for 
future 2.7 releases because certain internet security features have 
become dangerously obsolete and socially irresponsible and because 2.7 
is exceptional in not having a followup version and will be exceptional 
in its amount and length of use.


When we do a brown bag release in 1 to 4 weeks, we break the normal 
maintenance interval. We create a nuisance for those who already 
downloaded the replaced release. We create a nuisance for those who test 
with each maintenance release. But the reason we do that is because we 
also have a no-regression policy and we decide that the nuisance of a 
quick release is over-ridden by the nuisance of regression -- even if 
doing so increases the net user pain over not doing the quick release. 
(I personally have not been affected by regressions so far but have been 
affected by the new-release nuisance.)


In the area of internet security, standing still for too long is a form 
of regression  -- in terms of effectiveness.


An enhanced version of 2.7 will be a bit of a nuisance, but only for the 
people who use the enhancements. The decreasing effectiveness of static 
security modules will also be a nuisance.


--
Terry Jan Reedy

___
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