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

[Dwayne Litzenberger]

Hi folks,

I'm thinking about making some fairly drastic changes to PyCrypto 
(compared to what's happened historically) and I'd like to know how 
these would impact people:

1. How many of you would really care if PyCrypto 2.6 was that last 
    version to support legacy versions of Python?  By "legacy", I mean 
    all versions of Python that are NOT one of these:

     - Python 2.6.x
     - Python 2.7.x
     - Python 3.3 and above.

    I'd continue to make bugfix releases of PyCrypto 2.6.x, but add no 
    more substantial new features.

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.)

4. What if Crypto.* became a wrapper around some other crypto library?

5. The Apache License 2.0.  What if PyCrypto were licensed under it, or 
    included dependencies that are licensed under it?

6. What if src/*.c was mostly replaced with mostly just went away.

Don't panic.  These aren't concrete plans yet, but I'd like to know how 
this might affect various downstream PyCrypto stakeholders, and problems 
I might expect to encounter if I went in any of these directions.

Of particular concern is FOSS distributors packaging PyCrypto (e.g.  
Linux distros, *BSD ports trees, MacPorts/HomeBrew, etc.), and anything 
else that might impact a large number of downstream end-users.

I've been maintaining backward compatibility in order to protect 
end-users from bugs introduced in downstream forks of PyCrypto, but 
that's made it hard to generate interest in working on PyCrypto.  From 
what I can tell, there are currently several Python crypto libraries, 
and none of them are particularly great (including PyCrypto).

I'm beginning to wonder how the risk of downstream forks compares to the 
risks that users face when developers still don't have a highly-visible, 
easy-to-use Python crypto API.  It might be better to merge PyCrypto 
with one or more other Python crypto libraries...

Anyway, I'd love to hear what people have to say on this topic.

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