snapshot is from 20110322 and bundles a ffmpeg copy. from ffmpeg.org: July 28, 2011 We have made 2 new point releases that fix several security issues, amongth them MSVR-11-0080. September 7, 2011 We have made 2 new point releases that fix several security issues, amongth them MSVR-11-0088. September 22, 2011 We have made 2 new point releases that fix more security issues. October 2, 2011 We have made 2 new point releases (0.7.6 and 0.8.5) that fix security issues in [long list] November 4, 2011 We have made 2 new point releases (0.7.7 and 0.8.6) that fix around 90 bugs, several of which are security relevant. November 21, 2011 We have made 2 new point releases (0.7.8 and 0.8.7) that fix many bugs, several of which are security relevant. Amongth them NGS00144, NGS00145 and NGS00148. (all the ffmpeg sec. bugs we have should be relevant to this mplayer snapshot). restricting because i've not seen any report about this. feel free to unrestrict.
Thanks, Alexis. I am going to open the bug as I don't believe it is a secret mplayer includes ffmpeg. Please let us know when you're able to add an updated mplayer ebuild that resolves these issues. Tnx.
(In reply to comment #1) > Thanks, Alexis. I am going to open the bug as I don't believe it is a secret > mplayer includes ffmpeg. Please let us know when you're able to add an updated > mplayer ebuild that resolves these issues. Tnx. 1.0_rc4_p20111215 ''fixes'' the issues by using system ffmpeg
(In reply to comment #2) > > 1.0_rc4_p20111215 ''fixes'' the issues by using system ffmpeg Thanks, can we move to stabilize this?
(In reply to comment #3) > (In reply to comment #2) > > > > 1.0_rc4_p20111215 ''fixes'' the issues by using system ffmpeg > > Thanks, can we move to stabilize this? we can but: - it is not even keyworded everywhere - thus it lacks wider testing - this implies we will stabilise ffmpeg 0.9, which i've nothing against but the api changed; i've tried to fix bugs as i saw them but it really needs a tinderbox run for its stable rev. deps.
Ok, thanks. Depending on bug 392269 and bug 394805 for ffmpeg-0.9 and mplayer-1.0_rc4_p20111215 keywording, respectively. Diego, would it be possible to have a tinderbox run on =media-video/ffmpeg-0.9? Tnx!
After talking with Samuli is sounds like a tracker for ffmpeg-0.9 is unavoidable. Opened and depending on 395379.
ffmpeg-0.10 has been stable for a while now and mplayer-1.0_rc4_p20111215 is no longer in the tree. Are we good to stabilize a newer ebuild?
(In reply to comment #7) > ffmpeg-0.10 has been stable for a while now and mplayer-1.0_rc4_p20111215 is > no longer in the tree. Are we good to stabilize a newer ebuild? go with mplayer-1.1-r1 i'd say
(In reply to comment #8) > (In reply to comment #7) > > ffmpeg-0.10 has been stable for a while now and mplayer-1.0_rc4_p20111215 is > > no longer in the tree. Are we good to stabilize a newer ebuild? > > go with mplayer-1.1-r1 i'd say Excellent. Arches, please test and mark stable. Also waiting on ppc/ppc64 to keyword (bug 394805).
amd64 stable
Stable for HPPA.
arm stable
mplayer-1.1-r1 wasn't keyworded for ~ppc ~ppc64. I tested and it is fine on those arches. I've keyworded and since this is a security issue, I will stabilize in a few days.
x86 done.
stable ppc ppc64
alpha/ia64/sparc stable
Thanks, everyone. Added bug to existing GLSA draft.
nothing left to do for media-video@
This issue was resolved and addressed in GLSA 201310-13 at http://security.gentoo.org/glsa/glsa-201310-13.xml by GLSA coordinator Sean Amoss (ackle).