Crap. We need to patch all 3.* too.
Or use this to expedite 3.4 stabilization?
(In reply to Dirkjan Ochtman from comment #3)
> Or use this to expedite 3.4 stabilization?
That probably won't help much. We are waiting on a few dozen python packages before we can many 3.4 the default without confusing lots of people.
Yeah... Can we drop 3.2.x?
(In reply to Dirkjan Ochtman from comment #5)
> Yeah... Can we drop 3.2.x?
Yeah, let's mask it for a bit. Would be nice to keep the ebuild in the tree in case somebody wants to test something.
Adding vulnerability text so we do not have to jump to external site:
Title: Python standard HTTP libraries fail to validate TLS certificates for
Products: CPython, all 2.x versions prior to 2.7.9, 3.x versions prior to
When Python's standard library HTTP clients (httplib, urllib, urllib2,
xmlrpclib) are used to access resources with HTTPS, by default the
is not checked against any trust store, nor is the hostname in the
checked against the requested host. It was possible to configure a trust
to be checked against, however there were no faculties for hostname
This made MITM attacks against the HTTP clients trivial, and violated RFC
Python 2.7.9 has been issued to resolve this issue. It is also resolved in
3.4.3, which has not yet been released.
If nobody else has done it, I will plan on adding 2.7.9 to the tree this weekend.
For the 3.4 branch, I would prefer to wait for the upstream release.
I'm not sure what is happening on the 3.3 branch; if there is no upstream release scheduled soon, we can try to backport this.
dev-lang/python-2.7.9 is in the tree. Let's give it a week in ~arch before stabilizing.
Arches, please test and mark stable:
Target Keywords : "alpha amd64 arm hppa ia64 ppc ppc64 spark x86"
Stable for HPPA.
I just revbumped the ebuild. New target is:
I copied the existing stable keywords.
The HTTP clients in the (1) httplib, (2) urllib, (3) urllib2, and (4)
xmlrpclib libraries in CPython (aka Python) 2.x before 2.7.9 and 3.x before
3.4.3, when accessing an HTTPS URL, do not (a) check the certificate against
a trust store or verify that the server hostname matches a domain name in
the subject's (b) Common Name or (c) subjectAltName field of the X.509
certificate, which allows man-in-the-middle attackers to spoof SSL servers
via an arbitrary valid certificate.
Stable on alpha.
Python 3.4.3 has now been released, so hopefully that can be stablized, too.
This issue was resolved and addressed in
GLSA 201503-10 at https://security.gentoo.org/glsa/201503-10
by GLSA coordinator Kristian Fiskerstrand (K_F).