[pycrypto] Need your input: Major modernization; dropping legacy Python support?

[Dwayne Litzenberger]

On Wed, Oct 30, 2013 at 06:24:48PM +0100, Sebastian Ramacher wrote:
>> 2. I'm thinking of pulling in additional dependencies (e.g. cffi),
>> requiring setuptools, and basically joining what the rest of the
>> Python community is doing in 2013.
>>
>> 3. What if src/*.c were removed, and any relevant C code moved into
>> an    independent library, which could be loaded using cffi?  (This
>> is    basically what we need to do to support PyPy properly.)
>
>I wouldn't mind if the C code is moved into a library, however cffi
>doesn't seem to be ready to be used in binary distributions without
>resorting to hacks ([1] for the upstream bug, [2] for a very short
>thread on debian-python). I'm told that this will be fixed in cffi at
>some point.
>
>I've always had a good experience with Cython. What do you thinkg about
>that?
>
>Anyway, as long as we are not starting to use ctypes, I'll be fine.
>Depending on the timeframe of this change, I'd prefer PyCrypto to use
>someting that does not require hacks in binary distributions. If cffi is
>fixed until the change happens, I won't complain.
>
>[1] https://bitbucket.org/cffi/cffi/issue/109/enable-sane-packaging-for-cffi
>[2] https://lists.debian.org/debian-python/2013/10/msg00070.html

ctypes is definitely not on the list.

 From what I understand, CFFI will only try to build binaries if they're 
not already found.  I think as long as packages that use CFFI include 
the appropriate rules in their `setup.py build_ext` process, it 
shouldn't be a problem.  (I'd certainly work with you to make sure the 
packaging isn't a nightmare.)

>> 4. What if Crypto.* became a wrapper around some other crypto library?
>
>This depends on the crypto library you're thinking of. If it's openssl,
>then all the GPL licensed reverse dependencies might have a problem (at
>least in Debian).
>
>> 5. The Apache License 2.0.  What if PyCrypto were licensed under it,
>> or    included dependencies that are licensed under it?
>
>With my Debian maintainer hat on, this would be a problem for me. We
>still ship software that is GPL 2 only that depends on PyCrypto.
>However, GPL 2 and the Apache License 2.0 are incompatible.
>
>Examples of these packages include revelation and pymsnt (I stopped
>searching for GPL 2 only reverse dependencies after I've found two).
>
>Of course, if the license changes or python-crypto starts depending on
>something licensed under Apache 2.0 this needs to be checked on a case by
>case basis, but I'd rather avoid it if there is no really good reason to
>do so.

Ugh, GPL 2 only.  I wish people would at least do "or any later 
version".

I'm thinking of merging with the folks at https://cryptography.io/, 
which is covered by an Apache 2.0 license.  My concern is that there are 
a really small number of good crypto implementers in the FOSS world, and 
we're all working on different projects, so Linus' Law isn't really 
taking effect, to the detriment of our users.

With the increase in direct, state-sponsored attacks on deployed 
cryptosystems, there's a renewed interest in deploying "crypto 
everywhere", but our APIs are all terrible, our implementations are 
questionable, our protocols are error-prone.  I feel that we really need 
to combine our efforts if we want to have any hope of fixing these 
problems so that application developers can provide real security to us 
all.  If it means cutting loose a few rarely-used GPL2-only packages, it 
might be worth it.

How bad is the situation with GPL2-only packages?

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
  OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7