[pycrypto] Is PyCrypto dead?

[Dave Pawson]

I've insufficient knowledge to tweak code.
I do believe the documentation could be improved.
How to split out the documentation into n parts,
at least one favouring usage, examples, testing etc.
If I believed the list/site was live, I would work on that
and submit it for review.
 The requirement surely is to document fully the API, but
also provide ... a guidance /usage document set?

Getting no response from the maintainer is not conducive to submitting anything?



regards



On 12 May 2014 17:03, Dwayne Litzenberger <dlitz at dlitz.net> wrote:
> It's not dead.  Due to some personal issues, I just have very little time to
> work on the project right now, and unfortunately I haven't been able to find
> someone I trust to hand off maintenance to.  It seems that most contributors
> either want to add their pet algorithms[1] (increasing maintenance
> overhead)]---or they introduce potentially serious vulnerabilities[2][3],
> bizarre[4] or inconsistent[5] APIs, performance issues, etc.
>
> That's fine; Crypto is hard, but it means progress is slow, because I have
> to go over everything with a fine-toothed comb, and it's hard to find the
> time do it, and I'm reluctant to merge code that might make things worse for
> existing end-users, even if this makes some developers unhappy.
>
> If a fork is necessary, Sebastian Ramacher is probably the person I trust
> the most---at the moment---to maintain it.  His patches have been
> consistently good, albeit small, and he's the Debian package maintainer, so
> a lot of people are already implicitly relying on him anyway.
>
> I'm hoping to spend more time on the project soon, but my availability is
> hard to predict in advance.  Hopefully, things will be better in the next
> 6-12 months, but I can't promise anything.
>
> In the meantime, there are a few things that might help in the short term:
>
> - Having some process for triage & code review, so that the community   can
> vet and patches, and also ensure that the master branch remains in   a
> releasable state.  Right now, I have an unordered set of pull   requests to
> deal with.  It would be great if this became a queue that   was prioritized
> according to quality and the current release goals.
>
> - CI infrastructure.  It would be really helpful if all pull requests   were
> automatically tested against.  Like [6], but actually covering   all
> currently supported configurations.
>
> - Moving bug tracking to GitHub (from Launchpad).  Using both tools has
> been pretty cumbersome, but I've been reluctant to disrupt things.    Any
> objections to this?
>
> - If anyone is in/near San Francisco and wants to help with this, it   might
> help if we introduced ourselves in person.
>
> Does anyone want to champion this?
>
> Regards,
> - Dwayne
>
> [1] https://github.com/dlitz/pycrypto/pull/76
> [2] https://github.com/dlitz/pycrypto/pull/50
> [3] https://bugs.launchpad.net/pycrypto/+bug/1176482
> [4]
> https://github.com/dlitz/pycrypto/blob/f9a0fc77e1c8847c1a17503e5a1b86a409b8cb2d/lib/Crypto/PublicKey/RSA.py#L318
> [5] https://bugs.launchpad.net/pycrypto/+bug/1132550
> [6] https://github.com/dlitz/pycrypto/pull/60
>
> On Mon, Apr 21, 2014 at 09:44:16PM +0200, Legrandin wrote:
>>
>> Is PyCrypto dead?
>>
>> If one had to judge from the speed security flaws are recognized,
>> fixed and disclosed [1], then no, pycrypto is definitely not dead.
>> Other, more active FOSS library should take notes in fact.
>>
>> However, when it comes to adding new features (as in, catching up with the
>> needs of a normal security application in 2014) and refactoring the
>> existing ones, pycrypto is deep frozen. Bug reports keep piling up and it
>> can easily take a couple of years for a pull request to finally end up in
>> a
>> release.
>>
>> Every now and then, I can read on the ML proposals and intentions for
>> major (and IMO, not entirely needed) overhauls, but they never seem to
>> translate into anything solid. Worse than that, their completion is set as
>> the
>> precondition for acceptance of any new feature, which further exacerbates
>> the problem.
>>
>> What can be done to improve on that?
>> Would setting up a tip jar help?
>> Would a fork of the library be seen as hostile?
>>
>> Finally, I am aware of the existence of the cryptography project [1].
>> It does *not* cover my needs and I do *not* agree with some of the
>> principles and motivations behind that design, though its dev and test
>> processes are clearly sound.
>>
>> [1] http://lists.dlitz.net/pipermail/pycrypto/2013q4/000702.html
>> [2] https://cryptography.io
>
>
>> _______________________________________________
>> pycrypto mailing list
>> pycrypto at lists.dlitz.net
>> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>
>
>
> --
> Dwayne C. Litzenberger <dlitz at dlitz.net>
>  OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7
> _______________________________________________
> pycrypto mailing list
> pycrypto at lists.dlitz.net
> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk