[pycrypto] RSA exportKey() changes set in stone for 2.7?

[Dwayne Litzenberger]

On Mon, Sep 30, 2013 at 10:28:20PM -0700, Kurt Vogel wrote:
>On Sun, Sep 29, 2013 at 6:52 PM, Dwayne Litzenberger 
><dlitz at dlitz.net>wrote:
>> The exportKey API should be considered experimental at this point.  
>> There are things about it that don't really make sense (e.g. the 
>> `pkcs=1` parameter, which doesn't make any sense if you want to 
>> expoer in OpenPGP format, for example).  Realistically, it should 
>> probably be removed from Crypto.PublicKey and placed into Crypto.IO, 
>> but I'm not sure of exactly when that will happen.
[snip]
>Thanks, that is what I was assuming.  If we move import/export to 
>Crypto.IO it will break backwards compatibility, no?  Is that 
>important?
>
>Is anyone working on this issue?  If backwards compatibility is 
>important I say keep what we have there now (2.6) and have a 
>deprecation comment and/or stderr output?

Yes, that's the idea.  Even with a move to Crypto.IO, RSA.exportKey and 
RSA.importKey should continue to work during a deprecation period---but 
only to the extent that they work in PyCrypto 2.6.1.  I make no promises 
about what's in the master branch of the git repo.

>Also does Pycrypto have deprecation/error transition plan?  To ease 
>transition some packages first do a deprecation warning, second major 
>release it becomes an error/exception, then third major release the 
>code is completely removed.  Would that work with pycrypto users?

That's what I usually aim to do, but the very few people who work on 
PyCrypto are volunteers, so we can't make hard promises.  Obviously, 
compatibility is important to us (or we wouldn't be supporting really 
old versions of Python), but I weigh it against other factors.  For 
example:

1. I only worry about backward compatibility between stable releases, 
and only for public interfaces. (If it starts with an underscore, expect 
it to change.  Ditto if something has been introduced in an "alpha" 
release.)  Absolutely no guarantees are made about any part of the git 
repo that hasn't been tagged as a 'final' release.  I'm not *opposed* to 
a few people using the master branch in their own projects (the early 
feedback is helpful), but things will break and you'll need to be 
prepared to fix them.

2. I'm willing to break backward compatibility to fix a regression that 
broke backward compatibility with a previous version.  For example, v2.6 
silently changed the semantics of the Cipher .IV attribute.  I'm willing 
to undo that in v2.7 (any maybe even v2.6.2) without a deprecation 
period.

3. I'm willing to break applications that were already insecure anyway.  
(For example, making IVs mandatory for CBC/CFB/OFB modes in PyCrypto 
v2.6.)  My view is that the security of end-users is more important than 
convenience of developers using PyCrypto, and it's better to break an 
insecure application than to let it continue to give users a false sense 
of security.

3.a. If an interface is highly error-prone and has relatively few users, 
I might be willing to break existing applications in order to prevent 
new applications from being written than use the error-prone interface, 
especially if there's a trivial fix that will work with both the old and 
the new versions of PyCrypto.

4. I'm willing to remove features that I don't think are used much 
(especially if they're broken).  They can always be re-introduced if 
people complain (nobody has complained about any removed features, so 
far).

5. I'm willing to remove legally problematic code.

6. I'm more willing to break things in a "fail-safe" manner than a 
"fail-open" manner.  (For example, I might consider changing 
PKCS1_PSS.verify() to raise an exception instead of returning False on a 
signature verification failure, but I would go from raising an exception 
to returning False.)

In general, I think it's better for end-users if everyone collaborates 
on the same tree, so I try to make things easy for developers and 
distros.  However, my priorities are the security of end-users and 
keeping the code complexity manageable.  Every change can potentially 
break something for somebody, so I try to weigh the impact of each 
change on a case-by-case basis, taking everything into account.

The more information I get about how PyCrypto is being used, the better 
my decisions can be.

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