[pycrypto] RSA exportKey() changes set in stone for 2.7?
dlitz at dlitz.net
Sun Oct 20 13:24:22 PDT 2013
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.
>Thanks, that is what I was assuming. If we move import/export to
>Crypto.IO it will break backwards compatibility, no? Is that
>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
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
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
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
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
More information about the pycrypto