[pycrypto] Is PyCrypto dead?
dave.pawson at gmail.com
Mon May 12 10:49:11 PDT 2014
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?
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 (increasing maintenance
> overhead)]---or they introduce potentially serious vulnerabilities,
> bizarre or inconsistent 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 , 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?
> - Dwayne
>  https://github.com/dlitz/pycrypto/pull/76
>  https://github.com/dlitz/pycrypto/pull/50
>  https://bugs.launchpad.net/pycrypto/+bug/1176482
>  https://bugs.launchpad.net/pycrypto/+bug/1132550
>  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 , 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
>> 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
>> 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 .
>> 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.
>>  http://lists.dlitz.net/pipermail/pycrypto/2013q4/000702.html
>>  https://cryptography.io
>> pycrypto mailing list
>> pycrypto at lists.dlitz.net
> 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
XSLT XSL-FO FAQ.
More information about the pycrypto