[Cryptography-dev] Packaging ideas

[Donald Stufft]

On Apr 28, 2014, at 12:32 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> So, before I can start talking about solutions, I have to describe the use cases.
> 
> 1) Some folks need a very specific backend (i.e. pyOpenSSL) and right now it's just assumed that that will come with `pip install cryptography`.
> 2) Some folks want to use cryptography as the API for non-traditional primitives (e.g. scrypt), and `pip install cryptography` brings a lot more than what they want.
> 3) Some folks want to type the letters AES, and don't really care where that comes from.
> 4) Some folks want to type the letters "fab", and super don't care that fabric needs a paramiko which needs an AES.
> 5) Some folks want to be able `pip install something` without getting an OpenSSL, because OpenSSL is literally the worst thing in the world.
> 
> Invariants that must hold true:
> 
> * `pip install cryptography` gets you a thing that can AES (and whatever other core algorithms we think are important)
> * There's a thing you can `pip install` that gets you scrypt, but not OpenSSL
> * There's a thing you can `pip install` to definitely get some OpenSSL.
> 
> Solution:
> 
> We break things down into a few different packages:
> 
> * `pip install cryptography-core`: This contains all the primitives, all the recipes, all the everything besides the backends/bindings
> * `pip install cryptography-{openssl,scrypt,etc.}`: This contains the backend/bindings for the specific thing
> * `pip install cryptography`: This gets you a cryptography, and whatever set of core backends we think are reasonable for your platform for doing stuff like typing AES (and, god willing, then typing HMAC).
> 
> Thoughts?
> Alex
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

So I (obviously given i’ve been saying it for awhile now ;) ) agree with
splitting out the backends!

First off, my question is how important is #2 on platforms which do not ship
OpenSSL or have it easily installable which extends into how important is #5 at
all?

I ask because I think that cryptography-core (versus just keeping the “core”
stuff in cryptography) is a hack around a failing in python packaging and I
would much rather solve that by fixing python packaging. What that would mean
is that supporting #5 (and #2 on platforms where OpenSSL isn’t readably
available) isn’t super nice at first until packaging “catches” up.

It is my belief that the people with the use case of #2 are not going to care
if the bits to enable OpenSSL are residing on their machine unused unless those
bits forced them to go and manually install OpenSSL, with their level of care
increasing based on how painful it was for them to manually install OpenSSL. I
also believe that the #5 case will be the people who actually care “No there
must be ZERO OpenSSL bits on my system” and I also believe that they will be a
minority use case.

Given those beliefs I feel like it is reasonable to leave the “core” stuff
inside of the cryptography package, and simple say that if you want to
``pip install cryptography`` without getting the OpenSSL bits then you’ll need
to do ``pip install cryptography —no-use-wheel —install-option=“—no-openssl”``
or ``CRYPTOGRAPHY_WITHOUT_OPENSSL=1 pip install —no-use-wheel cryptography``.
Once packaging catches up to this use case then we can clean that up to
something like ``pip install cryptography[nss]`` (replace nss with any other
backend here!).

Beyond that there is one small sticky point to this: Imports.

Currently we only ship one package (well two if you count cryptography_vectors)
however this is going to cause us to ship more than that. However we already
have a public API on ``cryptography.hazmat.bindings.*`` and
``cryptography.hazmat.backends.*``. I do not think we can break those which
leaves us with two choices:

A) Namespace packages - These are the “obvious” first top to reach too, however
   I can often be found saying that nobody has ever used namespace packages
   without regretting it. In particular there are issues when combining
   easy_install and pip.
B) Use some sort of shim to enable ``cryptography.hazmat.bindings.*`` and
   ``cryptography.hazmat.backends.*`` to act as “aliases” for something else,
   either something based on setuptools entry points, or something based on
   naming (ex: https://github.com/mitsuhiko/flask/blob/master/flask/ext/__init__.py)

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140428/5f060a93/attachment.sig>