[pycrypto] DES/DES3/XOR/etc removal

[Jean-Paul Calderone]

On Wed, 22 Apr 2009 17:05:20 -0400, Thomas Dixon <reikon at reikon.us> wrote:
>Tzury Bar Yochay wrote:
>> please keep the DES3 and XOR.
>> we use them and need them in our ongoing projects
>>
>> On Wed, Apr 22, 2009 at 8:23 PM, Jean-Paul Calderone
>> <exarkun at twistedmatrix.com <mailto:exarkun at twistedmatrix.com>> wrote:
>>
>>     Hello,
>>
>>     Someone pointed out that XOR and several other ciphers [1] have been
>>     removed from PyCrypto.  This has the consequence that Twisted Conch,
>>     and SSH client and server implementation which depends on PyCrypto,
>>     no longer works with the latest development version of PyCrypto, and
>>     I assume that when the next release of PyCrypto is made, Conch also
>>     won't work with that.
>>
>>     I'm curious how important backwards compatibility is deemed with the
>>     new PyCrypto development going on.  A change like the one referenced
>>     above is going to break users of PyCrypto (and that seems like it is
>>     really obvious, to me - as opposed to a change which only accidentally
>>     breaks applications).  The added maintenance burden this causes makes
>>     PyCrypto less attractive (one nice thing about PyCrypto having been
>>     unmaintained for a long time is that Conch's use of it stayed as
>>     correct (or incorrect) as it was when it was written).  Basically, the
>>     question is whether I should expect more PyCrypto changes like this
>>     as development proceeds, or whether I can make the argument that
>>     backwards
>>     compatibility is a *good* thing compelling.
>>
>>     Of course it's one thing to say "more backwards compatibility please".
>>     Actually deciding how that can be accomplished while allowing
>>     development
>>     to proceed in a useful direction is another.  However, I'm
>>     intentionally
>>     omitting details of that discussion from this message to keep things
>>     simple.  I'm convinced that some degree of backwards compatibility is
>>     always possible, regardless of the changes desired, so the details
>>     of how
>>     it works aren't as important as deciding whether backwards
>>     compatibility
>>     will be maintained.
>>
>>     So, what do you say?  Can we decide that backwards compatibility
>>     is a good
>>     thing?
>>
>>     Jean-Paul
>>
>>     [1] -
>>     http://gitweb.pycrypto.org/?p=crypto/pycrypto-2.x.git;a=commit;h=5b5b496c0f81f3595d0aebb8da5196492abae429
>>     _______________________________________________
>>     pycrypto mailing list
>>     pycrypto at lists.dlitz.net <mailto:pycrypto at lists.dlitz.net>
>>     http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> pycrypto mailing list
>> pycrypto at lists.dlitz.net
>> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>>
>Personally, if Dwayne has decided to remove Blowfish, DES, 3DES, RC5,
>IDEA, and XOR, then I agree with that decision completely. From a legal
>and security standpoint, it makes perfect sense. There's also nothing to
>say that Dwayne won't add different implementations of some of these
>algorithms back into PyCrypto's offerings at a later date.

Great.  If that's the plan, then my complaint is moot.  My concern is
that the next release of PyCrypto won't have these APIs.

I understand that there are legal issues, but they're not new - PyCrypto
has had whatever they are for almost a decade - maybe *more* than a decade,
I dunno.  I'm all for resolving them, but I don't think the resolution needs
to be immediate, given that it is going to break things.  Go ahead and
deprecate the APIs with implementations that are not licensed compatibly
with the rest of PyCrypto, and even remove them after having deprecated
them for a while.  But don't just delete them without warning and surprise
all the application developers relying on them.  Again, if the plan is to
restore these APIs with new implementations, great, I'll stop complaining.

>Remember:
>Those who will primarily suffer from a software developer's laziness are
>their users.

I don't know what you mean by this.

Jean-Paul