[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 glyph):

 Replying to [comment:13 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.

 This change was announced [https://mail.python.org/pipermail/pyopenssl-
 users/2014-January/000484.html in January on the pyOpenSSL mailing list],
 [http://thread.gmane.org/gmane.comp.python.twisted/26687 and then on the
 Twisted list],
 [http://article.gmane.org/gmane.comp.python.twisted/26696/match=pyOpenSSL
 and then again on the Twisted list, specifically stressing how major the
 change would be], not to mention the 4 other alpha pre-release
 announcements on those lists.  I feel like this was reasonably broadly
 communicated.  What more do you feel we should have done?

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