Bug#682010: [mumble] Communication failures due to CELT codec library removal
Ron writes ("Bug#682010: [mumble] Communication failures due to CELT codec library removal"):
> I understand your line of thinking there, and for 99% of the code in the
> world, I'd be in complete agreement. I'm not someone who is afraid of
> code, or of getting my hands dirty in it, but we're not talking about
> simple programming errors here - if and where there are problems, they
> are in the boundary conditions of some very deep math that often still
> confuses the people who created it until they stop and think very hard.
In order to support this in wheezy we do not need to be able to fix
general bugs in the codec or analyse and understand its signal
processing behaviour.
We have only to be able to fix security problems, and it is normally
possible to find and fix such security problems without needing to
understand the purpose of the signal processing algorithms; typically
they would occur (as with decompressors) in the handling of invalid
packets.
I have some experience of this as in a past life one of my
responsibilities was security audit and response for a manufacturer of
HSMs, so I have some idea of what's involved.
Looking at the code I agree with Nico that it's not marvellous. And
it's rather too voluminous to audit. But I don't think it's
significantly worse than other codecs. In particular looking at the
opus code in sid it seems very similar in style and quality. The only
difficulty is that it's different enough to make backporting changes
nontrivial.
Looking at some sample diffs there seem to be a lot of variable and
type name changes and so on, as well as the algorithmic differences,
so a diffstat doesn't give an accurate picture.
> If there is anybody reading this who thinks they understand all the
> concepts there enough to analyse code implementing them, then please
> do put your hand up, we may need your expert attention at some point
> in the future. (and we have other codecs we'd love you to help out
> with too :)
I don't think this is relevant. Doing security support for this does
not need a degree in signal processing. (And my first degree
contained an awful lot of signal processing and I have a background
and advanced degree in computer security, so I should know.)
> > It's been incorporated as a key part of opus, renamed and
> > developed. So celt 0.7.11 is really best seen as an old, pre-release,
> > version of opus.
>
> There is a sense in which you are 100% correct there. But it is also
> the same sense which gave us the aphorism:
>
> "This is Ned Kelly's original axe."
> (only the handle has been replaced 5 times and the head twice)
Having eyeballed some diffs I don't think this is a fair
characterisation at all.
> There's a 'spiritual' connection between these codebases, but so much
> has been rewritten and reinvented so many times now, that backporting
> anything from the new code to the old won't be a case of understanding
> the code. It will likely require reverse engineering the math and
> then completely re-analysing the problem in a very different domain,
> just to see if it still applies, let alone to figure out a fix.
There is no need to backport anything other than security fixes. As I
say, sorting out security fixes does not involve anyone having to
understand FFTs.
And I disagree that the code is so different that the connection is
`spiritual' as you put it. Backporting a hypothetical security fix
from opus to celt 0.7.1 might well not be trivial (although depending
what it touched it might well be) but would also very likely be by no
means impossible.
> I'll leave trying to understand and review the diff itself as an
> exercise for the truly dedicated reader :)
It didn't seem to need that much dedication. Although I haven't read
the whole diff, just eyeballed pieces chosen essentially at random.
> And while that may not look like the most horrifyingly large diff that
> has ever been sent to -release as a minimal 'harmless' proposed fix,
> let's put it into perspective as a proportion of the total codebase:
Currently celt 0.7.1 is in wheezy. Its removal is blocked by the fact
that stripping it out introduces the RC bug in mumble.
The proposed fix involves moving the source code for celt 0.7.1 from
one source package to another, not introducing it newly into wheezy.
Ian.
Reply to: