[vlc-devel] Debian/Ubuntu VLC

[Reinhard Tartler]

On Tue, Jul 13, 2010 at 10:13:22 (EDT), Rémi Denis-Courmont wrote:

> On Tue, 13 Jul 2010 08:40:09 -0400, Reinhard Tartler <siretart at tauware.de>
> wrote:
>> 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?
>
> Generally, git gives you that. In -bugfix branches we normally don't do
> architectural changes or risky cleanups.
> With that in mind, it should be easy to make out bug fixes, from
> administrative updates and new features.
>
> Security-wise: http://www.videolan.org/security/sa1003.html

as indicated in my other mail, still seems rather non-trivial to me.

>>>> 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?
>
> Yes.
>
>> 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.
>
> Safe for a major speed up in CVE numbers assignment, this is unlikely to
> improve.

That's sad to hear.

> Besides, I fear I sense a chick-and-egg problem here. I mean,
> MITRE won't give me numbers just for my smile, will they?

Well, I don't know what went wrong with the CVE numbers in VLC SA 1003,
but AFAIUI they handed out the number reservations fairly quickly. I'm
not sure what the exact process is for getting proper CVE reports but me
it looks like this process somehow got stalled.

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