See http://ffmpeg.org/index.html#pr10 Please bump to ffmpeg-0.10.
in cvs
Are we anywhere near being able to stabilize this? Or 0.9? Thanks.
(In reply to comment #2) > Are we anywhere near being able to stabilize this? Or 0.9? Thanks. now that transcode is fixed, go for 0.10
(In reply to comment #3) > > now that transcode is fixed, go for 0.10 Once keywording is complete in bug 392269 are we ready move forward to stabilize 0.10?
(In reply to comment #4) > (In reply to comment #3) > > > > now that transcode is fixed, go for 0.10 > > Once keywording is complete in bug 392269 are we ready move forward to > stabilize 0.10? the same as for 0.9: once someone has checked the reverse deps, yes
CCing arches. We have a completely bloated, security-wide, mplayer, with almost one year of issues accumulated. Stable ffmpeg (and libav btw) is affected by the issues mentionned in this bug. Arches, please check your stable reverse deps, and if something fails, add them as blockers to bug #395379 . Otherwise proceed to ffmpeg-0.10 stabilisation. Note that almost every single video player on *nix uses ffmpeg, and those are usually fed with untrusted files, so I feel a bit ashamed to be that late in providing safe libraries considering the large impact it has.
@sound, jfyi, libaacplus is pulled in and it will be stabilized
(In reply to comment #6) > Arches, please check your stable reverse deps, and if something fails, add them > as blockers to bug #395379 . Otherwise proceed to ffmpeg-0.10 stabilisation. sure, but can you provide a stable list with packages needs testing?
(In reply to comment #7) > @sound, jfyi, libaacplus is pulled in and it will be stabilized fine by me (In reply to comment #8) > (In reply to comment #6) > > Arches, please check your stable reverse deps, and if something fails, add them > > as blockers to bug #395379 . Otherwise proceed to ffmpeg-0.10 stabilisation. > > sure, but can you provide a stable list with packages needs testing? ( http://tinderbox.dev.gentoo.org/misc/rindex/media-video/ffmpeg ∪ http://tinderbox.dev.gentoo.org/misc/rindex/virtual/ffmpeg ) ∩ { stable packages } :=) i remember there's a tool lying around to get stable rev deps but i dont remember more :( we've asked for tinderbox runs, but noone was willing to do it (see bug #389037 and bug #394809 comment 4 ), so here we are...
(In reply to comment #9) > ( http://tinderbox.dev.gentoo.org/misc/rindex/media-video/ffmpeg ∪ > http://tinderbox.dev.gentoo.org/misc/rindex/virtual/ffmpeg ) ∩ { stable > packages } > > :=) > > i remember there's a tool lying around to get stable rev deps but i dont > remember more :( http://phajdan-jr.blogspot.com/2011/10/exhaustive-testing-of-stable-reverse.html
(In reply to comment #6) > Arches, please check your stable reverse deps, and if something fails, add them > as blockers to bug #395379 . Otherwise proceed to ffmpeg-0.10 stabilisation. Done Removing arches until all bugs will be fixed.
(In reply to comment #11) > (In reply to comment #6) > > Arches, please check your stable reverse deps, and if something fails, add them > > as blockers to bug #395379 . Otherwise proceed to ffmpeg-0.10 stabilisation. > > Done thanks a lot ! (In reply to comment #11) > Removing arches until all bugs will be fixed. but please readd arches that are not affected by these bugs and may want to fix these sec. holes...
(In reply to comment #12) > (In reply to comment #11) > > Removing arches until all bugs will be fixed. > > but please readd arches that are not affected by these bugs and may want to > fix these sec. holes... thank you... you have all the stable request filled now, as blocking this bug, so you can proceed
Stable for HPPA.
ppc64 done
x264 is pulled in, what version we should stabilize?
(In reply to comment #16) > x264 is pulled in, what version we should stabilize? media-libs/x264-0.0.20111220 AND media-video/x264-encoder-0.0.20111220
ffmpegsource is pulled in and fails to compile
(In reply to comment #18) > ffmpegsource is pulled in and fails to compile use.masked on all but latest versions
amd64 stable
Other arches will continue in bug 411369
Thanks, everyone. Added to existing GLSA request.
nothing left to do for media-video@
This issue was resolved and addressed in GLSA 201310-12 at http://security.gentoo.org/glsa/glsa-201310-12.xml by GLSA coordinator Sean Amoss (ackle).
CVE-2011-3950 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3950): The dirac_decode_data_unit function in libavcodec/diracdec.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via a crafted value in the reference pictures number. CVE-2011-3949 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3949): The dirac_unpack_idwt_params function in libavcodec/diracdec.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via crafted Dirac data. CVE-2011-3946 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3946): The ff_h264_decode_sei function in libavcodec/h264_sei.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via crafted Supplemental enhancement information (SEI) data, which triggers an infinite loop. CVE-2011-3944 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3944): The smacker_decode_header_tree function in libavcodec/smacker.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via crafted Smacker data. CVE-2011-3941 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3941): The decode_mb function in libavcodec/error_resilience.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via vectors related to an uninitialized block index, which triggers an out-of-bound write. CVE-2011-3935 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3935): The codec_get_buffer function in ffmpeg.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via vectors related to a crafted image size. CVE-2011-3934 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3934): Double free vulnerability in the vp3_update_thread_context function in libavcodec/vp3.c in FFmpeg before 0.10 allows remote attackers to have an unspecified impact via crafted vp3 data.
