On Wednesday, July 18, 2012 19:15:01, Ian Jackson wrote: > Chris Knadle writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"): > > Package: tech-ctte > > Severity: normal > > ... > > > This refers to Bug #675971 (which is severity grave, and currently > > closed) against the Mumble VoIP package, which is also affected by Bug > > #674650 concerning the removal of the CELT library. This evening we > > also just discovered the existence of Bug #674634 which concerns the > > CELT library removal as well, and which may have more of the technical > > story. > > Thanks for this, including the clear summary. You're welcome. Thanks very much for looking into this. > > - From the point of view of the bug reporters, what we want is a > > > > package that inter-operates with other Mumble clients and servers, > > if possible. To do this today would require reintroducing the celt > > source package again, which is rumored to have potential security > > issues. [We have not seen any details on this yet.] > > > > Note: this evening we think we have found a security expert who is > > willing to audit the CELT 0.7.1 codec for issues and possibly provide > > patches, assuming this is reasonably feasible. > > This sounds like a good option to me. I will write to the security > team and ask them for their opinion about CELT. I agree this is a good idea. > From what you say I think: > - We should try to address the security problems, if any, in the celt > 0.7.1 codec. An audit would be very good. The professional security expert I've been put in contact with has begun having a look at the CELT codec. [I'll ask if he is okay with being named.] This is the most relevant portion of his initial response: ------------------------ CELT's git repository shows the last significant burst of activity was in April of 2011. The last commit confirms upstream is EOLed. commit e18de7747fb1655e66bf8d291560587036bfe53c Author: Ralph Giles <firstname.lastname@example.org> Date: Wed Sep 14 12:23:04 2011 -0700 Direct users at the opus repository. This repository is no longer used for active development. […] Currently, I'm trying to collect as much information as possible on libcelt. I will be reading the API documentation to get a feel for the architecture / call-graph. Also interested in any example code that decode CELT packets; this will give me an idea of which structs/functions to fuzz. Any rumours of crashes, unresolved bug reports or coredumps also helps the bug hunt. Finally, I will read every single line looking for insecure code patterns. :) ------------------------ > - This is a serious problem for mumble at least and is arguably RC. Yes I think I agree. I just reopened #675691 and blocked by #682010 to keep the bug marked RC for now. > Do you have people who are willing to be the maintainer(s) and (if > necessary) sponsor(s) for the celt package ? I have not attempted to discuss aspect this with anyone yet. Of the people I've been working with concerning the technical issues of the bug report so far, AFAIK none of us are DMs nor DDs. I've been doing some learning and successful packaging work in preparation for attempting to upload through [debian-mentors] but have not tried to upload to them yet, nor packaging of a library. [Maybe I'm just chicken. :-P] However in the spirit of good faith and Debian do-ocracy I'll volunteer to maintain or co-maintain unless someone with more experience would like to do it. If I end up being maintainer it will likely mean going through [debian-mentors] -> sponsor -> NEW queue -> ftpmasters -> Debian Unstable unless another DD volunteers to review the prospective package and sponsor. Additionally if we plan to re-introduce the CELT library, maintainers that had packages using CELT need contacting if an opportunity is to be given for those packages to be [un]patched to re-add CELT support again desired. This would naturally depend on getting CELT uploaded and accepted, which is where having a DD take over maintainership and upload would save time. Additionally the Mumble client in 1.2.3-349-g315b5f5-2 will not use the CELT library even if it is installed, which means that the mumble package will require [un]patching for this as well if CELT support is to be made available again. > I assume it would be possible to reintroduce a celt package which was > very similar to the one recently removed, so as to avoid risking > unnecessary bugs. It looks like that would probably work. The current celt source package uses individual debhelper calls with compat level 5 and is not multi-arch aware; I'm wondering if multi-arch support is something worth considering at this stage. The current celt source package from Wheezy (via apt-get source) builds and seems to function correctly, appears to be piuparts clean, but has some lintian warnings to look into [see below] -- and some autoconf related files are left behind after a cleanup of the build. Curiously the associated celt git repo will not build when tag v0.7.1-1 is checked out (the same version in Wheezy), even when the associated source tarballs are in place, and I'm not sure why that is yet. Lintian warnings: W: celt source: debhelper-but-no-misc-depends libcelt-dev W: celt source: debhelper-but-no-misc-depends celt W: celt source: debhelper-but-no-misc-depends celt-doc W: celt source: debhelper-but-no-misc-depends libcelt0-0 W: celt source: ancient-standards-version 188.8.131.52 (current is 3.9.3) W: libcelt0-0: hardening-no-relro usr/lib/libcelt0.so.0.0.0 W: libcelt0-0: hardening-no-fortify-functions usr/lib/libcelt0.so.0.0.0 W: libcelt0-0: description-synopsis-starts-with-article W: libcelt-dev: description-synopsis-starts-with-article W: celt: hardening-no-relro usr/bin/celtdec W: celt: hardening-no-fortify-functions usr/bin/celtdec W: celt: hardening-no-relro usr/bin/celtenc W: celt: hardening-no-fortify-functions usr/bin/celtenc W: celt: description-synopsis-starts-with-article W: celt: binary-without-manpage usr/bin/celtdec W: celt: binary-without-manpage usr/bin/celtenc -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Description: This is a digitally signed message part.