[ubuntu-dev] Bug#693372: ubuntu-dev-tools: requestsync fails "ValueError: IV must be 16 bytes long"

[Michael Bienia]

On 2012-12-30 18:40:23 -0800, Vincent Cheng wrote:
Hi,

> Michael: the reason why python-keyring can't migrate to testing right
> now is because Debian is in freeze, and updates such as new upstream
> releases don't comply with the freeze policy [1]. Is there a way to
> fix this bug with the current version of python-keyring in testing
> instead?

There is no other way than to "fix" (by either backporting the fix or
allowing python-keyring to migrate) python-keyring in testing[1]. The
current python-keyring from testing doesn't (partly) work with
python-crypto from testing as python-keyring from testing uses an empty
initialisation vector for the cypher to encrypt the keyring. Older
version of python-crypto wrongly allowed this but it got fixed in
python-crypto 2.6 which migrated to testing while a fixed python-keyring
didn't.

So someone needs to talk to the release team and security team how to
resolve the current situation regarding python-keyring by either
backporting the fix from python-keyring 0.9.1 to 0.7.1 or letting
python-keyring migrate:
"CryptedFileKeyring now uses PBKDF2 to derive the key from the user's
password and a random hash. The IV is chosen randomly as well. All the
stored passwords are encrypted at once. [...]" (this is CVE-2012-4571
and unfixed in testing).
Ideally python-crypto would have a "Breaks: python-keyring (<= 0.7.1-1)"
to enforce an upgrade of python-keyring when python-crypto get upgraded.

Unfortunately python-keyring 0.9.x also introduced a new keyring format
with this change. python-keyring 0.9 contains migration code from the
old format to the new format. This code got already removed again in
python-keyring 1.0 and any unconverted keyrings have to get converted
manually. While 1.0 won't be in wheezy, it will certainly be in jessie
and the Debian package would need to carry the migration code or
instruct the user how to upgrade its keyring files. (See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675379%3b#38)


1: There would be an other option: to undo the change in python-crypto
which enforces an non-empty IV but it's not a sane option security-wise.

Michael