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. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20494.55920.837498.721...@chiark.greenend.org.uk