7

The question is, how do I install packages securely with pip, on Ubuntu Trusty? Of course I need to clarify why I believe it's insecure.

urllib3 gives an InsecurePlatformWarning if you make an https request without a few extra openssl related python libraries installed, before Python 2.7.9. This is a well established question and answer:

InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately

The problem is, if you install pip version 6 or so, it starts giving you this very warning, as you install anything. From reading the official answer to the problem:

https://urllib3.readthedocs.org/en/latest/security.html#pyopenssl

it sounds like the problem lies in the Python ssl library. Did Pip just switch to the Python ssl library from openssl in the latest version? My guess (perhaps a bad guess) is that pip used the Python library before, it just used an older version of urllib that didn't even give the warning. So it's been insecure the whole time (though the particular vuln of concern seems to be somewhat recent).

Well if that's the case, the stock version of pip on Ubuntu isn't safe. I can't use it to safely install the stuff to make it safe. No matter, I can just install the same things from Ubuntu's repo, which verifies packages with GPG:

http://packages.ubuntu.com/search?keywords=python-ndg-httpsclient

Except the above is only available starting in Utopic. On Trusty I appear to be stuck.

So what's the deal? Do I have to roll the dice and install this stuff insecurely once, and then use pip securely only after that? Or am I misreading the situation altogether?

Community
  • 1
  • 1
orblivion
  • 446
  • 3
  • 12

2 Answers2

6

pip uses the standard library ssl module by default (unless you also install the extra libraries you've mentioned). Prior to Python 2.7.9 and Python 3.2(ish, I believe it was 3.2, might have been 3.1) the ssl module inside of the standard library lacked the ability to control certain settings related to ssl.

Some of these settings:

  • You cannot disable SSLv3 without explicitly pinning to TLSv1.0 (and you cannot pin to TLSv1.1 or TLSv1.2).
  • You cannot disable TLS Compression.
  • You cannot use SNI, forcing every host you're trying to talk to not use SNI (or you need to disable TLS verification for those hosts).
  • You cannot tell OpenSSL to prefer a shorter, but still trusted, chain over the chain that was explicitly given to it by the server. This means that some servers which could otherwise be validated will fail if the underlying certificate store removes the weak 1024 bit root certificates.
  • On even older Pythons (2.6) you cannot set the ciphers either, which means you're stuck with whatever OpenSSL used as the default (often resulting in insecure or less than optimal choices).

As far as what you should do, it's really up to you. If you're installing from PyPI itself a lot of these things simply don't matter much because we disable them on the server side instead of relying on the clients to implement them. However requests (the underlying library pip uses to access a repository) raises these warnings (and pip doesn't silence them) because PyPI is often not the only place you're going to connect to and those additional places may or may not take the same precautions that PyPI has.

Source: I am a core pip developer and administrator of PyPI.

Donald Stufft
  • 1,148
  • 8
  • 11
  • Interesting, thanks. So it sounds like an imperfect solution, since this issue is probably not well known. I had no idea about this until I ran a recent version of pip. But, it sounds like I can get all the packages I need to make pip work safely from pypi, and I should be reasonably safe in doing so since you said most of the issues are stopped server-side (though you didn't say all of them were). Then, I can install anything else I need because pip will be using openssl. Doable, but stlil doesn't seem ideal. The ecosystem is a bit chaotic. – orblivion Apr 11 '15 at 17:02
  • 1
    As pointed out [here](http://stackoverflow.com/a/29202163), you can switch to using `PyOpenSSL` with `requests` via `pip install requests[security]`. This way, you only get the warning for that one usage of `pip` and, as mentioned in the above answer, connecting to PyPI itself shouldn't be too much of a worry as they've handled these security issues server-side. – Steven Maude Jun 29 '15 at 10:56
0

I read the existing discussion and thought well, what am I supposed to do now?

Then I realised that the fundamental problem I was having was that I was on Ubuntu 14.04, and the version of python it ships is flawed. So I upgraded to 15.04.

pwaller
  • 601
  • 6
  • 10
  • That's unfortunate, since 14.04 is an LTS. I'm not eager to upgrade. – orblivion Jun 06 '15 at 22:21
  • Yes, it is, and I liked the idea of using LTS. I've come to think the reality of that is that these LTS systems will just get less and less secure over time, because even if they're providing security patches, stuff like this won't get fixed :( – pwaller Jun 09 '15 at 07:19