intrigeri <intrigeri@debian.org> (2013-12-22):
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: pu
>
> As discussed on #725779 in more details, the OTRv1 protocol has
> serious security issues. Clients supporting it (in addition to more
> recent, safer versions of the protocol) are subject to protocol
> downgrade attacks.
>
> This is why I have proposed to drop support for OTRv1 in libotr in
> Wheezy.
This makes me wonder whether there are some packages only supporting
OTRv1 in wheezy. If there are, I suspect they want to get a serious bug
since they won't work at all anymore. Could then be fixed by trying to
make them support something less broken that OTRv1.
(AFAICT, clients might be hardcoding OTRL_POLICY_ALLOW_V1 instead of
using the OTRL_POLICY_{OPPORTUNISTIC,MANUAL,ALWAYS}?)
> As the discussion on the aforementioned bug indicates, the maintainer
> agrees and the lead upstream developer confirms it is "totally fine".
>
> I have therefore backported the relevant bits of the upstream commit
> that does just the same in libotr 4.x (currently in testing/sid). The
> resulting package was successfully tested with pidgin-otr on Wheezy,
> and inter-operates correctly with sid's pidgin-otr and irssi-otr
> 1.0.0~alpha2-1~bpo70+1.
I think I like the reasoning and the tests very much.
> FTR, testing/sid has libotr 4.x that is not affected by these issues.
The BTS wants to be taught that.
> May I upload libotr 3.2.1-1+deb7u1 to stable?
Looks fine to me.
Mraw,
KiBi.
Attachment:
signature.asc
Description: Digital signature