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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org