Source: libotr Version: 3.2.1-1 Severity: important X-Debbugs-Cc: secur...@debian.org, anar...@koumbit.org, tails-dev@boum.org Control: tag -1 + security Control: found -1 3.2.0-2+squeeze1
Hi, as you are surely aware of, it's been known [1] since 2006 that clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject to protocol downgrade attacks clients. It's also been known for a while that OTRv1 has serious security issues (that were the main reason for a v2, actually). In short, support v2 only is the only safe way to go these days. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945 It took a while to obsolete older v1-only software, and another while to complete the libotr 4.x transition and get to a sane state in Debian testing. Now, I think the time has come when we can reasonably expect v2-only to work for everyone. I think that the only reasonable course of action from now on is to patch libotr in stable and oldstable to only support OTR v1. Thoughts? JFTR, libotr 4.x (testing/sid) is not affected by these issues (fixed in upstream commit 7ffba65f). (The only alternative I can think of would be to remove it from stable, remove all reverse-deps that are useless without OTR support (e.g. pidgin-otr), patch all reverse-deps that are useful without OTR support (e.g. kopete) to drop it, and prepare tons of backports. This requires tons of work, coordination with many package maintainers, and approval from the release team. I don't think we want to go this way.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev