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

Lorenz Quack don at amberfisharts.com
Wed Oct 30 09:03:30 PDT 2013


On 30/10/13 06:09, Dwayne Litzenberger wrote:
 > 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:

I'm only a very, very casual user but for what it's worth here come my 2 cents:

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

I like to keep dependencies as low as possible. Obviously, you always have to weigh the pros and cons. So I guess what I 
am saying is that is depends and should be decided on a case by case basis.

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

depends on what exactly you mean by "independent library". If you mean "maintained and shipped separately and added as a 
dependency" then I'm -1. There are enough crypto c-libs out there why add another one?
If you mean "have it in the pycrypto tree but compile it to a lib and use it via cffi just to make pypy happy" then I 
would like to see some performance analysis. The main reason to have stuff in C is performance if I am not mistaken. By 
hearsay I think that ctypes has quite a significant impact. what about cffi?

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

I believe most crypto libs already have a python wrapper. How would pycrypto be differnet?

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

Why? What would that achieve/improve? What's wrong with the current state (more or less public domain)? Wouldn't you 
need to get the consent of every contributor?

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

Wouldn't that totally kill performance? If the parts you want to kill are not security or performance sensitive: go for it!

That it.
Cheers and thanks for all your great work Dwayne!


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

More information about the pycrypto mailing list