Re: #682010 re celt and mumble referred to the TC
Hi Ian,
Being cc'd on this would have been nice, so apologies in advance if I
messed up any quoting by pasting stuff in.
On Thu, Jul 19, 2012 at 12:26:01AM +0100, Ian Jackson wrote:
> > 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.
>
> >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.
You understand this is a fairly arbitrary 'daily' snapshot of an
experimental research codec, from ~2.5 years ago, that nobody has
looked at since that day, that nobody has committed to maintaining,
that its author has explicitly said he has no interest in maintaining,
that has had large parts completely rewritten since for all manner of
reasons, and is bitstream incompatible with every other snapshot that
was ever released, right?
And that its successor code has been reviewed in detail by some of the
brightest minds of the IETF, prior to accepting that code as being the
normative part of a proposed standard (which has now occurred) - and
without exception, all of them said "this is way too deep for me,
I'm going to have to take the WG report on faith that it's sufficiently
debugged now" ...
If skilled people have time for auditing, I'd love to see the code from
the RFC pass under their eyes as a better, more enduring, use of their
time. But this isn't something people are likely to find high school
programming errors in from a quick read through or automated scan, or
are likely to shake things out of just with simple fuzz testing.
On the contrary, I fully expect mumble to have also EOL'd this long
before anyone else, except perhaps the most dedicated blackhats, have
understood even half of what goes on in this code, or the astronomical
number of state transitions that are possible within it. And they have
a 2.5 year head start on anyone who might try starting from today.
> - This is a serious problem for mumble at least and is arguably RC.
Yes, mumble has a serious problem, that is arguably RC.
In fact it has several of them aside from this corner that people
have painted themselves into with it ...
- Its primary author, who is also a DD and comaint of the package,
is currently MIA with a new job that has consumed pretty much
every minute of his time for the last 2 years or so now.
The people who remain that are hacking on it, can't even do a
formal new release at present, because he is the only one with
access to the systems they need to do that, and is not available
to do so.
They are all busy too, so there is very much a culture of
"close your eyes and pretend it's all ok" there at present.
- It has other deps in the distro aside from this one that appear
to be near enough to completely unmaintained too. Have a look
at the code for zeroc-ice, and the ABI breaking patch that was
blindly applied for gcc 4.7 and then left unfixed until Svedrin
and I got stuck with the job of unscrewing that, and share in
our tears ...
- It has a small subset of users who would rather risk everyone's
systems, than simply update their most ancient servers and tell
their friends that it's time for a security update too.
Which is all it takes to 'fix' this.
FWIW, even the original poster of the bug in question later agreed
in calmer discussion on IRC that the Right Thing for mumble to do
is to release 1.3 and accelerate the migration, and that is only
being delayed now by the first point above.
This particular problem being raised here was entirely avoidable.
Only a lack of foresight that the primary author of this software was
going to be taken by the rapture, and a subsequent failure to plan
for that loss by migrating to options that actually have maintainers
ahead of the crunch date, have left us in the situation we are in
today. These aren't things I usually associate with the idea of
something being viable stable release candidate software ...
If I'd known that Thorvald was not going to be here to manage this
transition for Wheezy, I'd have never agreed to shipping libcelt in
the Squeeze release either, and would have instead kept it in sid
only. If I'd known that his plan to have all other distros ship
the 0.7.1 release as a temporary interoperability snapshot would
fail as dismally as it did (no other distro shipped this version
except debian derivatives who took it from us), I'd have similarly
vetoed the idea of shipping this as a public library in the last
stable release too.
Mumble already ships this as an embedded private library on every
system other than direct Debian derivatives.
> 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.
I see that this proposal has already resulted in Chris skating down
the slippery slope of "let's re-enable it for everything else too".
And we'll get people with no experience or prior involvement to
maintain it, and we'll enable multi-arch too, and ...
So I really hope that it's actually clear to the people presiding
over the tech-ctte, that the *whole point* of a codec is that it
lets you *interoperate* with others. Which this snapshot does not.
Continuing public releases of an obsolete experimental snapshot, that
will only create confusion with a now published internet standard,
is not the way to encourage users that they really do have viable
alternatives to patent encumbered codecs. Doing this would make
us our own worst enemy to the causes and philosophy that we say we
stand for. They'll have a bad experience, and maybe blow out their
speakers, and then blame the codec, and its authors and everything
they touch - not the people who should never have shipped it and
who were explicitly advised not to.
If people really want to do this for mumble, then it really ought
to be done as a private implementation detail, like it is for every
other platform - not by setting traps in public for the unsuspecting
and otherwise uninformed. If we ship celt publicly, we are sending
the message that people should use it. That's the wrong message
for an obsolete, unmaintained codec, and there is no reason to tie
'being pragmatic' about the mumble screwup to making an even bigger
mistake. That's not 'avoiding risk', it's "not avoiding risk".
And one that is really, really trivial to avoid.
Anyhow, this is already too long, and it's still not even half the
full story - but I have paying customers, who do trust my judgement,
that have work which needs to be done - and I don't expect anybody
is really going to digest the full implications here if I do just
write more, so I'll open the floor to intelligent questions.
My general feeling is that mumble is currently in an awkward state
which really doesn't make it a good release candidate for Wheezy,
and we'd probably be best served by simply dropping it from testing,
fixing this in sid as the fixes come or are needed, and then pushing
snapshots to bpo as we have reasonable candidates for that.
That was my original recommendation to the release team, but Phil
offered to cut us some slack with letting things in if I did try
to salvage it for Wheezy proper, so Svedrin and I put in the effort
to make that as possible as it might be.
Maybe that really was a mistake. I don't mind taking full
responsibility for my mistakes - but being bullied into making
even bigger mistakes, by people who didn't understand the set
that created the problem in the first place, is not in my usual
definition of wisdom, and the crux of my disagreement with the
crusade that Chris has embarked on here.
Since he didn't bother to wait for Josh and I to discuss that
further, now we're here ...
Sorry,
Ron
Reply to: