<div dir="ltr">Thanks, Nick. I hereby approve this PEP. You can update the status yourself. Congrats!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 3:04 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've reworded the PEP to make it clear it is now just about<br>
backporting a specific set of enhancements to 2.7.7, as well as<br>
switching to updating to new OpenSSL feature releases in the binary<br>
installers.<br>
<br>
The idea of an open ended backport policy is now listed as a rejected<br>
variant. I believe that change addresses Guido's main remaining<br>
concern, so I think this version is ready for pronouncement.<br>
<br>
Regards,<br>
Nick.<br>
<br>
========================================<br>
PEP: 466<br>
Title: Network Security Enhancements for Python 2.7.7<br>
Version: $Revision$<br>
Last-Modified: $Date$<br>
Author: Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>>,<br>
Status: Draft<br>
Type: Informational<br>
Content-Type: text/x-rst<br>
Created: 23-Mar-2014<br>
Post-History: 23-Mar-2014, 24-Mar-2014, 25-Mar-2014, 26-Mar-2014, 16-Apr-2014<br>
<br>
<br>
Abstract<br>
========<br>
<br>
Most CPython tracker issues are classified as errors in behaviour or<br>
proposed enhancements. Most patches to fix behavioural errors are<br>
applied to all active maintenance branches. Enhancement patches are<br>
restricted to the default branch that becomes the next Python version.<br>
<br>
This cadence works reasonably well during Python's normal 18-24 month<br>
feature release cycle, which is still applicable to the Python 3 series.<br>
However, the age of the standard library in Python 2 has now reached a point<br>
where it is sufficiently far behind the state of the art in network security<br>
protocols for it to be causing real problems in use cases where upgrading to<br>
Python 3 in the near term may not be feasible.<br>
<br>
In recognition of the additional practical considerations that have arisen<br>
during the 4+ year maintenance cycle for Python 2.7, this PEP allows a<br>
critical set of network security related features to be backported from<br>
Python 3.4 to the upcoming Python 2.7.7 maintenance release.<br>
<br>
While this PEP does not make any changes to the core development team's<br>
handling of security-fix-only branches that are no longer in active<br>
maintenance, it *does* recommend that commercial redistributors providing<br>
extended support periods for the Python standard library either backport<br>
these features to their supported versions, or else explicitly disclaim<br>
support for the use of older versions in roles that involve connecting<br>
directly to the public internet.<br>
<br>
<br>
New security related features in Python 2.7.7<br>
=============================================<br>
<br>
Under this proposal, the following features will be backported from Python<br>
3.4 to the upcoming Python 2.7.7 maintenance release:<br>
<br>
* in the ``os`` module:<br>
<br>
* persistent file descriptor for ``os.urandom()``.<br>
<br>
* in the ``hmac`` module:<br>
<br>
* constant time comparison function (``hmac.compare_digest()``).<br>
<br>
* in the ``hashlib`` module:<br>
<br>
* password hashing function (``hashlib.pbkdf2_hmac()``).<br>
* details of hash algorithm availability (``hashlib.algorithms_guaranteed``<br>
and ``hashlib.algorithms_available``).<br>
<br>
* in the ``ssl`` module:<br>
<br>
* this module is almost entirely synchronised with its Python 3<br>
counterpart, bringing TLSv1.x settings, SSLContext manipulation, Server<br>
Name Indication, access to platform certificate stores, standard<br>
library support for peer hostname validation and more to the Python 2<br>
series.<br>
* the only ``ssl`` module features *not* backported under this policy are<br>
the ``ssl.RAND_*`` functions that provide access to OpenSSL's random<br>
number generation capabilities - use ``os.urandom()`` instead.<br>
<br>
As a general change in maintenance policy, permission is also granted to<br>
upgrade to newer feature releases of OpenSSL when preparing the binary<br>
installers for new maintenance releases of Python 2.7.<br>
<br>
This PEP does NOT propose a general exception for backporting new features<br>
to Python 2.7 - every new feature proposed for backporting will still need<br>
to be justified independently. In particular, it will need to be explained<br>
why relying on and independently updated backport on the Python Package Index<br>
instead is not an acceptable solution.<br>
<br>
<br>
Backwards compatibility considerations<br>
======================================<br>
<br>
As in the Python 3 series, the backported ``ssl.create_default_context()``<br>
API is granted a backwards compatibility exemption that permits the<br>
protocol, options, cipher and other settings of the created SSL context to<br>
be updated in maintenance releases to use higher default security settings.<br>
This allows them to appropriately balance compatibility and security at the<br>
time of the maintenance release, rather than at the time of the original<br>
feature release.<br>
<br>
This PEP does *not* grant any other exemptions to the usual backwards<br>
compatibility policy for maintenance releases. Instead, by explicitly<br>
encouraging the use of feature based checks, it is designed to make it easier<br>
to write more secure cross-version compatible Python software, while still<br>
limiting the risk of breaking currently working software when upgrading to<br>
a new Python 2.7 maintenance release.<br>
<br>
In all cases where this proposal allows new features to be backported to<br>
the Python 2.7 release series, it is possible to write cross-version<br>
compatible code that operates by "feature detection" (for example, checking<br>
for particular attributes in a module), without needing to explicitly check<br>
the Python version.<br>
<br>
It is then up to library and framework code to provide an appropriate warning<br>
and fallback behaviour if a desired feature is found to be missing. While<br>
some especially security sensitive software MAY fail outright if a desired<br>
security feature is unavailable, most software SHOULD instead emit a warning<br>
and continue operating using a slightly degraded security configuration.<br>
<br>
The backported APIs allow library and application code to perform the<br>
following actions after detecting the presence of a relevant<br>
network security related feature:<br>
<br>
* explicitly opt in to more secure settings (to allow the use of enhanced<br>
security features in older maintenance releases of Python with less<br>
secure default behaviour)<br>
* explicitly opt in to less secure settings (to allow the use of newer Python<br>
feature releases in lower security environments)<br>
* determine the default setting for the feature (this MAY require explicit<br>
Python version checks to determine the Python feature release, but DOES<br>
NOT require checking for a specific maintenance release)<br>
<br>
Security related changes to other modules (such as higher level networking<br>
libraries and data format processing libraries) will continue to be made<br>
available as backports and new modules on the Python Package Index, as<br>
independent distribution remains the preferred approach to handling<br>
software that must continue to evolve to handle changing development<br>
requirements independently of the Python 2 standard library. Refer to<br>
the `Motivation and Rationale`_ section for a review of the characteristics<br>
that make the secure networking infrastructure worthy of special<br>
consideration.<br>
<br>
<br>
OpenSSL compatibility<br>
---------------------<br>
<br>
Under this proposal, OpenSSL may be upgraded to more recent feature releases<br>
in Python 2.7 maintenance releases. On Linux and most other POSIX systems,<br>
the specific version of OpenSSL used already varies, as CPython dynamically<br>
links to the system provided OpenSSL library by default.<br>
<br>
For the Windows binary installers, the ``_ssl`` and ``_hashlib`` modules are<br>
statically linked with OpenSSL and the associated symbols are not exported.<br>
Marc-Andre Lemburg indicates that updating to newer OpenSSL releases in the<br>
``egenix-pyopenssl`` binaries has not resulted in any reported compatibility<br>
issues [3]_<br>
<br>
The Mac OS X binary installers historically followed the same policy as<br>
other POSIX installations and dynamically linked to the Apple provided<br>
OpenSSL libraries. However, Apple has now ceased updating these<br>
cross-platform libraries, instead requiring that even cross-platform<br>
developers adopt Mac OS X specific interfaces to access up to date security<br>
infrastructure on their platform. Accordingly, and independently of this<br>
PEP, the Mac OS X binary installers were already going to be switched to<br>
statically linker newer versions of OpenSSL [4]_<br>
<br>
<br>
Other Considerations<br>
====================<br>
<br>
Maintainability<br>
---------------<br>
<br>
A number of developers, including Alex Gaynor and Donald Stufft, have<br>
expressed interest in carrying out the feature backports covered by this<br>
policy, and assisting with any additional maintenance burdens that arise<br>
in the Python 2 series as a result.<br>
<br>
Steve Dower and Brian Curtin have offered to help with the creation of the<br>
Windows installers, allowing Martin von Löwis the opportunity to step back<br>
from the task of maintaining the 2.7 Windows installer.<br>
<br>
This PEP is primarily about establishing the consensus needed to allow them<br>
to carry out this work. For other core developers, this policy change<br>
shouldn't impose any additional effort beyond potentially reviewing the<br>
resulting patches for those developers specifically interested in the<br>
affected modules.<br>
<br>
<br>
Security releases<br>
-----------------<br>
<br>
This PEP does not propose any changes to the handling of security<br>
releases - those will continue to be source only releases that<br>
include only critical security fixes.<br>
<br>
However, the recommendations for library and application developers are<br>
deliberately designed to accommodate commercial redistributors that choose<br>
to apply these changes to additional Python release series that are either<br>
in security fix only mode, or have been declared "end of life" by the core<br>
development team.<br>
<br>
Whether or not redistributors choose to exercise that option will be up<br>
to the individual redistributor.<br>
<br>
<br>
Integration testing<br>
-------------------<br>
<br>
Third party integration testing services should offer users the ability<br>
to test against multiple Python 2.7 maintenance releases (at least 2.7.6<br>
and 2.7.7+), to ensure that libraries, frameworks and applications can still<br>
test their handling of the legacy security infrastructure correctly (either<br>
failing or degrading gracefully, depending on the security sensitivity of<br>
the software), even after the features covered in this proposal have been<br>
backported to the Python 2.7 series.<br>
<br>
<br>
Handling lower security environments with low risk tolerance<br>
------------------------------------------------------------<br>
<br>
For better or for worse (mostly worse), there are some environments where<br>
the risk of latent security defects is more tolerated than even a slightly<br>
increased risk of regressions in maintenance releases. This proposal largely<br>
excludes these environments from consideration where the modules covered by<br>
the exemption are concerned - this approach is entirely inappropriate for<br>
software connected to the public internet, and defence in depth security<br>
principles suggest that it is not appropriate for most private networks<br>
either.<br>
<br>
Downstream redistributors may still choose to cater to such environments,<br>
but they will need to handle the process of downgrading the security<br>
related modules and doing the associated regression testing themselves.<br>
The main CPython continuous integration infrastructure will not cover this<br>
scenario.<br>
<br>
<br>
Motivation and Rationale<br>
========================<br>
<br>
The creation of this PEP was prompted primarily by the aging SSL support in<br>
the Python 2 series. As of March 2014, the Python 2.7 SSL module is<br>
approaching four years of age, and the SSL support in the still popular<br>
Python 2.6 release had its feature set locked six years ago.<br>
<br>
These are simply too old to provide a foundation that can be recommended<br>
in good conscience for secure networking software that operates over the<br>
public internet, especially in an era where it is becoming quite clearly<br>
evident that advanced persistent security threats are even more widespread<br>
and more indiscriminate in their targeting than had previously been<br>
understood. While they represented reasonable security infrastructure in<br>
their time, the state of the art has moved on, and we need to investigate<br>
mechanisms for effectively providing more up to date network security<br>
infrastructure for users that, for whatever reason, are not currently in<br>
a position to migrate to Python 3.<br>
<br>
While the use of the system OpenSSL installation addresses many of these<br>
concerns on Linux platforms, it doesn't address all of them (in particular,<br>
it is still difficult for sotware to explicitly require some higher level<br>
security settings). The standard library support can be bypassed by using a<br>
third party library like PyOpenSSL or Pycurl, but this still results in a<br>
security problem, as these can be difficult dependencies to deploy, and many<br>
users will remain unaware that they might want them. Rather than explaining<br>
to potentially naive users how to obtain and use these libraries, it seems<br>
better to just fix the included batteries.<br>
<br>
In the case of the binary installers for Windows and Mac OS X that are<br>
published on <a href="http://python.org" target="_blank">python.org</a>, the version of OpenSSL used is entirely within<br>
the control of the Python core development team, but is currently limited<br>
to OpenSSL maintenance releases for the version initially shipped with the<br>
corresponding Python feature release.<br>
<br>
With increased popularity comes increased responsibility, and this proposal<br>
aims to acknowledge the fact that Python's popularity and adoption is at a<br>
sufficiently high level that some of our design and policy decisions have<br>
significant implications beyond the Python development community.<br>
<br>
As one example, the Python 2 ``ssl`` module does not support the Server<br>
Name Indication standard. While it is possible to obtain SNI support<br>
by using the third party ``requests`` client library, actually doing so<br>
currently requires using not only ``requests`` and its embedded dependencies,<br>
but also half a dozen or more additional libraries. The lack of support<br>
in the Python 2 series thus serves as an impediment to making effective<br>
use of SNI on servers, as Python 2 clients will frequently fail to handle<br>
it correctly.<br>
<br>
Another more critical example is the lack of SSL hostname matching in the<br>
Python 2 standard library - it is currently necessary to rely on a third<br>
party library, such as ``requests`` or ``backports.ssl_match_hostname`` to<br>
obtain that functionality in Python 2.<br>
<br>
The Python 2 series also remains more vulnerable to remote timing attacks<br>
on security sensitive comparisons than the Python 3 series, as it lacks a<br>
standard library equivalent to the timing attack resistant<br>
``hmac.compare_digest()`` function. While appropriate secure comparison<br>
functions can be implemented in third party extensions, many users don't<br>
even consider the issue and use ordinary equality comparisons instead<br>
- while a standard library solution doesn't automatically fix that problem,<br>
it *does* make the barrier to resolution much lower once the problem is<br>
pointed out.<br>
<br>
Python 2.7 represents the only long term maintenance release the core<br>
development team has provided, and it is natural that there will be things<br>
that worked over a historically shorter maintenance lifespan that don't work<br>
over this longer support period. In the specific case of the problem<br>
described in this PEP, the simplest available solution is to acknowledge<br>
that long term maintenance of network security related modules *requires*<br>
the ability to add new features, even while retaining backwards compatibility<br>
for existing interfaces.<br>
<br>
For those familiar with it, it is worth comparing the approach described in<br>
this PEP with Red Hat's handling of its long term open source support<br>
commitments: it isn't the RHEL 6.0 release itself that receives 10 years<br>
worth of support, but the overall RHEL 6 *series*. The individual RHEL 6.x<br>
point releases within the series then receive a wide variety of new<br>
features, including security enhancements, all while meeting strict<br>
backwards compatibility guarantees for existing software. The proposal<br>
covered in this PEP brings our approach to long term maintenance more into<br>
line with this precedent - we retain our strict backwards compatibility<br>
requirements, but make an exception to the restriction against adding new<br>
features.<br>
<br>
To date, downstream redistributors have respected our upstream policy of<br>
"no new features in Python maintenance releases". This PEP explicitly<br>
accepts that a more nuanced policy is appropriate in the case of network<br>
security related features, and the specific change it describes is<br>
deliberately designed such that it is potentially suitable for Red Hat<br>
Enterprise Linux and its downstream derivatives.<br>
<br>
<br>
Rejected alternative: just advise developers to migrate to Python 3<br>
-------------------------------------------------------------------<br>
<br>
This alternative represents the status quo. Unfortunately, it has proven<br>
to be unworkable in practice, as the backwards compatibility implications<br>
mean that this is a non-trivial migration process for large applications<br>
and integration projects. While the tools for migration have evolved to<br>
a point where it is possible to migrate even large applications<br>
opportunistically and incrementally (rather than all at once) by updating<br>
code to run in the large common subset of Python 2 and Python 3, using the<br>
most recent technology often isn't a priority in commercial environments.<br>
<br>
Previously, this was considered an acceptable harm, as while it was an<br>
unfortunate problem for the affected developers to have to face, it was<br>
seen as an issue between them and their management chain to make the case<br>
for infrastructure modernisation, and this case would become naturally<br>
more compelling as the Python 3 series evolved.<br>
<br>
However, now that we're fully aware of the impact the limitations of the<br>
Python 2 standard library may be having on the evolution of internet<br>
security standards, I no longer believe that it is reasonable to expect<br>
platform and application developers to resolve all of the latent defects<br>
in an application's Unicode correctness solely in order to gain access to<br>
the network security enhancements already available in Python 3.<br>
<br>
While Ubuntu (and to some extent Debian as well) are committed to porting all<br>
default system services and scripts to Python 3, and to removing Python 2<br>
from its default distribution images (but not from its archives), this is<br>
a mammoth task and won't be completed for the Ubuntu 14.04 LTS release<br>
(at least for the desktop image - it may be achieved for the mobile and<br>
server images).<br>
<br>
Fedora has even more work to do to migrate, and it will take a non-trivial<br>
amount of time to migrate the relevant infrastructure components. While<br>
Red Hat are also actively working to make it easier for users to use more<br>
recent versions of Python on our stable platforms, it's going to take time<br>
for those efforts to start having an impact on end users' choice of version,<br>
and any such changes also don't benefit the core platform infrastructure<br>
that runs in the integrated system Python by necessity.<br>
<br>
The OpenStack migration to Python 3 is also still in its infancy, and even<br>
though that's a project with an extensive and relatively robust automated<br>
test suite, it's still large enough that it is going to take quite some time<br>
to migrate fully to a Python 2/3 compatible code base.<br>
<br>
And that's just three of the highest profile open source projects that<br>
make heavy use of Python. Given the likely existence of large amounts of<br>
legacy code that lacks the kind of automated regression test suite needed<br>
to help support a migration from Python 2 to Python 3, there are likely to<br>
be many cases where reimplementation (perhaps even in Python 3) proves<br>
easier than migration. The key point of this PEP is that those situations<br>
affect more people than just the developers and users of the affected<br>
application: the existence of clients and servers with outdated network<br>
security infrastructure becomes something that developers of secure<br>
networked services need to take into account as part of their security<br>
design, and that's a problem that inhibits the adoption of better security<br>
standards.<br>
<br>
As Terry Reedy noted, if we try to persist with the status quo, the likely<br>
outcome is that commercial redistributors will attempt to do something<br>
like this on behalf of their customers *anyway*, but in a potentially<br>
inconsistent and ad hoc manner. By drawing the scope definition process<br>
into the upstream project we are in a better position to influence the<br>
approach taken to address the situation and to help ensure some consistency<br>
across redistributors.<br>
<br>
The problem is real, so *something* needs to change, and this PEP describes<br>
my preferred approach to addressing the situation.<br>
<br>
<br>
Rejected alternative: create and release Python 2.8<br>
---------------------------------------------------<br>
<br>
With sufficient corporate support, it likely *would* be possible to create<br>
and release Python 2.8 (it's highly unlikely such a project would garner<br>
enough interest to be achievable with only volunteers). However, this<br>
wouldn't actually solve the problem, as the aim is to provide a *relatively<br>
low impact* way to incorporate enhanced security features into integrated<br>
products and deployments that make use of Python 2.<br>
<br>
Upgrading to a new Python feature release would mean both more work for the<br>
core development team, as well as a more disruptive update that most<br>
potential end users would likely just skip entirely.<br>
<br>
Attempting to create a Python 2.8 release would also bring in suggestions<br>
to backport many additional features from Python 3 (such as ``tracemalloc``<br>
and the improved coroutine support), making the migration from Python 2.7<br>
to this hypothetical 2.8 release even riskier and more disruptive.<br>
<br>
This is not a recommended approach, as it would involve substantial<br>
additional work for a result that is actually less effective in achieving<br>
the original aim (which is to eliminate the current widespread use of the<br>
aging network security infrastructure in the Python 2 series).<br>
<br>
Furthermore, while I can't make any commitments to actually addressing<br>
this issue on Red Hat platforms, I *can* categorically rule out the idea<br>
of a Python 2.8 being of any use to me in even attempting to get it<br>
addressed.<br>
<br>
<br>
Rejected alternative: distribute the security enhancements via PyPI<br>
-------------------------------------------------------------------<br>
<br>
While this initially appears to be an attractive and easier to manage<br>
approach, it actually suffers from several significant problems.<br>
<br>
Firstly, this is complex, low level, cross-platform code that integrates<br>
with the underlying operating system across a variety of POSIX platforms<br>
(including Mac OS X) and Windows. The CPython BuildBot fleet is already set<br>
up to handle continuous integration in that context, but most of the<br>
freely available continuous integration services just offer Linux, and<br>
perhaps paid access to Windows. Those services work reasonably well for<br>
software that largely runs on the abstraction layers offered by Python and<br>
other dynamic languages, as well as the more comprehensive abstraction<br>
offered by the JVM, but won't suffice for the kind of code involved here.<br>
<br>
The OpenSSL dependency for the network security support also qualifies as<br>
the kind of "complex binary dependency" that isn't yet handled well by the<br>
``pip`` based software distribution ecosystem. Relying on a third party<br>
binary dependency also creates potential compatibility problems for ``pip``<br>
when running on other interpreters like ``PyPy``.<br>
<br>
Another practical problem with the idea is the fact that ``pip`` itself<br>
relies on the ``ssl`` support in the standard library (with some additional<br>
support from a bundled copy of ``requests``, which in turn bundles<br>
``backport.ssl_match_hostname``), and hence would require any replacement<br>
module to also be bundled within ``pip``. This wouldn't pose any<br>
insurmountable difficulties (it's just another dependency to vendor), but<br>
it *would* mean yet another copy of OpenSSL to keep up to date.<br>
<br>
This approach also has the same flaw as all other "improve security by<br>
renaming things" approaches: they completely miss the users who most need<br>
help, and raise significant barriers against being able to encourage users<br>
to do the right thing when their infrastructure supports it (since<br>
"use this other module" is a much higher impact change than "turn on this<br>
higher security setting"). Deprecating the aging SSL infrastructure in the<br>
standard library in favour of an external module would be even more user<br>
hostile than accepting the slightly increased risk of regressions associated<br>
with upgrading it in place.<br>
<br>
Last, but certainly not least, this approach suffers from the same problem<br>
as the idea of doing a Python 2.8 release: likely not solving the actual<br>
problem. Commercial redistributors of Python are set up to redistribute<br>
*Python*, and a pre-existing set of additional packages. Getting new<br>
packages added to the pre-existing set *can* be done, but means approaching<br>
each and every redistributor and asking them to update their<br>
repackaging process accordingly. By contrast, the approach described in<br>
this PEP would require redistributors to deliberately *opt out* of the<br>
security enhancements by deliberately downgrading the provided network<br>
security infrastructure, which most of them are unlikely to do.<br>
<br>
<br>
Rejected variant: provide a "legacy SSL infrastructure" branch<br>
--------------------------------------------------------------<br>
<br>
Earlier versions of this PEP included the concept of a ``2.7-legacy-ssl``<br>
branch that preserved the exact feature set of the Python 2.7.6 network<br>
security infrastructure.<br>
<br>
In my opinion, anyone that actually wants this is almost certainly making a<br>
mistake, and if they insist they really do want it in their specific<br>
situation, they're welcome to either make it themselves or arrange for a<br>
downstream redistributor to make it for them.<br>
<br>
If they are made publicly available, any such rebuilds should be referred to<br>
as "Python 2.7 with Legacy SSL" to clearly distinguish them from the official<br>
Python 2.7 releases that include more up to date network security<br>
infrastructure.<br>
<br>
After the first Python 2.7 maintenance release that implements this PEP, it<br>
would also be appropriate to refer to Python 2.7.6 and earlier releases as<br>
"Python 2.7 with Legacy SSL".<br>
<br>
<br>
Rejected variant: synchronise particular modules entirely with Python 3<br>
-----------------------------------------------------------------------<br>
<br>
Earlier versions of this PEP suggested synchronising the ``hmac``,<br>
``hashlib`` and ``ssl`` modules entirely with their Python 3 counterparts.<br>
<br>
This approach proved too vague to build a compelling case for the exception,<br>
and has thus been replaced by the current more explicit proposal.<br>
<br>
<br>
Rejected variant: open ended backport policy<br>
--------------------------------------------<br>
<br>
Earlier versions of this PEP suggested a general policy change related to<br>
future Python 3 enhancements that impact the general security of the<br>
internet.<br>
<br>
That approach created unnecessary uncertainty, so it has been simplified to<br>
propose backport a specific concrete set of changes. Future feature<br>
backport proposals can refer back to this PEP as precedent, but it will<br>
still be necessary to make a specific case for each feature addition to<br>
the Python 2.7 long term support release.<br>
<br>
<br>
Disclosure of Interest<br>
======================<br>
<br>
The author of this PEP currently works for Red Hat on test automation tools.<br>
If this proposal is accepted, I will be strongly encouraging Red Hat to take<br>
advantage of the resulting opportunity to help improve the overall security<br>
of the Python ecosystem. However, I do not speak for Red Hat in this matter,<br>
and cannot make any commitments on Red Hat's behalf.<br>
<br>
<br>
Acknowledgements<br>
================<br>
<br>
Thanks to Christian Heimes and other for their efforts in greatly improving<br>
Python's SSL support in the Python 3 series, and a variety of members of<br>
the Python community for helping me to better understand the implications<br>
of the default settings we provide in our SSL modules, and the impact that<br>
tolerating the use of SSL infrastructure that was defined in 2010<br>
(Python 2.7) or even 2008 (Python 2.6) potentially has for the security<br>
of the web as a whole.<br>
<br>
Thanks to Donald Stufft and Alex Gaynor for identifying a more limited set<br>
of essential security features that allowed the proposal to be made more<br>
fine-grained than backporting entire modules from Python 3.4 [7,8]_.<br>
<br>
Christian and Donald also provided valuable feedback on a preliminary<br>
draft of this proposal.<br>
<br>
Thanks also to participants in the python-dev mailing list threads<br>
[1,2,5,6]_, as well as the various folks I discussed this issue with at<br>
PyCon 2014 in Montreal.<br>
<br>
<br>
References<br>
==========<br>
<br>
.. [1] PEP 466 discussion (round 1)<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133334.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133334.html</a>)<br>
<br>
.. [2] PEP 466 discussion (round 2)<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133389.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133389.html</a>)<br>
<br>
.. [3] Marc-Andre Lemburg's OpenSSL feedback for Windows<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133438.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133438.html</a>)<br>
<br>
.. [4] Ned Deily's OpenSSL feedback for Mac OS X<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133347.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133347.html</a>)<br>
<br>
.. [5] PEP 466 discussion (round 3)<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133442.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133442.html</a>)<br>
<br>
.. [6] PEP 466 discussion (round 4)<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133472.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133472.html</a>)<br>
<br>
.. [7] Donald Stufft's recommended set of backported features<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133500.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133500.html</a>)<br>
<br>
.. [8] Alex Gaynor's recommended set of backported features<br>
(<a href="https://mail.python.org/pipermail/python-dev/2014-March/133503.html" target="_blank">https://mail.python.org/pipermail/python-dev/2014-March/133503.html</a>)<br>
<br>
<br>
<br>
Copyright<br>
=========<br>
<br>
This document has been placed in the public domain.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div>