[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

David Wilson dw+python-dev at hmmz.org
Thu Jun 1 10:10:00 EDT 2017

On Thu, Jun 01, 2017 at 12:18:48PM +0100, Cory Benfield wrote:

> So, this will work, but at a performance and code cleanliness cost.
> This essentially becomes a Python-2-only code-path, and a very large
> and complex one at that.

"Doctor, it hurts when I do this .."

Fine, then how about rather than exporting pip's problems on to the rest
of the world (which an API change to a security module in a stable
branch most certainly is, 18 months later when every other Python
library starts depending on it), just drop SSL entirely, it will almost
certainly cost less pain in the long run, and you can even arrange for
the same code to run in both major versions.

Drop SSL? But that's madness!

Serve the assets over plain HTTP and tack a signature somewhere
alongside it, either side-by-side in a file, embedded in a URL query
string, or whatever. Here[0] is 1000 lines of pure Python that can
validate a public key signature over a hash of the asset as it's
downloaded. Embed the 32 byte public key in the pip source and hey

[0] https://github.com/jfindlay/pure_pynacl/blob/master/pure_pynacl/tweetnacl.py

Finding someone to audit the signature checking capabilities of [0] will
have vastly lower net cost than getting the world into a situation where
pip no longer runs on the >1e6 EC2 instances that will be running Ubuntu
14.04/16.04 LTS until the turn of the next decade.

Requests can't be installed without a working SSL implementation? Then
drop requests, it's not like it does much for pip anyway. Downloads
worldwide get a huge speedup due to lack of TLS handshake latency, a
million Squid caching reverse proxies worldwide jump into action caching
tarballs they previously couldn't see, pip's _vendor directory drops by
4.2MB, and Python package security depends on 1k lines of memory-safe
code rather than possibly *the* worst example of security-unconcious C
to come into existence since the birth of our industry. Sounds like a
win to me.

Maybe set a standard rather than blindly follow everyone else, at the
cost of.. everyone else.


More information about the Python-Dev mailing list