Upgrade to Python 2.7.9

[Alex Gaynor]

Python 2.7.9 contains numerous security improvements for Python.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alex Gaynor (alex-gaynor)]

CVE-2014-9365 has been assigned to TLS certificate validation issue in Python 2.7.8 and earlier; this issue is fixed in 2.7.9

[James Lamb (admin-oranged)]

Is this going to be back-ported to 14.04?

[Hans Joachim Desserud (hjd)]

Python 2.7.9 is now in the Proposed for Ubuntu Vivid. My guess is that they are rebuilding/checking libraries and applications to verify they are still working as expected with the newer version, before pushing it to the main archives.

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.

Not familiar with the CVEs, but if possible those should maybe be patched for older releases as well.

[Tyler Hicks (tyhicks)]

The Ubuntu Security team has made the decision to not backport the fix for CVE-2014-9365 to stable Ubuntu releases. The rationale can be found in the Notes section of the corresponding Ubuntu CVE tracker entry:

  http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-9365.html

I think this bug can be closed since Ubuntu 15.04 and newer shipped Python 2.7.9 or newer while Ubuntu 14.04 LTS and Ubuntu 12.04 LTS will not be receiving the backported fix for CVE-2014-9365. We'll fix individual applications that do not do proper certificate verification in those two releases.

[Cory Benfield (lukasaoz)]

Tyler,

Sorry if I don't fully understand, but your claim is that this is a non-issue because "you" (presumably referring to the Ubuntu Security team in general) will fix individual applications that are vulnerable to CVE-2014-9365. Before closing this issue, I'd like to know how you plan to do that without backporting the fix in question.

If we restrict ourselves to just the package tree for a moment, are you really suggesting that the Ubuntu Security team will comb through every single Python package to check whether they use a Python module that does not verify certificates, and then evaluate how to patch that in manually, and then apply that patch? And then you will do this recursively, so that all packages that depend on the first set of packages are themselves evaluated for breakage or workaround? Where is Ubuntu getting the manpower to do this work?

That then leaves out the substantial portion of users who are using applications that are not in the package trees: those users need to be actively watching the CVE database for vulnerabilities in order to know that they are, in fact, vulnerable. I suspect most of them are not: they, like many others, are expecting that Ubuntu will patch known defects when they arise.

Am I wrong here? Because it seems to me that the decision was made here that it matters more that user code does not break, even when that code is actively exposing the users to compromise and risk. That strikes me as a pretty perverse decision.

[W. Koot (wkoot)]

So none of the currently supported LTS versions will actually have a backport.
I'd rather not have to upgrade to 16.04 LTS (Xenial Xerus) in order to get rid of urllib2 quircks

[Kevin Carter (kevin-carter)]

I have to agree with the sentiment that this should be backported on the grounds Ubuntu LTS releases are popular server operating systems which many folks rely on for day to day operations. As an LTS release its expected security issues will be taken care of as long as the release is supported. The idea that this is not being backported because it has the potential to break some applications which have made assumptions regarding certificate validation is beyond me and I find the notion that some internal team within Ubuntu is going to sit and fix applications invididually absolutely crazy. If individual application patching is being proposed it would seem more sane to simply backported the security fix and hunt for apps that are now unstable. If and when these apps are found folks at Ubuntu or in the general community should coordinate with the respective upstream to get the appropriate fixes in. IMHO holding back this update will do more harm then good.

As a potential compromise, might this be considered for backported in 14.04 only? I ask because, like @wkoot, I would rather not have to wait and later upgrade to Ubuntu 16.04 to see this security issue resolved.

[Dario Bertini (berdario)]

For the people annoyed at the idea to move to 16.04:

There are some alternative ways to get an updated Python version, without relying on the one shipped by default in Ubuntu:

Pythonz: https://github.com/saghul/pythonz (disclaimer: I submitted some patches and integrated pythonz into my own project: https://github.com/berdario/pew )
Pyenv: https://github.com/yyuu/pyenv
The deadsnakes ppa: https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes-python2.7?field.series_filter=precise (this is not the main PPA, but it's the one created specially for this purpose)

[Tyler Hicks (tyhicks)]

Hi Cory and Kevin! The Ubuntu Security team (most of the work was done by Marc Deslauriers) has actively fixed individual Python packages in Ubuntu's main archive pocket that are vulnerable to certificate verification flaws prior to the Python 2.7.9 change. While many packages were already doing proper certificate verification, we updated a number that were not:

 http://www.ubuntu.com/usn/usn-1265-1/
 http://www.ubuntu.com/usn/usn-1270-1/
 http://www.ubuntu.com/usn/usn-1352-1/
 http://www.ubuntu.com/usn/usn-1375-1/
 http://www.ubuntu.com/usn/usn-1381-1/
 http://www.ubuntu.com/usn/usn-1464-1/
 http://www.ubuntu.com/usn/usn-1465-1/
 http://www.ubuntu.com/usn/usn-1465-2/
 http://www.ubuntu.com/usn/usn-1547-1/

You're correct that code living outside of Ubuntu's archive must do the right thing or be updated to a release that does do the right thing by the system administrator. We also keep in mind that there are many one-off scripts, cron jobs, etc., connecting to a server with a self-signed cert, that would break due to such a change. We have to walk a fine line between providing security updates at all costs and potentially breaking production machines with those updates. While we try our best to err on the side of security whenever possible, it did not make sense to us in this instance.

However, we are now looking into ways for our users to opt-in to full certificate verification using our python2.7 packages. While enabling full certificate verification by default, as performed by Python 2.7.9, in a stable Ubuntu release is not a possibility due to the issues I mentioned above, there are some other options on the table. We will look at backporting the appropriate 2.7.9 patches to our python2.7 package in 14.04 and 12.04 or possibly bump those package versions up to 2.7.9. If either of those options are possible, we'll employ the strategy proposed by PEP 493 where the full certification verification is disabled by default but configurable at a system-wide level through /etc/python/cert-verification.cfg. This opt-in approach should allow the owners of systems to enable the changes from PEP 476 once they know their applications, scripts, cron jobs, etc., will continue to work correctly.

[Tyler Hicks (tyhicks)]

@kwoot - please see comment #10 for python2.7 options that may be available in 12.04 and 14.04 in the future. I wanted to point out to you that python3.4 in 14.04 already has the ability to enable full certification verification through the /etc/python3.4/cert-verification.conf configuration file. See the first changelog entry here:

 https://launchpad.net/ubuntu/+source/python3.4/3.4.3-1ubuntu1~14.04.2

[Jamie Strandboge (jdstrand)]

Marking confirmed while the investigation is ongoing. Please mark as triaged if we will employ one of the strategies.

[W. Koot (wkoot)]

@tyhicks Sadly we depend on some libraries that aren't python3-safe. The backport combined with suggested /etc/python/cert-verification.cfg would be an excellent solution

[Sebastien Bacher (seb128)]

https://bugs.launchpad.net/ubuntu/+source/python-defaults/2.7.15-3

[W. Koot (wkoot)]

Wonderful, thanks