CVE-2014-1684 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-1684): The ASF_ReadObject_file_properties function in modules/demux/asf/libasf.c in the ASF Demuxer in VideoLAN VLC Media Player before 2.1.3 allows remote attackers to cause a denial of service (divide-by-zero error and crash) via a zero minimum and maximum data packet size in an ASF file. Maintainers, please advise which version we can begin stabilization on: 2.1.4 or 2.1.5
=media-video/vlc-2.1.5 should be stabilized, as no new bug since 2.1.4 is known for that version. This bug should depend on these two: Bug 530254 : keyword request for vlc-2.1.5 on alpha architecture. It would also be nice if arch testers unmask some hard-masked use flags mentioned in this bug. Bug 489436 : this one still blocks keywording vlc-2.1.5 on ppc64 and amd64-fbsd architectures. Alternatively it is possible to hardmask 'rdp' USE flag on ppc64 and 'chromaprint' USE flag on amd64-fbsd and keyword stripped version of vlc-2.1.5.
Arch teams, could you please stabilize vlc-2.1.5-r1? If possible, you can also remove hard masks for your architecture mentioned in Bug 530254. VLC 2.1.5 is still not keyworded on alpha,ppc64 and amd64-fbsd, so it is not possible to switch from 2.1.2 on these architectures. I was trying to contact with them few times, but only alpha team responds from time to time. We will have to drop support for these archs if nothing changes.
*** Bug 541674 has been marked as a duplicate of this bug. ***
Arches, please test and mark stable: =media-video/vlc-2.1.5-r1 Target keywords : "alpha amd64 ppc ppc64 x86"
amd64 stable
x86 stable
ppc stable
ppc64 stable
I'm unable to go ahead for alpha because of bug 480718
(In reply to Agostino Sarubbo from comment #9) > I'm unable to go ahead for alpha because of bug 480718 What about "autogen-5.18.1" which is building correctly on aplha according to SpanKY?
(In reply to Paweł Stankowski from comment #10) > What about "autogen-5.18.1" which is building correctly on aplha according > to SpanKY? I reopened the bug.
would purging vlc-2.1.2.ebuild cure this? It is the only version of vlc keyworded alpha
alpha will pass for now..feel free to cleanup.
from Comment 2; VLC 2.1.5 is still not keyworded on alpha,ppc64 and amd64-fbsd, From bug 530254, still awaiting alpha The new proxy maintainer has also attempted contact with alpha team and is still waiting. (In reply to Agostino Sarubbo from comment #13) > alpha will pass for now..feel free to cleanup. I have NO idea what this means. 2.1.2 | + o o o o o o o o o o o o o | o 0/5-7 | gentoo 2.1.5-r1 | o + ~ o o o o o + + o o - + | o | gentoo 2.1.9999 | o o o o o o o o o o o o o o | o | gentoo ------------+-----------------------------+---------+------- 2.2.0 | o ~ ~ o o o o o o o o o - ~ | # 0/5-8 | gentoo 2.2.1 | o ~ ~ o o o o o o ~ o o - ~ | o | gentoo From here we are all wondering how and why vlc was ever keyworded alpha. I attempted purging of 2.1.2 in initial stages of managing vlc only to have the legacy of the mask of the use flag pertaining to 2.1.2 rule everything in the present day. I cannot cleanup anything. 2.1.2 is the only version keyworded alpha and 2.1.5-r1 is the only stabled. So, cleanup what?? The 2.2.1 is planned for stable request but its dependencies are not yet ready.
(In reply to Ian Delaney from comment #14) > VLC 2.1.5 is still not keyworded on alpha,ppc64 and amd64-fbsd, vlc-2.1.5-r1 is stable on PPC64. I don't see where you retrieve this info. > From bug 530254, still awaiting alpha Bug 530254 as absolutely nothing to do with this SECURITY bug. > I have NO idea what this means. This means you can cleanup the older vlc and alpha will lose the stable keyword. Vlc on alpha will be ~
(In reply to Agostino Sarubbo from comment #15) > (In reply to Ian Delaney from comment #14) > > VLC 2.1.5 is still not keyworded on alpha,ppc64 and amd64-fbsd, > > vlc-2.1.5-r1 is stable on PPC64. I don't see where you retrieve this info. > ok. I copy pasted too much. delete ",ppc64 and amd64-fbsd,", leaving alpha. This was intended to illustrate alpha is outstanding, forget the others. > > From bug 530254, still awaiting alpha > > Bug 530254 as absolutely nothing to do with this SECURITY bug. > This security bug would normally proceed to stabilising a version that cures to deficit contained in the security bug. So the security bug serves to 'house' a stable request status, then proceed to cleanup. vlc is still awaiting action from the alpha team to either purge the masking of the use flag or to re-keyword alpha. And you say Bug 530254 as absolutely nothing to do it!? Your comment is valid viewing ONLY the security aspect, but in reality, this bug cannot move until Bug 530254 is addressed, though there is an out. I could put forward the request to make 2.2.1 stable without ~alpha, but in light of the impact, I elect not to. Note Comment 3 of that bug. It was re-opened by a member of the security team. > > I have NO idea what this means. > > This means you can cleanup the older vlc and alpha will lose the stable > keyword. > Vlc on alpha will be ~ vlc will be ~ on alpha when and not before it is re-keyworded. current status is KEYWORDS="~amd64 ~arm ~ppc64 -sparc ~x86 ~x86-fbsd"\
GLSA Vote: No Thank you all. Closing as noglsa.
The other VLC bug required a GLSA, so adding this one to it as well. Re-Opening
There are no longer vulnerable versions of VLC in Portage; I recommend closing this bug.
This issue was resolved and addressed in GLSA 201603-08 at https://security.gentoo.org/glsa/201603-08 by GLSA coordinator Kristian Fiskerstrand (K_F).
