[vlc-devel] Debian/Ubuntu VLC

[Rémi Denis-Courmont]

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

>>> 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. 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?

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis