[vlc-devel] Debian/Ubuntu VLC

[Rémi Denis-Courmont]

Le dimanche 18 juillet 2010 21:02:50 Reinhard Tartler, vous avez écrit :
> On Sun, Jul 18, 2010 at 19:41:46 (CEST), Jean-Baptiste Kempf wrote:
> > On Sun, Jul 18, 2010 at 06:14:26PM +0200, Reinhard Tartler wrote :
> >> I think the biggest problem we face here is communication. It is totally
> >> unreasonable to expect everyone to read and follow vlc. Can you please
> >> either be more explicit with your VSAs or perhaps create a more
> >> specialized mailing list for such issues?
> > 
> > http://www.videolan.org/security/ is not enough for you?
> 
> It's not, and I've elaborated why in the paragraph you've killed in
> your reply.

Sure. But as nice as it would be, we simply can't put CVE identifiers in 
commit logs, as they are allocated afterwards. We can and often do point at 
commits in the advisory. In the last occurence though, this was not possible 
since they were not self-contained individual commits.

> >> > But even then, how do you plan to upgrade from 1.0.2 to 1.0.6?
> >> 
> >> I don't understand the question. Of course by preparing an upload and
> >> uploading it!
> > 
> > Waouw, since when has this changed?
> > 'we cannot update because this release change functionnalities' is what
> > we usually had...
> 
> This has not changed, but AFAIUI, there are only very focused and
> documented changes in bugfix branches. Maybe I'm wrong here? If yes,
> then a stable release update needs to cherry-pick the relevant changes.

Generally, it mostly contains bug fixes. But as long as the source and binary 
interfaces remain compatible, and regression are perceived as very unlikely, 
new features can and do go in.

> Nothing really surprising, IMHO.

It's not surprising. What's surprising is that you seem to expect the VideoLAN 
project to do that. Different distros have different policies w.r.t. what can 
go in and when. With no fewer than 20 VLC releases published since Lenny, 
there is no way in hell that the VideoLAN project could maintain security 
patches/branches for every releases. And I don't think any other open-source 
project does that either.

I could understand a statement that you don't buy in the computer security 
theater, and so don't need security updates. But that would be another 
discussion, and that does not seem to be the case.

> >> > Or from 1.1.x in final Maverick, to 1.1.x+{1,2,...} ? VideoLAN won't
> >> > provide one stable tree per release! We can't afford the kernel's
> >> > luxury time-wise.
> >> 
> >> I guess 1.0-bugfix and 1.1-bugfix branches do exist, yes?  What's the
> >> problem?
> > 
> > You don't understand him. He is speaking about 1.1.0-bugfix,
> > 1.1.1-bugfix, etc...
> 
> I think the misunderstanding is about the 1.0-bugfix and 1.1-bugfix
> branches. Can you perhaps explain me the update/commit policy in the
> 1.0-bufix branch? what patches qualify and what don't? Is there a wiki
> page or something I can read about?

In 1.0-bugfix the current policy is that it is DEAD. It just happens that 
there have been no security advisories since 1.0.6, and so 1.0-bugfix happens 
to be up-to-date w.r.t. security matters.

But for 1.1-bugfix, there will be select low-risk new features probably until 
shortly before 1.2.0 is out. And 1.2.0 will probably be out long after 
Maverick. So that does not work in the medium term.

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