Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to
> > CELT codec library removal"):
> > > > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > > > > 1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > > > >
> > > > > codec library [very undesirable]
> > > > >
> > > > > 2) Same as 1) but with embedded CELT (would need testing)
> > > > > 3) drop mumble from Wheezy
> > >
> > > Of these 2. would seem to be the best option.
> >
> > I agree.
> >
> > Pros:
> > - Solution should work for both Wheezy and Sid
> > (-2 in Sid currently has no celt support, and celt is the most widely
> > used codec in mumble on the 'net)
> > - Would use celt 0.7 as well as 0.11
>
> I'm not sure I follow this. Are you saying that enabling the embedded
> celt would necessarily involve enabling /two/ versions of celt ? (And
> you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> so I'm confused about that too.)
This is absolutely not _necessary_, and not at all what I had in mind
in the previous discussions of this option.
It is _possible_ for mumble to embed many versions of celt simultaneously,
and perhaps Nicos and Chris had discussed this privately, but this is not
what we should be doing here. If we take this option at all, then we
should use precisely the same celt code we have been using before now,
the 0.7.1 release.
> Surely we want to avoid having multiple different versions if at all
> possible.
Absolutely.
Anything else only increases our exposure surface to unmaintained code.
> Is it essential to support anything other than 0.7.1 ?
No. We have never shipped a version that supported anything else.
> I thought upstream had declared 0.7.1 to be a baseline so that would
> be sufficient.
Correct. (well, ostensibly correct, that's what upstream declared, but
apparently there are live servers in existence which don't respect this
and want to force other arbitrary versions of celt too).
For decoding speex actually appears to be the only baseline that we
really can trust all clients will have and all servers will support.
> And if 0.7.1 is sufficient, can it be done using an embedded copy
> right now with a build system change, or would we have to dump a
> special copy of celt 0.7.1 into the mumble source package ?
I'll have to look at exactly what has been included in the recent
tarballs, the upstream git repo is a bit of a hodge-podge of git
sub-modules, embedding various versions of various external libs,
all of which we currently do not use at all. There will be some
diff, but I haven't looked at how big in detail yet.
> > Cons:
> > - Larger diff in mumble
>
> Is it in fact a substantial diff ? I thought it was essentially a
> configure option.
That will depend on the above, but if it's "substantial" it should
be fairly much limited to a single subdirectory adding the celt code.
I'm not concerned about our ability to do this correctly should we
choose to, only about the advisability of continuing to use celt
at all.
> > - Would greatly irritate mumble maintainer
>
> Rather than consider someone's emotional state, I'd rather focus on
> their views.
Amen.
> That is, if this is a bad idea according to the mumble
> maintainers then I'd like to hear why they think so.
My primary concern is with the fact we would be shipping very complicated
code, that only about 3 people in the world really understand, and which
has no committed ongoing maintainer from among them or anyone else.
If there is a consensus among the members of the TC and the security
team that the risk of doing that is justified by other factors, then
I'll consider the peer decision making process to have worked as it
should, and quite the opposite of being 'irritated', I'll be quite
relieved that this decision and its possible consequences do not fall
on my head alone.
I was not comfortable unilaterally making the decision to continue
shipping celt with the knowledge I have of its situation, and I wasn't
going to be browbeaten by users who shared no part in the risk they
wanted to expose others to. That's very different to the TC putting
its judgement on the line, and the security team committing to do the
work should it come to that.
If they all agree this is our best option, then I have no problem with
deferring to that opinion. As I said previously, it won't take a formal
vote to convince me if consensus is that this is the best thing to do.
I think I'd still like to see us explore the speex option. But the
release clock is ticking, and I'd be lying if I said I wasn't anxious
about squandering what time we have left by not having real users
really out testing all this and reporting the bugs they find.
The bottom line on the compatibility matrix is that the *only* way to
ensure we really are compatible with all extant systems is to:
- Ship with speex reenabled.
- Ship with all seven or so versions of celt enabled.
- Ship with opus enabled.
I think we can all quickly agree that shipping with more than one
version of celt is crazy-talk, and the only option we need to consider
there is 0.7.1.
Speex is our most certain baseline, because all clients support it,
and no server support is required.
Opus support we need, because we likewise have no guarantee that
Fedora or other distributions will not assess the celt risk to be
too great and ship their subsequent releases with only Opus and/or
speex enabled (just to pick one other distro out of the hat).
Either way it *will* be widespread long before the end of life of
wheezy, so not supporting it will just disadvantage our users,
and possibly put them right back in the situation we are presently
trying to avoid. The new server does have an opus threshold option
and once critical mass of that is triggered, clients without opus
will not be able to talk or hear other users. That will be released
upstream for all users when Thorvald gets back, whatever we do.
So ... really the only decision I see to be made here, is will we
ship with celt 0.7.1 enabled or not. If -ctte and -security weighs
up the risks and tells me they are happy doing that, then I'm happy
to make that happen with no further delay.
Is there anything I've still missed?
Cheers,
Ron
Reply to: