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

[Sebastian Ramacher]

On 2013-01-02 12:35:36, Michael Bienia wrote:
> 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:

I'll check if the changes are easily backportable. There is also another
CVE that is unfixed in wheezy.

> "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.

Yeah, it should have the Breaks. I'll look into that.

> 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.

NACK with my python-crypto maintainer hat on. I'm not opening this can
of worms again. One CVE because of that is already one to much.

Regards
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/ubuntu-dev-team/attachments/20130102/afad2776/attachment.pgp>