As you might know, with PEP 476, since Python 3.5 (backported to 3.4.3 and 2.7.9) tls certificates are now checked for their validity.

Lack of validation leaves software exposed to mitm, so I think it's fairly uncontroversial to think of the update 2.7.8 -> 2.7.9 as a security update.

Recently I found myself using my old laptop, running Ubuntu LTS instead of the latest and greatest. After running updates and setting up the environment to work on some python code, I realized that the version for the python2 interpreter seemed suspiciously low: 2.7.5-5ubuntu3

You can check yourself the version online:

latest python2.7 on latest ubuntu (as of 26th December 2015) is 2.7.9-1

latest python2.7 on latest ubuntu lts (as of 26th December 2015) 2.7.5-5ubuntu3

This doesn't necessarily means that it doesn't ship the 2.7.9 changes, because they could've been backported (though I find it suspicious, due to the huge change in the ssl module, I'd expect it easier to adopt 2.7.9 wholesale rather than backporting the patches)... so I tried to open up a page with a certificate that's not commonly accepted (e.g. https://cacert.org ) and, to my dismay, no exception was raised.

For comparison, with a newer Python:

>>> urlopen('https://cacert.org')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/usr/lib/python2.7/ssl.py", line 808, in do_handshake
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

It has now been more than 1 year since Python 2.7.9 has been released, and both Ubuntu 14.04.2 and 14.04.3 have been released in the meanwhile, so if it hasn't been backported, it's not because they were waiting for a dot-release of the LTS.

An example of how things might be affected by this change: At my previous job, I found an internal script that was scheduled to connect and authenticate to an internal https-only website to report some information, such internal website relied on an internal root certificate. The script didn't fail, even if the root CA was not available to it, only thanks to the lack of this check. The credentials were stored safely on disk, but (as risky as it would've been to do it in a work environment) being on the same network it could've been possible to do a mitm attack to steal these credentials.

This is interesting because updating to 2.7.9 would both solve the potential security issue with that script, and make the script stop working until fixed. I thus thought that an explanation for why this hasn't been backported to Ubuntu LTS might be the risk in breaking existing code, but I'm not persuaded.

While I'm at it, here's the code to fix such broken code, by doing certificate pinning (actually only the CA is pinned) for the benefit of people who might stumble on this, since it's really trivial but there are not a lot of examples around:

import ssl as tls
    from urllib.request import urlopen
except ImportError:
    from urllib import urlopen

# this is the certificate in binary form, taken from http://www.cacert.org/certs/root.der
cert = '0\x82\x07=0\x82\x05%\xa0\x03\x02\x01\x02\x02\x01\x000\r\x06\t*\x86H\x86\xf7\r\x01\x01\x04\x05\x000y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x1e\x17\r030330122949Z\x17\r330329122949Z0y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x82\x02"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x02\x0f\x000\x82\x02\n\x02\x82\x02\x01\x00\xce"\xc0\xe2F}\xec6(\x07P\x96\xf2\xa03@\x8cK\xf1;f?1\xe5k\x026\xdb\xd6|\xf6\xf1\x88\x8fNw6\x05A\x95\xf9\t\xf0\x12\xcfF\x86s`\xb7n~\xe8\xc0Xd\xae\xcd\xb0\xadE\x17\x0cc\xfag\n\xe8\xd6\xd2\xbf>\xe7\x98\xc4\xf0L\xfa\xe0\x03\xbb5]l!\xde\x9e \xd9\xba\xcdf27r\xfa\xf7\x08\xf5\xc7\xcdX\xc9\x8e\xe7\x0e^\xea>\xfe\x1c\xa1\x14\n\x15l\x86\x84[df*z\xa9KSy\xf5\x88\xa2{\xee/\na+\x8d\xb2~MV\xa5\x13\xec\xea\xda\x92\x9e\xacDA\x1eX`e\x05f\xf8\xc0D\xbd\xcb\x94\xf7B~\x0b\xf7eh\x98Q\x05\xf0\xf3\x05\x91\x04\x1d\x1b\x17\x82\xec\xc8W\xbb\xc3kz\x88\xf1\xb0r\xcc%[ \x91\xec\x16\x02\x12\x8f2\xe9\x17\x18H\xd0\xc7\x05.\x020B\xb8%\x9c\x05k?\xaa:\xa7\xebSH\xf7\xe8\xd2\xb6\x07\x98\xdc\x1b\xc64\x7f\x7f\xc9\x1c\x82z\x05X+\x08[\xf38\xa2\xab\x17]f\xc9\x98\xd7\x9e\x10\x8b\xa2\xd2\xddt\x9a\xf7q\x0cr`\xdf\xcdo\x983\x9d\x964v>$z\x92\xb0\x0e\x95\x1eo\xe6\xa0E8G\xaa\xd7A\xedJ\xb7\x12\xf6\xd7\x1b\x83\x8a\x0f.\xd8\t\xb6Y\xd7\xaa\x04\xff\xd2\x93}h.\xdd\x8bK\xabX\xba/\x8d\xea\x95\xa7\xa0\xc3T\x89\xa5\xfb\xdb\x8bQ"\x9d\xb2\xc3\xbe\x11\xbe,\x91\x86\x8b\x96x\xad \xd3\x8a/\x1a?\xc6\xd0Qe\x87!\xb1\x19\x01e\x7fE\x1c\x87\xf5|\xd0ALO)\x98!\xfd3\x1fu\x0c\x04Q\xfa\x19w\xdb\xd4\x14\x1c\xee\x81\xc3\x1d\xf5\x98\xb7i\x06\x91"\xdd\x00P\xcc\x811\xac\x12\x07{8\xdah[\xe6+\xd4~\xc9_\xad\xe8\xebrL\xf3\x01\xe5K \xbf\x9a\xa6W\xca\x91\x00\x01\x8b\xa1u!7\xb5c\rg>FOp g\xce\xc5\xd6Y\xdb\x02\xe0\xf0\xd2\xcb\xcd\xbab\xb7\x90A\xe8\xdd \xe4)\xbcd)B\xc8"\xdcx\x9a\xffC\xec\x98\x1b\tQKZZ\xc2q\xf1\xc4\xcbs\xa9\xe5\xa1\x0b\x02\x03\x01\x00\x01\xa3\x82\x01\xce0\x82\x01\xca0\x1d\x06\x03U\x1d\x0e\x04\x16\x04\x14\x16\xb52\x1b\xd4\xc7\xf3\xe0\xe6\x8e\xf3\xbd\xd2\xb0:\xee\xb29\x18\xd10\x81\xa3\x06\x03U\x1d#\x04\x81\x9b0\x81\x98\x80\x14\x16\xb52\x1b\xd4\xc7\xf3\xe0\xe6\x8e\xf3\xbd\xd2\xb0:\xee\xb29\x18\xd1\xa1}\xa4{0y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x82\x01\x000\x0f\x06\x03U\x1d\x13\x01\x01\xff\x04\x050\x03\x01\x01\xff02\x06\x03U\x1d\x1f\x04+0)0\'\xa0%\xa0#\x86!https://www.cacert.org/revoke.crl00\x06\t`\x86H\x01\x86\xf8B\x01\x04\x04#\x16!https://www.cacert.org/revoke.crl04\x06\t`\x86H\x01\x86\xf8B\x01\x08\x04\'\x16%http://www.cacert.org/index.php?id=100V\x06\t`\x86H\x01\x86\xf8B\x01\r\x04I\x16GTo get your own certificate for FREE head over to http://www.cacert.org0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x04\x05\x00\x03\x82\x02\x01\x00(\xc7\xee\x9c\x82\x02\xba\\\x80\x12\xca5\n\x1d\x81o\x89j\x99\xcc\xf2h\x0f\x7f\xa7\xe1\x8dX\x95>\xbd\xf2\x06\xc3\x90Z\xac\xb5`\xf6\x99C\x01\xa3\x88p\x9c\x9db\x9d\xa4\x87\xafgX\r06;\xe6\xadH\xd3\xcbt\x02\x86q>\xe2+\x03h\xf14b@F;S\xea(\xf4\xac\xfbf\x95S\x8aM]\xfd;\xd9`\xd7\xcayi;\xb1e\x92\xa6\xc6\x81\x82\\\x9c\xcd\xebM\x01\x8a\xa5\xdf\x11U\xaa\x15\xca\x1f7\xc0\x82\x98pa\xdbj|\x96\xa3\x8e.T>O!\xa9\x90\xef\xdc\x82\xbf\xdc\xe8E\xadM\x90s\x08<\x94e\xb0\x04\x99v\x7f\xe2\xbc\xc2j\x15\xaa\x97\x047$\xd8\x1e\x94Nm\x0eQ\xbe\xd6\xc4\x8f\xca\x96m\xf7C\xdf\xe80e\';{\xbbCCc\xc4C\xf7\xb2\xech\xcc\xe1\x19\x8e"\xfb\x98\xe1{Z>\x017;\x8b\x08\xb0\xa2\xf3\x95N\x1a\xcb\x9b\xcd\x9a\xb1\xdb\xb2p\xf0-J\xdb\xd8\xb0\xe3oEH3\x12\xff\xfe<2*T\xf7\xc4\xf7\x8a\xf0\x88#\xc2G\xfedzq\xc0\xd1\x1e\xa6c\xb0\x07~\xa4/\xd3\x01\x8f\xdc\x9f+\xb6\xc6\x08\xa9\x0f\x93H%\xfc\x12\xfd\x9fB\xdc\xf3\xc4>\xf6W\xb0\xd7\xddi\xd1\x06w4\nK\xd2\xca\xa0\xff\x1c\xc6\x8c\xc9\x16\xbe\xc4\xcc27hs_\x08\xfbQ\xf7IS6\x05\n\x95\x02L\xf2y\x1a\x10\xf6\xd8:u\x9c\xf3\x1d\xf1\xa2\rpg\x86\x1b\xb3\x16\xf5/\xe5\xa4\xeby\x86\xf9=\x0b\xc2s\x0b\xa5\x99\xaco\xfcg\xb8\xe5/\x0b\xa6\x18$\x8d{\xd1H5)\x18@\xac\x93`\xe1\x96\x86P\xb4zY\xd8\x8f!\x0b\x9f\xcf\x82\x91\xc6;\xbfk\xdc\x07\x91\xb9\x97V#\xaa\xb6l\x94\xc6H\x06<\xe4\xceN\xaa\xe4\xf6/\t\xdcSo.\xfct\xeb:c\x99\xc2\xa6\xac\x89\xbc\xa7\xb2D\xa0\r\x8a\x10\xe3l\xf2$\xcb\xfa\x9b\x9fpG.\xde\x14\x8b\xd4\xb2 \t\x96\xa2d\xf1$\x1c\xdc\xa15\x9c\x15\xb2\xd4\xbcU.}\x06\xf5\x9c\x0eU\xf4Z\xd6\x93\xdav\xad%sL\xc5C'

ctx = tls.create_default_context(cadata=cert)
urlopen('https://cacert.org', context=ctx) # success

Whatever the reason for not shipping this security fix, there's often expectation that (barring 0 days and newly discovered vulnerabilities) having a system of a supported OS version, with all of the system updates installed (and kept up-to-date subsequently) gives you a secure foundation over which to build a system (which will then be made insecure with misconfigurations and custom code).

I was a bit unsure if I should ask this over unix.stackexchange.com or somewhere else, anyhow I tried to have a look for documentation on the policy used by the Ubuntu maintainers [1] [2] [3], and I don't see anywhere that could explain why some fixes might not qualify to be backported. OTOH security support means:

[they] provide security updates for supported software in the Ubuntu distribution.

Nowhere it's written that such updates are complete and exhaustively cover every security issue known by the maintainers. Ok, FOSS software often/always has the "No warranty" clause/disclaimer, but I'm not concerned about that.

I'm concerned with the mismatching expectations that IT professionals and the world at large have over security updates, and what can actually be provided: After all, not every software project has different releases still supported, and if it's still in active development, it might not be feasible to backport such fixes to older versions (ok, it might be argued that such software shouldn't belong in the Ubuntu main repositories). Sometimes security issues might be fixed upstream, without the developers realizing they were security issues in the first place, and so no one will realize the need for backporting these. And this is assuming that the maintainers are infallible beings that won't commit mistakes.

There's a question that asks about a similar problem but from a different angle: PCI compliance. I'd expect such a standard to be both more-strict than best practices for normal server/workstation deployments, and also not as comprehensive as needed to cover every possible case (after all, standards are formalized only after enough people take notice). So for PCI compliance that might be only needed to "tick a checkbox", but it'd be worrying if even to follow best practices it wasn't enough just to run the system updates, but we'd need to also keep track with upstream for every single piece of software running on a system.

OTOH, if we truly have to take ownership of all of this, it would force us in the direction of having less to deal with, a smaller attack surface and fewer moving parts... Maybe scrapping Linux or a full-fledged OS altogether and only run Unikernels on server...

So, what is/could be the rationale for not choosing to backport such fixes? Is it documented?

PS: After writing this, I found this other stackexchange question

The upstream version of Python 2.7 in Ubuntu 14.04 will always be 2.7.6.

This is a bit at odds with my understanding of the wiki, since potentially Ubuntu could ship 2.7.9 for Trusty. The answerer anyhow doesn't seem to be affiliated with Canonical/Ubuntu, he also writes:

Since 2.7.9 will be part of Ubuntu 15.04, I'd expect an update around the time 14.04.2 releases, if ever. The corresponding Launchpad bug is as yet unassigned.

(emphasis mine)

So, with 14.04.2 nothing obviously changed. One user on Launchpad mentions:

As for backporting to older releases I don't know, but it should be possible to add a request once the package has landed in Vivid.

I know that there's a process to request normal backports in Debian/Ubuntu, but that shouldn't apply for security updates.

2 Answers 2


A security update is when a patch is released to fix a security vulnerability, not when a new security feature is added. There will be an associated advisory about a security update.

The Python change you are referring to is classified by Python as a new feature, not a security fix. The big difference here is documentation. As they document the Python functionality as not validating the cert, it is not a security vulnerability, just a (crappy) feature.

So there's no commitment to backport it.

  • Ok, but this comes with a CVE, so do you think that we shouldn't think of every CVE fix as a security update? "classified by Python as a new feature, not a security fix"? Maybe you mean classified by Debian/Ubuntu? The PEP never explicitly categorize itself as new-feature or security fix (and I'm not sure if it makes sense to consider the 2 things mutually exclusive)... Where is this classification documented? Who does it?
    – berdario
    Commented Dec 27, 2015 at 12:20
  • Even in the face of the CVE, Python did not treat this as a security fix and did not produce a security patch. Ubuntu just followed suit. If you're asking what I think, I think it's an embarrassment that Python ever shipped without the functionality. But I'm not a Python contributor so my opinion doesn't really matter. The question is about why didn't Ubuntu's security patch promise kick in, not what I think Python should have done. Perhaps raising this on a Python or Ubuntu forum will provide you with a different viewpoint. (There's askubuntu.com.) Commented Dec 27, 2015 at 17:26
  • Agree, I hoped there'd be more overlap with a linux distribution security team (this example is in Ubuntu, but I think it could've happened anywhere) in this community rather than in askubuntu, but I could try to ask somewhere else as well. I also agree that it's an embarrassment (I guess the state of TLS in a language's stdlib is often suboptimal)...
    – berdario
    Commented Dec 27, 2015 at 19:22
  • @berdario It doesn't make sense for a repackager of software to question every decision made by the code's authors. It just doesn't scale. That doesn't mean that a repackager like Ubuntu can't reconsider and change a decision, but that can only happen in exceptional situations. If I was in charge of Ubuntu, I'm unsure what I would decide in this case. It seems a close call and doing nothing is less work than doing something. And every change runs the risk of compatibility problems as when you ship a security patch you are basically forcing your users to upgrade. Commented Dec 27, 2015 at 19:27
  • Yeah.... Also I guess that to "produce a security patch" it might also be enough to simply have the patch in a single self-contained commit... I wonder if there could be a similar problem to this one every time that a project produces a security fix that spawns several different commits.
    – berdario
    Commented Dec 27, 2015 at 19:31

I asked on the ubuntu-hardened mailing list, and I've been pointed to this tracker:


(My email also prompted one of the maintainers to reply to the launchpad bug that I linked at earlier)


  • good news, these things are tracked publicly... it's better than I feared
  • bad news, the lack of a backport for this CVE is indeed intentional, and it's quite a routine decision, apparently

I downloaded the repository for the CVE tracker, and by running

ack -l 'precise.*ignored(?!.*abandoned)' retired

I found a few other examples of security patches that haven't been (and won't be) backported. None of the examples I've seen are interesting (the first 2 are a Chromium bug and an Apache bug that is not affected by Ubuntu default configuration).

Still, I found these insights useful and interesting.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .