[Spice-devel] [PATCH] make celt to be optional

[Ron]

On Tue, Jun 12, 2012 at 06:30:36PM +0200, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jun 12, 2012 at 5:35 PM, Ron <ron at debian.org> wrote:
> > The bitstream has been frozen for just a tad under a year now.
> 
> I don't know how you can claim that: http://www.opus-codec.org/downloads/
> 
> The bit-stream has not changed, except for some corner cases that are
> unlikely to happen in the real world.
> [   ] opus-0.9.9.tar.gz                                  18-Feb-2012
> 16:20  710K

Which part of "The bit-stream has not changed" is unclear?

The qualifier there I believe is a reference to this commit:

 Fixes the code for optional self-delimited packing to make it fit the draft.
 This has no impact on opus_demo, test vectors, or "normal" codec operation.

Since support for that packing mode is declared to be OPTIONAL in the
standard (their caps not mine :), anything which might use it cannot
expect to actually be interoperable with a compliant decoder anyhow.

If "unlikely to happen in the real world" was not an extremely conservative
estimate of the real impact, then strictly preserving the bitstream would
have won hands down at that point in time, without any doubt at all.

> If it is, can you point to an official release note stating it clearly
> "bitstream is frozen" or compatible with any further release?

More official than the codec working group declaring it to be in its
finally frozen form, or the codec specification being submitted to and
approved by the IESG for publication?

Archives of all those things are public if you don't want to take
my word for it.


> > The API is frozen.
> >
> > The working group and IETF last calls are over.
> >
> > The IESG telecon has been held and has approved passing this.
> >
> > The only thing we're effectively waiting on before the RFC is officially
> > published now is for this to pass through -editors.  And they aren't going
> > to edit anything that changes the API or bitstream.
> >
> > Fedora is shipping Opus packages now, as is Debian.
> 
> This is not helping, we have implementations not really frozen.

Who is "we" here?

I *absolutely* would not have pushed a copy of this to Debian for people
to use if there was anything short of an ASTRONOMICALLY SMALL chance of
there still being a bitstream change.  (my caps this time, I'm serious
about that.  It's not going to happen while the upstream developers
draw breath to stab anybody who might try).

Anything which did change it would no longer be Opus, since the IETF now
has change control over it, and the Last Call for changes is over.


> > So if say, a later version of celt was found to have issues, which were
> > fixed in that later version, and which led normally very reliable upstream
> > developers to suggest that at least some earlier versions may be at risk
> > of being crashed remotely ...  then what would you do?
> >
> > Given that nobody is working on celt *at all* anymore, and there are no
> > simple patches being produced for this that you can Just Apply to it, how
> > exactly would you plan to "certainly update it"?  Since the only "certain"
> > update is not bitstream compatible with the celt you currently use.
> 
> We would make a release, just like there has been several 0.5.1 releases:
> http://downloads.us.xiph.org/releases/celt/celt-0.5.1.tar.gz vs
> http://downloads.us.xiph.org/releases/celt/celt-0.5.1.3.tar.gz

At risk of sounding repetitive, Who is "we" here?

That looks like the download site of the people who are no longer maintaining
celt to me, not evidence of people existing who actually are.

0.5.1.3 was May 2009.  Made just 2 weeks after 0.5.1 to fix some initial
obvious screwups.  It hasn't been touched or looked at by anyone since.

> Since no releases happened recently, I assume no security issues are known.

That's an interesting assumption ...

Here's another, that is actually a little more grounded in what the people
who might actually make those releases have actually been focussed on:

No releases happened because *nobody* is looking at celt 0.5.1 at all, let
alone backporting fixes to it for things found in much later releases.
Issues found in later releases were fixed in later releases, and nobody
spent even a minute looking at backporting those things to 0.5.1.

And now that Opus is finalised, nobody is looking at *any version* of celt
at all outside of what is in Opus.


So if you aren't actively doing that, well, I guess that just leaves the
black hats with motivation to do so ...


> As I said, it would be quite critical for the Spice project to rely on a celt
> release with security issues. As long as spice support 0.5.1 (which is likely
> for a long time still) there will be new releases or fix when necessary.

Well, I just told you there is a reasonable suspicion (from the person who
single-handedly has found more bugs in this code than anyone else in the
world, all put together) ...

What is your plan to confirm or deny 0.5.1 is affected by the problems that
he found and fixed in later versions?

The only thing I know for sure is that nobody else is looking at the 0.5.1
code to assess whether things need backporting.


You could just wait for the news of a live exploit actually doing the rounds,
but I personally wouldn't want to trust my own systems to that plan.


> > I'm not suggesting you need to panic and do anything silly.  But the time
> > to start addressing the real future of this _is_ now.
> 
> It will be when there is an official and clear announcement that the opus
> library implementation has frozen bit-stream (or any further release will be
> bit-stream compatible)

If the IETF closure on this isn't official enough for you, then I don't really
know what to say.

I'm not particularly interested in arguing with someone who has already made
up their mind and for whom facts are just annoying details to handwave away.
But if you're actually interested in the facts, I'm happy to help answer any
questions that you or the rest of the spice team might have.

It's your decision what you do with spice.  But saying "Opus isn't ready yet"
is simply not true.  You may have other reasons not to use it, but that isn't
one of them that stands up to genuine scrutiny.

 Cheers,
 Ron