[vlc-devel] Debian/Ubuntu VLC

[Reinhard Tartler]

On Tue, Jul 13, 2010 at 02:49:15 (EDT), Rémi Denis-Courmont wrote:

>    Hello,
>
> On Mon, 12 Jul 2010 22:28:59 +0200, Benjamin Drung <bdrung at ubuntu.com>
> wrote:
>> I doubt that we can pull a new upstream version into a stable Ubuntu
>> release (e.g. vlc 1.1.0 in Ubuntu 10.04), because the new version breaks
>> the ABI of the older version and therefore break applications that uses
>> libvlc.
>
> Not true for 9.10 which ships 1.0.2, while 1.0.6 has no known security
> issues.

So let's check:

| vlc | 0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu3.3 | hardy-updates/universe | source
| vlc | 0.9.9a-2ubuntu1 | jaunty/multiverse | source, amd64, i386
| vlc | 1.0.2-1ubuntu2 | karmic/universe | source, amd64, i386
| vlc | 1.0.2-1ubuntu2.1 | karmic-updates/universe | source, amd64, i386
| vlc | 1.0.6-1ubuntu1 | lucid/universe | source, amd64, i386
| vlc | 1.0.6-1ubuntu1.1 | lucid-updates/universe | source, amd64, i386
| vlc | 1.1.0-2ubuntu1 | maverick/universe | source, amd64, i386

so in hardy we have basically the same situation as in
debian/stable. We could argue that it is unsupportable and try to get it
removed.

As for karmic, I guess we could and probably should work on preparing an
upload to either karmic-updates or karmic-security. But this would
involve following a rather strict process. Rémi, is there a list of bugs
fixed between 1.0.2 - 1.0.6? the SRU team will most likely require some
kind of risk analysis and some proof that it's really worth. I of course
believe you because I know vlc and what incredible work you are doing,
but having something more solid like in CVE references would be really
beneficial here.  Moreover, it seems that there has been at least one
update to vlc in karmic-updates.

>
>> The normal way for stable releases is to cherry-pick security
>> fixes and apply them to the older version. How much manpower do you have
>> to support this model?
>
> English is ambiguous here. *I* definitely won't spend time on 0.8 or 0.9,
> and I very much doubt anyone else will.
>
> As for 1.0, it all depends how hard specific fixes will be, which is
> undecidable until shit happens.
>
>> The process would be:
>
>> 1. Open a bug report in Launchpad stating the security bug
>> 2. Produce a patch that fixes the bug in the latest trunk version
>> 3. Backport the patch against trunk to the older versions of vlc
>> 4. Release the security update
>
> Someone needs to dig the security patches out of 1.0-bugfix from 1.0.2 to
> 1.0.6. That's not really difficult; it's just time consuming. The VideoLAN
> project is already doing that for the latest 1.0.x. We are not going to do
> that for all of the 1.0.x revisions individually. If distribution FOOBAR
> decides to fork the maintenance process, then that's FOOBAR's problem. And
> when FOOBAR does not stand up to its own process, you get pathetic results
> like VLC in Debian Stable.

I tend to agree here. This answers my question from above pretty much.
So if I understand you correctly, there is a 1.0-bugfix branch, from
which we can try to cherry-pick individial changes to existing
releases. I guess it is this repository:

http://git.videolan.org/?p=vlc/vlc-1.0.git;a=summary

correct?

Hm, I see that the amount of work you're doing here is incredible. I
really think we should get this packaged.

> We are already sorting Ubuntu VLC bug reports, made 1.0.6 more or less only
> for Ubuntu LTS, report security issues in your bug tracker. Where does this
> stop? We're _not_ paid.
>
>> Looking at the Ubuntu bugs, there is only one security bug reported:
>> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464

and AFAIUI, it doesn't affect the versions of vlc we're talking right
now. So from a ubuntu bugtracker POV, there are no known security
issues, and as the commit logs don't reference CVE or similar security
trackers either, I guess we need to be somewhat more convincing here.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4