On Monday, July 23, 2012 15:25:17, Ron wrote:
> 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
[…]
> > > - 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.
I have no objection.
There has been no private discussion with any of the parties in the bug AFAIK.
The main reason I was considering the embedded version was because the celt
library is removed in Sid. The only possible benefit of using celt 0.11.0 is
only if it somehow improves interoperability with other distros, that from
what you mentioned used embedded celt -- but this is certainly /not/ a
requirement.
> > Surely we want to avoid having multiple different versions if at all
> > possible.
>
> Absolutely.
> Anything else only increases our exposure surface to unmaintained code.
I think I agree with that.
[…]
> > 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.
It will be good if a solution with Speex will work out such that celt can go
away. On that I think we're all on the same page, but I have my doubts if it
will work with existing servers. Hopefully it does.
[…]
> > 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.
The term "browbeaten" is objectionable, as from our point of view mumble
became completely unusable to talk to the rest of the world, there wasn't
sufficient information available to understand the issue, and ... so on.
Please just try to stick to the technical issues so I may do the same, because
those are things we're much more likely to agree on.
> 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.
Cool.
> 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.
Seven versions of celt? No, I'm not looking to enable THAT.
> 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.
No objection.
> 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.
I'm okay with shipping opus as long is it doesn't cause compatability
problems, because support for it is just starting to be rolled out, but as
there seem to be very few existing clients that support it today I'm also
concerned that support for it isn't stable. It'll require testing, and I'm
willing to help with that.
> 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.
Thanks
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.