From ${URL} : Description A vulnerability has been discovered in VLC Media Player, which can be exploited by malicious people to compromise a user's system. For more information: SA56642 The vulnerability is confirmed in version 2.1.1. Prior versions may also be affected. Solution: Update to version 2.1.2. Original Advisory: iSECpartners: http://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html @maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
I have a recording bug with newer versions, which is unfortunate as that means I can only bump and do some quick checks and tests but cannot actively do longer tests. Regardless of that, playback is fine (I have bisected and fixed a PA bug). As I haven't heard others report the recording bug (vide and/or audio stuttering) I think it is specific to a specific format or set of CLI parameters I use. So, yes, feel free to go ahead and stabilize. On a side note, ppc64 keyword missing due to bug #489436...
Depending on USE configuration this package pulls in a few non-stable deps. With the flags I just happen to have set I get: media-libs/opus (USE=opus) net-libs/gnutls (USE=gnutls) sys-devel/gettext (this looks like it doesn't depend on USE) How do we want to handle? Stable masking some USE flags might be an option, but we should at least check in with the gettext maintainers.
(In reply to Richard Freeman from comment #2) > Depending on USE configuration this package pulls in a few non-stable deps. > With the flags I just happen to have set I get: > media-libs/opus (USE=opus) > net-libs/gnutls (USE=gnutls) > sys-devel/gettext (this looks like it doesn't depend on USE) > > How do we want to handle? Stable masking some USE flags might be an option, > but we should at least check in with the gettext maintainers. Yes, I think we could proceed with stable masking them in the short run, then file stabilization bugs in the long run. Though we definitely want to get the unconditional dependencies to stabilize, I'll try to set up some stable masks and stabilization request blockers up for that soon. PS: I've since corrected the gettext dependency to appropriately use the virtual in DEPEND (though it is still listed in RDEPEND).
Okay, here is a full summary of where we are at now: KEYWORDS that are negative: -sparc KEYWORDS that were dropped since stable: alpha, ppc64 (covered by bug #489436) KEYWORDS that were never stabilized: arm Dependencies that repoman complains on when attempting to stabilize in general: ['>=net-libs/gnutls-3.0.20:0', '>=media-libs/opus-1.0.3:0', '>=x11-libs/libvdpau-0.6:0', '>=sys-devel/gettext-0.18.3:0'] Dependencies that repoman complains on too when attempting to stabilize on arm: ['>=media-libs/libtiger-0.3.1:0', '>=media-libs/zvbi-0.2.28:0', 'net-misc/freerdp:0=', '>=kde-base/kdelibs-4:4'] Dependencies that repoman complains on too when attempting to stabilize on alpha, ppc or ppc64: ['>=media-libs/chromaprint-0.6:0'] Dependencies that repoman complains on too when attempting to stabilize on alpha: ['>media-libs/opencv-2.0:0', ''media-libs/libpostproc:0'] There also is this Qt 5 thing, not sure if we need to specially address this: dependency.badmasked 4 media-video/vlc/vlc-2.1.9999.ebuild: DEPEND: **(empty profile) ['>=dev-qt/qtgui-5.1.0:5', '>=dev-qt/qtcore-5.1.0:5', 'dev-qt/qtwidgets:5'] media-video/vlc/vlc-2.1.9999.ebuild: RDEPEND: **(empty profile) ['>=dev-qt/qtgui-5.1.0:5', '>=dev-qt/qtcore-5.1.0:5', 'dev-qt/qtwidgets:5'] media-video/vlc/vlc-9999.ebuild: DEPEND: **(empty profile) ['>=dev-qt/qtgui-5.1.0:5', '>=dev-qt/qtcore-5.1.0:5', 'dev-qt/qtwidgets:5'] media-video/vlc/vlc-9999.ebuild: RDEPEND: **(empty profile) ['>=dev-qt/qtgui-5.1.0:5', '>=dev-qt/qtcore-5.1.0:5', 'dev-qt/qtwidgets:5'] We now look at the USE flags: '>=net-libs/gnutls-3.0.20:0' --> USE flag gnutls on all arches '>=media-libs/opus-1.0.3:0' --> USE flag opus on all arches '>=x11-libs/libvdpau-0.6:0' --> USE flag vdpau on all arches '>=sys-devel/gettext-0.18.3:0' --> No USE flag on all arches '>=media-libs/libtiger-0.3.1:0' --> USE flag libtiger on ARM '>=media-libs/zvbi-0.2.28:0' --> USE flag linsys and USE flag zvbi on ARM 'net-misc/freerdp:0=' --> USE flag rdp on ARM and alpha '>=kde-base/kdelibs-4:4' --> USE flag kde on ARM and alpha '>=media-libs/chromaprint-0.6:0' --> USE flag chromaprint on alpha, ppc{,64} '>media-libs/opencv-2.0:0' --> USE flag opencv on alpha, arm, ppc64 'media-libs/libpostproc:0' --> USE flag postproc on alpha For the first four I've found bug #492522 (gnutls, tracks breaking bugs) and filed bug #500868, bug #500870 and bug #500872. For the second four I've filed bug #500874, bug #500876, bug #500878 and bug #500880. For the last three I've filed bug #500882, bug #500886 and #500888. We'll await response on them first, those whom are slow or disagree we can proceed with putting in a package.use.stable.mask; but, I'd like to prevent touching so many files and thus prevent creating more work than is needed here. Will re-evaluate where we are in a week or so, to shape a better view; then another time in a month or so, at which point we should consider package.use.stable.mask together with the arches to move forward on stabilizing where possible and delaying the particular USE flags for later. Out of the USE flags mentioned, I think vdpau is one of the more important ones; so, it would be nice to prioritize our efforts to that one first after gettext is done. If we consider this more severe, we can start the process earlier; but it seems that we're locked by how fast gettext can go, and perhaps vdpau too ('cause losing hardware rendering can be perceived as a regression). We'll see... Thank you in advance to everyone involved.
Moved bugs which will have package.use.stable.mask entries to separate bug #504826; need to wait for a profile EAPI 2 --> 5 move that happens any moment, after that I can commit those entries and add the arches to this bug.
These packages were added to package.use.stable.mask such that security bug #486902, this security bug and security bug #504088 can proceed to stabilize. Alpha needs to proceed with stabilizing bug #500872 first; other arches can proceed here regardless of that bug #500872, here are the stabilization details: Target version: ~media-video/vlc-2.1.2 Target keywords: alpha, amd64, arm, ppc, ppc64, x86 Thank you very much in advance. PS: Raised priority to High because this blocks a Major A2 bug.
(In reply to Tom Wijsman (TomWij) from comment #6) > > PS: Raised priority to High because this blocks a Major A2 bug. Please don't touch Importance field, if you don't know how it work for security bugs.
amd64 stable
x86 stable
ppc stable
ppc64 stable
alpha stable
arm has not stable keyword Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
+ 08 Jun 2014; Tom Wijsman <TomWij@gentoo.org> package.mask: + Mask VLC ebuilds that are affected with security bug CVE-2013-6934. +# Tom Wijsman <TomWij@gentoo.org> (8 Jun 2014) +# Mask VLC ebuilds that are affected with security bug CVE-2013-6934: +# +# A vulnerability has been discovered in VLC Media Player, which can be +# exploited by malicious people to compromise a user's system. +# +# Some ebuilds also have other buffer and integer overflow security bugs like +# CVE-2013-1954, CVE-2013-3245, CVE-2013-4388 and CVE-2013-6283. +# +# Users should consider to upgrade VLC Media Player to at least version 2.1.2. +<media-video/vlc-2.1.2 Masking for a few days for awareness, as well as to see if the upgrade works out well for everyone (due to blockers); if all goes well, I'll then clean them.
Maintainer(s), Thank you for cleanup! Added to an existing GLSA request.
vdpau flag is still masked in /usr/portage/profiles/arch/amd64/package.use.stable.mask # Tom Wijsman <TomWij@gentoo.org (16 Mar 2014) # Mask unstable USE flags on media-video/vlc, see security bug #499806. media-video/vlc gnutls opus vdpau should it be removed now we have newer version available?
This issue was resolved and addressed in GLSA 201411-01 at http://security.gentoo.org/glsa/glsa-201411-01.xml by GLSA coordinator Sean Amoss (ackle).
removed all <2.1.2 ebuilds affected by security bug 499806
This bug is marked as RESOLVED FIXED, and vulnerable <media-video/vlc-2.1.2 ebuilds are removed. But VLC opus USE flag is still hardmasked in package.use.stable.mask Maybe it's time to unmask USE flags for VLC in package.use.stable.mask?
(In reply to ghost99 from comment #19) > This bug is marked as RESOLVED FIXED, and vulnerable <media-video/vlc-2.1.2 > ebuilds are removed. But VLC opus USE flag is still hardmasked in > package.use.stable.mask > > Maybe it's time to unmask USE flags for VLC in package.use.stable.mask? it's a security bug. File separate bug for another issues.
(In reply to ghost99 from comment #19) > This bug is marked as RESOLVED FIXED, and vulnerable <media-video/vlc-2.1.2 > ebuilds are removed. But VLC opus USE flag is still hardmasked in > package.use.stable.mask > > Maybe it's time to unmask USE flags for VLC in package.use.stable.mask? Thanks for pointing out. I've already created bug 530254 for that issue.
