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 <giles@mozilla.com>
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 3.8.3.0 (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
Attachment:
signature.asc
Description: This is a digitally signed message part.