gst-plugins-libav-1.10.3 is being stabled for other gstreamer vulnerabilities (just to stay in sync with others and thus work together properly), but bundles ffmpeg-3.2.2, which received security fixes in 3.2.4 release. This bundled copy of ffmpeg is used with USE=libav, to support system-libav choice over system-ffmpeg - it is buggy with libav (upstream welcomes patches to fix that, but no-one has done it), and thus we instead use the bundled ffmpeg with USE=libav (commonly set globally by users of system libav), as we can't depend on system ffmpeg when the user has chosen to use system libav instead as they can't be both installed on the system. The gst-libav-1.10.4 release updates the bundled version to 3.2.4, thus fixing the vulnerabilities if media-plugins/gst-plugins-libav[libav] is used.
Hello arches, please stabilize media-video/gst-plugins-libav-1.10.4 as it bundled ffmpeg code, which is used with USE=libav. This bundled code received update from ffmpeg-3.2.2 to ffmpeg-3.2.4 for security fixes as also done for system ffmpeg in bug 608868. I have light tested it to work fine together with rest of gst 1.10.3 and checked the changes to only include this bundling update and an irrelevant configure change, so this security stabilization doesn't necessitate stabling of the rest of gst1.10.4 - 1.10.3 is sufficient as stabilized in bug 601354.
An automated check of this bug failed - repoman reported dependency errors (57 lines truncated): > dependency.bad media-plugins/gst-plugins-libav/gst-plugins-libav-1.10.4.ebuild: DEPEND: alpha(default/linux/alpha/13.0) ['>=media-video/ffmpeg-3.2.4:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.bad media-plugins/gst-plugins-libav/gst-plugins-libav-1.10.4.ebuild: RDEPEND: alpha(default/linux/alpha/13.0) ['>=media-video/ffmpeg-3.2.4:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]'] > dependency.bad media-plugins/gst-plugins-libav/gst-plugins-libav-1.10.4.ebuild: DEPEND: alpha(default/linux/alpha/13.0) ['>=media-video/ffmpeg-3.2.4:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
apparently stablebot isn't grokking dep bug of dep bug..
An automated check of this bug succeeded - the previous repoman errors are now resolved.
amd64 stable
x86 stable
arm stable
Stable for HPPA PPC64.
ppc stable.
Stable on alpha.
Arches, Thank you for your work. Added to an existing GLSA Request. Can not wait on sparc. Will write and release without stable spare.
This issue was resolved and addressed in GLSA 201705-05 at https://security.gentoo.org/glsa/201705-05 by GLSA coordinator Kristian Fiskerstrand (K_F).
Re-Opening for SPARC and IA64
ia64 got done with the rest on bug 601354 (where I updated the target to keep things in batch for the slow ones)
I've removed all sparc keywords from gst-plugins-libav due to no responses. I've also cleaned up all older versions than 1.10.4 now thanks to that. There's already 1.10.5 getting stabilized as well, but some arches are being slow there, but that's a concern for some other bug. Though we don't have other bugs about gst-plugins-libav bundling vulnerable ffmpeg, that gets used with USE=libav, and I'm pretty sure 1.10.5 doesn't have a new enough one...
