Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 09:15:20PM +0200, Reinhard Tartler wrote:
I don't think it is a practical problem to point than more than one diff
in the announcement and/or changelog. Do you?
For the Debian Security Team is pointer to an upload commit is usually
sufficient. Adding one would be much appreciated.
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.
This then may qualify for an ubuntu stable release update[1], but probably
not for a debian one. We could however try, I've seen that there has
been formed a stable release manager team and opinions may have changed
with that.
[1] https://wiki.ubuntu.com/StableReleaseUpdates
There are some exceptions for well-tested point updates. We do that for
Postgres, e.g.
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.
I see. Well, my point still stands, a clearer identification of
important issues (including but not strictly limited to security issues)
would help packagers to identify patches that qualify for backporting.
This backporting itself does not need to be done by upstream, I think,
this means that I certainly don't expect you to actively maintain
1.x.y-bugfix branches, but I imagine that a little help with VSAs or a
detailed ChangeLog or perhaps some wiki page to list and classify such
patches would be probably little effort for you and help us immensly
with preparing patches for released distro versions.
I've discussed this with Reinhard in person at the currently holding
Debian conference (DebConf); we'lÃl send an end of life announcement
for the ancient VLC version in Lenny.
Cheers,
Moritz
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Fri, Jul 16, 2010 at 10:55:02 (CEST), Rémi Denis-Courmont wrote: On Tue, 13 Jul 2010 10:14:52 -0400, Reinhard Tartler siret...@tauware.de wrote: On Tue, Jul 13, 2010 at 10:01:13 (EDT), Rémi Denis-Courmont wrote: Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable it lists 4 CVEs: CVE-2010-1441 - 1445, all of them only affecting the 0.8 series and without any details. My point was, the Debian Security team already knows about this, since they have put in their tracker. That is all. I take this as you didn't contact the team directly yet. I'm doing this now with this mail. Security team: It seems that you are aware of 4 CVEs, for which even an upstream security announcement has been made. I now wonder why is vlc in stable in such a bad shape, and I wonder if there should be an official DSA EOL announcement about that in order to communicate this issue to our users clearly. [...] So this piece of information is pretty useless for identifying missing changes in 0.8.x. That's not my problem (anymore). We have made about twenty releases, from four different branches since Debian Stable has last updated. The VideoLAN does not have the resources to maintain four branches at a time. But, in fact, that is irrelevant because Debian does _not_ follow our updates anyway. Otherwise they would at least have 0.8.6i. So keeping the 0.8-bugfix branch alive would have been a pure waste of time. TBH, I was totally unaware of the 0.8.6i release and about its changes. I've just taken a look at its gitweb: http://git.videolan.org/?p=vlc/vlc-0.8.git;a=shortlog;h=refs/tags/0.8.6i To me, it indeed seems to be a good idea to upload this either to lenny-security or lenny-proposed. Security team, what do you think about this? I am not aware of any entity (in general) following any of the older branches, 0.8, 0.9 and 1.0. I only know: - entities not updating (at all), and - entities following the very latest version. And indeed, polls for interested parties in maintaining each of the older branches have all been left without answers this far. I'm not aware of neither these changes you're talking about, nor about these polls. What, in your opinion, should the pkg-multimedia team, or if you prefer, Debian as a project, have done to be aware of those changes and the polls? Canonical puts VLC in universe, wash their hands as far support is concerned. But Debian pretends to support VLC except it does not. The bottom line in both distros is the same: For both distros, maintaining vlc is a community effort, and in both cases, we face the similar symptoms. My hypothesis is in both cases that maintaining vlc properly is too hard. What can we do to improve the situation? (I'm not answering in this mail, but I'll do so in a followup.) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
Le dimanche 18 juillet 2010 12:00:47 Reinhard Tartler, vous avez écrit : So this piece of information is pretty useless for identifying missing changes in 0.8.x. That's not my problem (anymore). We have made about twenty releases, from four different branches since Debian Stable has last updated. The VideoLAN does not have the resources to maintain four branches at a time. But, in fact, that is irrelevant because Debian does _not_ follow our updates anyway. Otherwise they would at least have 0.8.6i. So keeping the 0.8-bugfix branch alive would have been a pure waste of time. TBH, I was totally unaware of the 0.8.6i release and about its changes. I've just taken a look at its gitweb: http://git.videolan.org/?p=vlc/vlc-0.8.git;a=shortlog;h=refs/tags/0.8.6i To me, it indeed seems to be a good idea to upload this either to lenny-security or lenny-proposed. It would have been a good idea two years ago. Now is a bit late. I doubt anyone will ever feel so bored that (s)he would go throug the thousands of changes from 0.8.6i to 1.1.0 to extract the security-relevant or whatever applicable fixes. I am not aware of any entity (in general) following any of the older branches, 0.8, 0.9 and 1.0. I only know: - entities not updating (at all), and - entities following the very latest version. And indeed, polls for interested parties in maintaining each of the older branches have all been left without answers this far. I'm not aware of neither these changes you're talking about, nor about these polls. What, in your opinion, should the pkg-multimedia team, or if you prefer, Debian as a project, have done to be aware of those changes and the polls? Don't you already have people reading vlc-devel? Canonical puts VLC in universe, wash their hands as far support is concerned. But Debian pretends to support VLC except it does not. The bottom line in both distros is the same: For both distros, maintaining vlc is a community effort, and in both cases, we face the similar symptoms. My hypothesis is in both cases that maintaining vlc properly is too hard. The VideoLAN project maintains VLC properly as a pure community effort. Contrary to Ubuntu or even indirectly Debian, we have no sponsored staff. Maintaining a fork of VLC, and in fact, the whole Linux ecosystem, has got to be too hard. I doubt a dedicated stable security team can ever support a stable system for years with as many thousands packages as Debian has. If it were up to me, I'd decree the respective package maintainers are responsible for (most of the work of) stable updates. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 13:25:30 (CEST), Rémi Denis-Courmont wrote: Le dimanche 18 juillet 2010 12:00:47 Reinhard Tartler, vous avez écrit : So this piece of information is pretty useless for identifying missing changes in 0.8.x. That's not my problem (anymore). We have made about twenty releases, from four different branches since Debian Stable has last updated. The VideoLAN does not have the resources to maintain four branches at a time. But, in fact, that is irrelevant because Debian does _not_ follow our updates anyway. Otherwise they would at least have 0.8.6i. So keeping the 0.8-bugfix branch alive would have been a pure waste of time. TBH, I was totally unaware of the 0.8.6i release and about its changes. I've just taken a look at its gitweb: http://git.videolan.org/?p=vlc/vlc-0.8.git;a=shortlog;h=refs/tags/0.8.6i To me, it indeed seems to be a good idea to upload this either to lenny-security or lenny-proposed. It would have been a good idea two years ago. Now is a bit late. I doubt anyone will ever feel so bored that (s)he would go throug the thousands of changes from 0.8.6i to 1.1.0 to extract the security-relevant or whatever applicable fixes. I see. Well, it seems to me that the 0.8.6i release is still better than we currently have in stable, even if it is more than 2 years old. But anyways, I take your comment as a vote that vlc in stable should be EOL'ed with a DSA (Debian security announcement). IIRC, something similar has already been done with iceweasel: http://www.debian.org/security/2009/dsa-1753 I am not aware of any entity (in general) following any of the older branches, 0.8, 0.9 and 1.0. I only know: - entities not updating (at all), and - entities following the very latest version. And indeed, polls for interested parties in maintaining each of the older branches have all been left without answers this far. I'm not aware of neither these changes you're talking about, nor about these polls. What, in your opinion, should the pkg-multimedia team, or if you prefer, Debian as a project, have done to be aware of those changes and the polls? Don't you already have people reading vlc-devel? vlc-devel is a really high volume mailing list, I don't really read it. xtophe might, but he is also upstream himself. Short: obviously not. Is staying up-to-date with vlc-devel a requisite for maintaining vlc properly? Xtophe, maybe you can in future forward such mails to our team mailinglist? Canonical puts VLC in universe, wash their hands as far support is concerned. But Debian pretends to support VLC except it does not. The bottom line in both distros is the same: For both distros, maintaining vlc is a community effort, and in both cases, we face the similar symptoms. My hypothesis is in both cases that maintaining vlc properly is too hard. The VideoLAN project maintains VLC properly as a pure community effort. Contrary to Ubuntu or even indirectly Debian, we have no sponsored staff. irrelevant for this discussion; if this is an attempt to ask for resources from canonical, you're asking in the totally wrong place. Maintaining a fork of VLC, and in fact, the whole Linux ecosystem, has got to be too hard. ubuntu strictly follows Debian packaging, and in fact, only Benjamin and I actually touch the vlc package in ubuntu. We both also work in pkg-multimedia. In this common package, I wouldn't consider it to be a fork in the strict sense. However we cannot easily follow updates in stable release of both distros because of incompatible release update policies in vlc and the distros. But anyway, this argument really doesn't help here. I doubt a dedicated stable security team can ever support a stable system for years with as many thousands packages as Debian has. If it were up to me, I'd decree the respective package maintainers are responsible for (most of the work of) stable updates. Well, AFAIUI, many maintainers directly prepare security updates themselves. For vlc, this has failed in the past. And I'm asking you *again*: What can we do so that the situation improves? Are you evading my question? We know that we suck in this regard, emphasizing this part from your side is probably not going to improve the situation. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
Hello,
Le dimanche 18 juillet 2010 17:56:16 Reinhard Tartler, vous avez écrit :
vlc-devel is a really high volume mailing list,
It's not so bad since commit logs were secluded to a list of their own.
Besides, we tend to tag relevant topics with '[PACKAGERS]'. At least the
OpenSUSE maintainer is there (I think).
I don't really read it. xtophe might, but he is also upstream himself.
I do think he does, and that is what I implied.
I don't know if Samuel still does (guess not).
And I'm asking you *again*: What can we do so that the situation
improves? Are you evading my question? We know that we suck in this
regard, emphasizing this part from your side is probably not going to
improve the situation.
I DON'T KNOW? It's not up to me how Debian, Ubuntu and pkg-multimedia work.
As already stated, nobody answered when older releases support was questioned.
The 1.0-bugfix branch could be reopened for security fixes as there has not
been any known vulnerability since 1.0.6 and 1.1.0 were released. It is
probably too late for stability non-security fixes though, as we've let slip
far too many of them.
But even then, how do you plan to upgrade from 1.0.2 to 1.0.6? 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.
As for 0.8.6-bugfix and 0.9-bugfix, I think it's game over for good. Hence,
Lenny, Hardy and Jaunty should probably drop VLC altogether.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 17:23:48 (CEST), Rémi Denis-Courmont wrote:
And I'm asking you *again*: What can we do so that the situation
improves? Are you evading my question? We know that we suck in this
regard, emphasizing this part from your side is probably not going to
improve the situation.
I DON'T KNOW? It's not up to me how Debian, Ubuntu and pkg-multimedia work.
As already stated, nobody answered when older releases support was
questioned.
The 1.0-bugfix branch could be reopened for security fixes as there has not
been any known vulnerability since 1.0.6 and 1.1.0 were released. It is
probably too late for stability non-security fixes though, as we've let slip
far too many of them.
Well, maybe this is too obvious, but it would really help if videolan's
security announcements would be a) more focused and b) much clearer in
future. If it was clear what patches are related to what VSA,
backporting them to earlier releases would be much easier to
everyone. The last 3 VLAs all basically said there is a problem,
please update without any proper classification of the severity nor
what the actual change was to fix the issue. They just point to use the
latest release but looking at the respective bugfix branch, I see many
janitor commits interleaved with potentially related commits.
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?
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!
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?
As for 0.8.6-bugfix and 0.9-bugfix, I think it's game over for good. Hence,
Lenny, Hardy and Jaunty should probably drop VLC altogether.
Noted, thanks, let's see what the Debian security team thinks about this.
The packages themselves are still useable, so removing it might be a bit
too aggressive. Doing a proper EOL via security announcement channels
seems more appropriate to me, or do I miss something?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
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?
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...
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...
Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
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.
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.
Nothing really surprising, IMHO.
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?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 08:02:50PM +0200, Reinhard Tartler wrote : It's not, and I've elaborated why in the paragraph you've killed in your reply. What do you need? sha1s of the commits? 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. Nothing really surprising, IMHO. This has never been the case. See below, 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? There is no defined policy. ABI and API should be compatible. But, various fixes, or small improvements should go there. But also new features can enter there, as 1.1.1 can show... Those branches aren't 'small fixes' and 'security' only. Best Regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 20:09:33 (CEST), Jean-Baptiste Kempf wrote: On Sun, Jul 18, 2010 at 08:02:50PM +0200, Reinhard Tartler wrote : It's not, and I've elaborated why in the paragraph you've killed in your reply. What do you need? sha1s of the commits? That sounds great. Even better if in form of links to gitweb, so that one can directly inspect the diff. 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. Nothing really surprising, IMHO. This has never been the case. See below, 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? There is no defined policy. ABI and API should be compatible. But, various fixes, or small improvements should go there. But also new features can enter there, as 1.1.1 can show... Those branches aren't 'small fixes' and 'security' only. Hm, so they probably don't meet the stable release update policy of neither debian nor ubuntu. That makes things of course more difficult. So what basically would indeed help was if you as upstream could help us identify to security or otherwise important changes (patches). Ideally in form of a VSA or at least in a ChangeLog file or something. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
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
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Sun, Jul 18, 2010 at 20:37:59 (CEST), Rémi Denis-Courmont wrote:
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.
I don't think it is a practical problem to point than more than one diff
in the announcement and/or changelog. Do you?
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.
This then may qualify for an ubuntu stable release update[1], but probably
not for a debian one. We could however try, I've seen that there has
been formed a stable release manager team and opinions may have changed
with that.
[1] https://wiki.ubuntu.com/StableReleaseUpdates
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 see, it seems that I was wrong here.
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.
Let me make the statement that I'm interested in improving the situation
for the vlc package in stable distro releases.
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.
I see. Well, my point still stands, a clearer identification of
important issues (including but not strictly limited to security issues)
would help packagers to identify patches that qualify for backporting.
This backporting itself does not need to be done by upstream, I think,
this means that I certainly don't expect you to actively maintain
1.x.y-bugfix branches, but I imagine that a little help with VSAs or a
detailed ChangeLog or perhaps some wiki page to list and classify such
patches would be probably little effort for you and help us immensly
with preparing patches for released distro versions.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, 13 Jul 2010 10:14:52 -0400, Reinhard Tartler siret...@tauware.de wrote: On Tue, Jul 13, 2010 at 10:01:13 (EDT), Rémi Denis-Courmont wrote: Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable it lists 4 CVEs: CVE-2010-1441 - 1445, all of them only affecting the 0.8 series and without any details. My point was, the Debian Security team already knows about this, since they have put in their tracker. That is all. So this piece of information is pretty useless for identifying missing changes in 0.8.x. That's not my problem (anymore). We have made about twenty releases, from four different branches since Debian Stable has last updated. The VideoLAN does not have the resources to maintain four branches at a time. But, in fact, that is irrelevant because Debian does _not_ follow our updates anyway. Otherwise they would at least have 0.8.6i. So keeping the 0.8-bugfix branch alive would have been a pure waste of time. I am not aware of any entity (in general) following any of the older branches, 0.8, 0.9 and 1.0. I only know: - entities not updating (at all), and - entities following the very latest version. And indeed, polls for interested parties in maintaining each of the older branches have all been left without answers this far. Canonical puts VLC in universe, wash their hands as far support is concerned. But Debian pretends to support VLC except it does not. (...) It's more like nobody cares. I dont't think that's accurate. I'd rather guess that there is no one in the distro camp that knows how to match these 5 issues to patches that fix them. Maybe people care but don't have time. But they why pretend that VLC is supported (in Debian stable)? -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
Hello, On Mon, 12 Jul 2010 22:28:59 +0200, Benjamin Drung bdr...@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. 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. 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 -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
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 bdr...@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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
[sorry for the resent, it seems the CC line was wrong in the previous mail] On Mon, Jul 12, 2010 at 14:54:53 (EDT), Rémi Denis-Courmont wrote: Hello, I think it is fair to say that there is increasing frustration from users and developers w.r.t. the state of VLC in Debian Ubuntu. I am left wondering what is the best way forward... Thanks for bringing this up. This has also bugged me for quite some time. 1) Debian stable Some time ago, one of the Debian Security (testing or stable, I honestly don't remember) complained that the VideoLAN project security update process was less than optimal. Guess what? It's been almost 3 months since we released VLC 1.0.6, and still Debian Stable ships the same security holes. If we are doing less than optimal, Debian Stable is doing outright PATHETIC. Well, small focused bugfixes would be ok for a security upload, and I guess even for a point release, but something like updating from 0.8.6 to the 1.1 series would cause an unacceptable risk for regressions. What we could do however is to ask the release team what they prefer: either (of possible, lenny's ffmpeg is pretty dated) updating vlc in stable to 1.0 or 1.1, or have it removed from stable. I guess the release team has done that in a couple of cases so far. 2) Ubuntu current version Sooner or later, someone will find a security hole in VLC 1.0.6. If not for security, there are known critical bugs already. For a start, the Mozilla plugin just crashes. Always. If I understand right, Reinhard considered making a PPA, whereas Benjamin suggested VideoLAN make a PPA. Either way, I am concerned that this will cause a flood of untraceable Apport crash reports. How are we supposed to fix that? Is there some 1.0 release branch that has these security fixes in? In that case, we could (and should!) prepare uploads to the security pockets ASAP! 3) Ubuntu LTS At this point in the spacetime continuum, LTS is the current version. But what should be done in a few months when it's not the case anymore? Apply focused bug and security patches on a best efford basis. 4) Ubuntu older versions Ubuntu happily ships VLC with known security holes. WTH? I think the answer is the same here: If there was some focused release branch, there is no problem in uploading to the either -security or -proposed. If not, we can always provide some PPA and point people at it. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Mon, 12 Jul 2010 23:22:11 +0100, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote: 2010/7/12 Rémi Denis-Courmont r...@remlab.net: Hello, I think it is fair to say that there is increasing frustration from users and developers w.r.t. the state of VLC in Debian Ubuntu. I am left wondering what is the best way forward... 1) Debian stable Some time ago, one of the Debian Security (testing or stable, I honestly don't remember) complained that the VideoLAN project security update process was less than optimal. Guess what? It's been almost 3 months since we released VLC 1.0.6, and still Debian Stable ships the same security holes. If we are doing less than optimal, Debian Stable is doing outright PATHETIC. Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable It's more like nobody cares. Depending on severity it can either go to -security pocket or later as an update. To effectivly track the issue either a CVE number or DSA report should be filled. 2) Ubuntu current version Sooner or later, someone will find a security hole in VLC 1.0.6. If not for security, there are known critical bugs already. For a start, the Mozilla plugin just crashes. Always. Similar workflow. File a bug in launchpad against vlc package, mark it as security issue provide as much detail as you can. Ubuntu/Canonical security teams will review it and push to -security or -proposed updates - -updates. That solution straight from the text book does simply not work. I don't buy the Debian/Ubuntu PR, at least not anymore. 4) Ubuntu older versions Ubuntu happily ships VLC with known security holes. WTH? In the same security bug add affects multiple ubuntu series. You can see the currently supported releases here https://wiki.ubuntu.com/Releases and you should target the security bug against all currently supported releases on the desktop. All of these still qualify for security updates. Some of those bugs have been open just for many months. Nobody cares. Look at this old example: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/295464 -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, 13 Jul 2010 08:40:09 -0400, Reinhard Tartler siret...@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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
% apt-cache rdepends libvlc2 libvlc2 Reverse Depends: vlc-nox mozilla-plugin-vlc libvlc-dev % apt-cache showsrc vlc-nox libvlc-dev mozilla-plugin-vlc| \ grep Package: | uniq Package: vlc So the ABI issue is a non-issue, since nobody uses libvlc outside of vlc itself. It's no longer true if we consider experimental which has phonon-backend-vlc But upstream is very strict on not breacking ABI between minor release -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
On Tue, Jul 13, 2010 at 10:01:13 (EDT), Rémi Denis-Courmont wrote: Ping maintainers and debian security team. Indicate the security issue, the patch and or new tarball. It's not like it's not known: http://security-tracker.debian.org/tracker/status/release/stable it lists 4 CVEs: CVE-2010-1441 - 1445, all of them only affecting the 0.8 series and without any details. So this piece of information is pretty useless for identifying missing changes in 0.8.x. A tad more insightful is http://www.videolan.org/security/sa1003.html, which at least mentions: - Heap buffer overflow vulnerability in A/52, DTS and MPEG Audio decoders - Invalid memory access in AVI, ASF, Matroska (MKV) demuxers - Invalid memory access in XSPF playlist parser - Invalid memory access in ZIP archive decompressor - Heap buffer overflow in RTMP access I guess each of them match to the respective CVE number. BTW, this is only half the story you mentioned in the beginning of this thread. It's more like nobody cares. I dont't think that's accurate. I'd rather guess that there is no one in the distro camp that knows how to match these 5 issues to patches that fix them. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [vlc-devel] Debian/Ubuntu VLC
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 siret...@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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
