[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2193: pyOpenSSL 0.14 pulls in a bunch of new dependencies

[Tahoe-LAFS]

#2193: pyOpenSSL 0.14 pulls in a bunch of new dependencies
-------------------------+-------------------------------------------------
     Reporter:  daira    |      Owner:
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:           |    Version:  1.10.0
  packaging              |   Keywords:  packaging setuptools pyopenssl
   Resolution:           |  cryptography six cffi pycparser
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by daira):

 Replying to [comment:12 glyph]:
 > Replying to [comment:10 daira]:
 > > I'm annoyed and frustrated by pyOpenSSL adding a dependency on yet
 another fucking cryptography library. It's going in entirely the wrong
 direction.
 >
 > However, since you seem frustrated let me try to address that.  It might
 be helpful to read [https://cryptography.io/en/latest/#why-a-new-crypto-
 library-for-python the Cryptography team's rationale for creating
 something new] rather than trying to maintain one of the existing options,
 but that's pretty brief.
 >
 > First of all, Cryptography is not ''really'' "yet another ...
 cryptography library".  My understanding is that it implements exactly
 ''no'' cryptographic primitives itself.  Instead, its mission is to be a
 comprehensive wrapper around and common interface to multiple back-ends
 which allow for using your platform's existing cryptography engine,
 allowing you to access things like hardware support and platform security
 updates without updating all of your application's code.  For example,
 it's not just a wrapper around OpenSSL; it also wraps
 [https://github.com/pyca/cryptography/tree/master/cryptography/hazmat/bindings/commoncrypto
 the CommonCrypto API from OS X's security framework].

 Well exactly, and this is the core of the issue. The decision to change
 the scope of `pyOpenSSL` from being a wrapper around just `OpenSSL`, to
 being something that depends on a considerably more ambitious project,
 came entirely out of the blue from the point of view of Tahoe-LAFS
 developers. Perhaps we should have been paying more attention, I don't
 know. I certainly don't have any objection to the `cryptography` project;
 what I have an objection to is the lack of any heads-up to projects
 depending on `pyOpenSSL` (a list of them is easily determined from the
 package metadata on PyPI) of a rather major design change.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193#comment:13>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage