Summary: | <media-video/ffmpeg-0.7_rc1: Multiple vulnerabilities | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Tim Sammut (RETIRED) <underling> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexanderyt, hwoarang, nikoli, phajdan.jr, tomka |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://ffmpeg.org/releases/ffmpeg-0.6.3.changelog | ||
Whiteboard: | B2 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 367437, 367501 | ||
Bug Blocks: |
Description
Tim Sammut (RETIRED)
2011-04-29 03:57:17 UTC
0.7_rc1 has that fix and you should also check libav (In reply to comment #1) > 0.7_rc1 has that fix and you should also check libav Is there a fixed version of ffmpeg that is a suitable target for stabilization? @video, can anyone comment on libav impact? Thanks! (In reply to comment #2) > (In reply to comment #1) > > 0.7_rc1 has that fix and you should also check libav > > Is there a fixed version of ffmpeg that is a suitable target for stabilization? Since this version uses the old api/abi, this is a good target for stabilisation (after a tinderbox run) imho I will run the tinderbox check on behalf of QA. Is 0.7_rc1 the correct ffmpeg target? I am done with testing. I found 2 packages which fail to work against this version of ffmpeg (In reply to comment #5) > I am done with testing. I found 2 packages which fail to work against this > version of ffmpeg Thanks for doing this, Markos. B2-rated vulnerabilities are expected to be fixed within 10 days. We can't wait a month if one package fails to build (and another B2-rated vulnerability is blocked on this, bug #370481). Can we proceed with the stabilization? Blockers should be fixed, let's do the stabilization. Arches, here's your list: =media-video/ffmpeg-0.7_rc1 =virtual/ffmpeg-0.6.90 =media-libs/FusionSound-1.1.1-r1 They should all be stabilized together and the last one is needed to fix a compatibility issue in current stable version (it wouldn't compile with new ffmpeg). (In reply to comment #8) > Blockers should be fixed, let's do the stabilization. Arches, here's your list: > > =media-video/ffmpeg-0.7_rc1 > =virtual/ffmpeg-0.6.90 > =media-libs/FusionSound-1.1.1-r1 > > They should all be stabilized together and the last one is needed to fix a > compatibility issue in current stable version (it wouldn't compile with new > ffmpeg). What about USE="encode aac" which requires media-libs/vo-aacenc ? Is this safe? amd64:
This will be interesting.
Now by rights ought try all use flags. For now, test phase fails. I have added the already filed bug for test failure which already has a build log. If you want mine, just say "the word". For now, use=test fails,
A couple of use flags require
=media-libs/vo-amrwbenc-0.1.0 ~amd64
>=media-libs/libvpx-0.9.6 ~amd64
Tested FusionSound-1.1.1 with use=ffmpeg, failed. The build log looks just like the one in fixed 367437, not filing again. (In reply to comment #10) > Now by rights ought try all use flags. For now, test phase fails. I have added > the already filed bug for test failure which already has a build log. If you > want mine, just say "the word". For now, use=test fails, Please always figure out if the failures are regressions over the current stable. If not, then it's not a blocker, especially with security related stables. > =media-libs/vo-amrwbenc-0.1.0 ~amd64 > >=media-libs/libvpx-0.9.6 ~amd64 Good, thanks for catching these too. The list for now would be =media-video/ffmpeg-0.7_rc1 =virtual/ffmpeg-0.6.90 =media-libs/FusionSound-1.1.1-r1 =media-libs/vo-aacenc-0.1.1 =media-libs/vo-amrwbenc-0.1.0 =media-libs/libvpx-0.9.6 Any comments? Stable for HPPA. (In reply to comment #12) > =media-video/ffmpeg-0.7_rc1 > =virtual/ffmpeg-0.6.90 > =media-libs/FusionSound-1.1.1-r1 > =media-libs/vo-aacenc-0.1.1 > =media-libs/vo-amrwbenc-0.1.0 > =media-libs/libvpx-0.9.6 As per Thomas list, ok on amd64. Stable on alpha. =media-libs/vo-amrwbenc-0.1.0 isn't keyworded on x86, but =media-libs/vo-amrwbenc-0.1.1 looks pretty good! ;-) The only thing i encountered besides amrwbenc is that media-libs/libvpx's USE=sse2 should depend on USE=mmx, as it failes otherwise: variance_sse2.c:(.text+0xe4f): undefined reference to `vp8_vp7_bilinear_filters_mmx' variance_sse2.c:(.text+0xe7d): undefined reference to `vp8_filter_block2d_bil4x4_var_mmx' vp8/encoder/x86/variance_sse2.c.o: In function `vp8_variance4x4_wmt': variance_sse2.c:(.text+0xf8c): undefined reference to `vp8_get4x4var_mmx' vp8/common/x86/subpixel_sse2.asm.o: In function `no symbol': vp8/common/x86/subpixel_sse2.asm:(.text+0x76f): undefined reference to `vp8_bilinear_filters_mmx' /usr/lib/gcc/i686-pc-linux-gnu/4.4.5/../../../../i686-pc-linux-gnu/bin/ld: vp8/common/x86/subpixel_sse2.asm.o: relocation R_386_GOTOFF against undefined symbol `vp8_bilinear_filters_mmx' can not be used when making a shared object /usr/lib/gcc/i686-pc-linux-gnu/4.4.5/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[1]: *** [libvpx.so.0.9.6] Error 1 make: *** [.DEFAULT] Error 2 emake failed (In reply to comment #16) > =media-libs/vo-amrwbenc-0.1.0 isn't keyworded on x86, but > =media-libs/vo-amrwbenc-0.1.1 looks pretty good! ;-) > > The only thing i encountered besides amrwbenc is that media-libs/libvpx's > USE=sse2 should depend on USE=mmx, as it failes otherwise: is eapi4 allowed in stable now ? (In reply to comment #17) > is eapi4 allowed in stable now ? Yes, an EAPI-4 capable portage has been stabilized few months ago in bug #358009 (In reply to comment #18) > (In reply to comment #17) > > is eapi4 allowed in stable now ? > > Yes, an EAPI-4 capable portage has been stabilized few months ago in bug > #358009 thanks; then it should be fixed now Thomas; (In reply to comment #9) > Please always figure out if the failures are regressions over the current > stable. If not, then it's not a blocker, especially with security related > stables. > > > =media-libs/vo-amrwbenc-0.1.0 ~amd64 > > >=media-libs/libvpx-0.9.6 ~amd64 > > Any comments? Thomas, As I said, "The build log looks just like the one in fixed 367437:, that;s the one filed by Markos. Rather than a regression, it looks as if the bug supposedly fixed (367437) is still flawed. x86 stable: =media-libs/libvpx-0.9.6 =media-libs/vo-aacenc-0.1.1 =media-libs/vo-amrwbenc-0.1.1 =x11-libs/xvba-video-0.7.8 =x11-libs/libva-0.32.0_p2 =media-video/ffmpeg-0.7_rc1 =virtual/ffmpeg-0.6.90 =media-libs/FusionSound-1.1.1-r1 ok ppc should be good now amd64 stable ppc64 done. Masked some USE flags so I didn't have to direct to stable anything. arm stable ia64/sparc stable Thanks, everyone. GLSA request filed. 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). |