Re: mumble and celt, #682010, TC

[Thorvald Natvig <thorvald@natvig.com>]

On 7/19/12 11:45 AM, Ian Jackson wrote:
> Thorvald Natvig writes ("Re: mumble and celt, #682010, TC"):
>> For now, the easiest is probably to re-enable Mumble to build the
>> embedded CELT, something it currently does not do. That way it is just a
>> single package, and we can deal with problems as they come up.
> Since Ron is listed as co-maintainer for mumble do you feel you have
> the authority to do this ?  I imagine Ron would object, so you would
> in any case need a TC ruling to arbitrate between you.
>
> We would have to clear this approach with the release team.

I actually haven't been that active on the package for the last few
months, and I've been reading through the changes in git now. The
current mumble packaging has CELT completely disabled. That means a
debian user of Mumble cannot talk to anyone that isn't using the *same*
debian version of Mumble, and they are both connected to a server
running on a Debian box. If we change the package format for Opus before
the next major release, both of these will also be incompatible with
future clients. While this does indeed package a version of Mumble in
debian, and this version does not use the potentially vulnerable CELT,
it isn't really a version that does what the users expect, which is to
be able to talk to other users on other platforms.

Judging from what little I can find of discussions and changelogs, I do
find it likely Ron will object to being forced to re-enable CELT when he
strongly believes it should be disabled. At that point, this boils down
more to a resource question than a "who is right" question; I have
severely limited spare time for new next few months, and if Patrick has
already withdrawn from this package, the only remaining short-term
maintainer is Ron, meaning his decision will stand as he is the one
actually doing things.


Maybe the right solution is to apply some upstream pressure in Mumble
(as in, on me) to finish the Opus support on other platforms and make a
new major release. This would help transition the majority of our
userbase to a Opus compatible version, at which point this entire
problem goes away.

>> Krautz, another Mumble developer, has some proof-of-concept code to
>> sandbox CELT using seccomp. If the CELT in Mumble was stand-alone, we
>> could apply this sandboxing to the local copy we have there. It is
>> another of the "not ready yet" solutions, but if it is needed, it will
>> be much easier to retrofit this inside Mumble itself than it would be to
>> do it in a global package.
> Thanks for the consideration but this is not very useful to us for
> Debian wheezy.  But the Debian Security Team have said that while they
> have reservations they do not consider celt upstream to be
> non-release-critical.
>
> Am I right in thinking that enabling the builtin 0.7.1 alongside the
> other builtin versions of celt only makes the security situation worse
> by bugs that are in 0.7.1 but in none of the other embedded version of
> celt which are currently enabled ?  (Which are those?)

On Debian, we've never enabled any of the embedded versions, they're
only built if your system does not have CELT 0.7.1 installed. The only
one we would need is 0.7.1, as that is the fallback format we support on
all platforms.