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
signature.asc
Description: Digital signature