GNOME Bugzilla – Bug 678774
Please do a new gst-ffmpeg-0.10.x release
Last modified: 2012-10-25 14:01:56 UTC
Hi, Since the gst-ffmpeg-0.10.13 release there have been 2 new releases of the (bundled) libav library: 0.8.2 and 0.8.3, see: http://libav.org/ Both of which fix a long list of security issues. Since the advised way to build gst-ffmpeg is with the bundled libav I would expect the gstreamer project to provide updates releases shortly after a new libav release to close any security issues fixed by new libav releases. Setting severity to critical since the current gst-ffmpeg 0.10.x release is vulnerable to a long list of CVE-s because of the old bundled libav: CVE-2012-0947 CVE-2012-0858 CVE-2012-0853 CVE-2012-0852 CVE-2012-0851 CVE-2012-0850 CVE-2011-4031 CVE-2011-3952 CVE-2011-3951 CVE-2011-3947 CVE-2011-3945 CVE-2011-3940 CVE-2011-3937 CVE-2011-3936 CVE-2011-3929 Regards, Hans
Once this has been fixed notifying GNOME's distributor-list@ might make sense too.
We will likely change our advise now that there are proper libav releases, and drop the internal copy. You should feel free to build against any minor dot-release of libav that matches the major release (0.x) gst-ffmpeg ships with.
(In reply to comment #2) > We will likely change our advise now that there are proper libav releases, and > drop the internal copy. > > You should feel free to build against any minor dot-release of libav that > matches the major release (0.x) gst-ffmpeg ships with. We (rpmfusion) are actually moving in the opposite direction, since there can be only 1 system wide ffmpeg, either the original ffmpeg, or libav and for better or worse rpmfusion has chosen for ffmpeg for now. With ffmpeg-0.10.x this was fine as it is fully compatible with libav-0.8, but with ffmpeg-0.11 there is no more compatibility :| And ffmpeg & libav are not parallel installable. So although I'm really happy with you changing your advise, for now it looks like for the rpmfusion packages we will be moving in the other direction :( <sigh, what a mess>
> We (rpmfusion) are actually moving in the opposite direction, since there can > be only 1 system wide ffmpeg, either the original ffmpeg, or libav and for > better or worse rpmfusion has chosen for ffmpeg for now. With ffmpeg-0.10.x > this was fine as it is fully compatible with libav-0.8, but with ffmpeg-0.11 > there is no more compatibility :| And ffmpeg & libav are not parallel > installable. > > So although I'm really happy with you changing your advise, for now it looks > like for the rpmfusion packages we will be moving in the other direction :( > <sigh, what a mess> Argh. Out of curiosity, has anyone tried persuading the libav folks to make their major releases parallel-installable (which indirectly should also make them parallel-installable to ffmpeg), by suffixing their library names with -0.10 or so like glib/gstreamer do?
(In reply to comment #4) > > Argh. Out of curiosity, has anyone tried persuading the libav folks to make > their major releases parallel-installable (which indirectly should also make > them parallel-installable to ffmpeg), by suffixing their library names with > -0.10 or so like glib/gstreamer do? I think some people (not me) have made that argument in the past, but both sides of the fork claim to be the one true version and thus don't want to add a prefix. I've considered opening a bug at both sides for this, but on second thought I would rather stay out of this mess. Note that it seems that libav will do a 0.9 release soon-ish and that will more or less have the same API changes as ffmpeg-0.11, so once gst-ffmpeg moves to libav-0.9 the compatibility with a system ffmpeg libav (rather then a libav libav) will probably get restored...
It does not look like there will be any more 0.10 releases. For 1.0, what we'll do is this: - move to latest libav in each development cycle (1.1.x, 1.3.x etc.) - then update internal snapshot to latest libav bug-fix release within the same series gst-libav 1.0.2 is now at 0.8.4, and gst-libav 1.1.x in git master will move to 0.9 when someone gets around to fixing it up for that. So closing this as OBSOLETE since I think it's sorted in 1.0 (or WONTFIX for 0.10).