Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => shlomif

Updated to 3.3.3 and submitted to mga6 core/updates_testing . Thanks!

Not quite right, the tainted build has a subrel, which it should not.  Please have the sysadmins remove it and rebuild without the subrel.

CC: (none) => sysadmin-bugs

(In reply to David Walser from comment #3)
> Not quite right, the tainted build has a subrel, which it should not. 
> Please have the sysadmins remove it and rebuild without the subrel.

Well, I got an error on submitting the tainted version without it. I'll try contacting the sys admins.

(In reply to Shlomi Fish from comment #4)
> (In reply to David Walser from comment #3)
> > Not quite right, the tainted build has a subrel, which it should not. 
> > Please have the sysadmins remove it and rebuild without the subrel.
> 
> Well, I got an error on submitting the tainted version without it. I'll try
> contacting the sys admins.

I thought that had been fixed already as I had filed it as a blocker before Mageia 6, because we can't have the build system holding up security updates like that.  That build system bug needs to be fixed ASAP.

(In reply to David Walser from comment #5)
> (In reply to Shlomi Fish from comment #4)
> > Well, I got an error on submitting the tainted version without it. I'll try
> > contacting the sys admins.
> 
> I thought that had been fixed already as I had filed it as a blocker before
> Mageia 6, because we can't have the build system holding up security updates
> like that.  That build system bug needs to be fixed ASAP.

Well it's "fixed". You just need to wait for the ARM builds to complete before pushing on the other branch, as the buildsystem does not allow concurrent builds with same NEVR on different branches. Though it could be made to allow it altogether IMO, I don't see the need for this restriction.

(In reply to Rémi Verschelde from comment #6)
> Well it's "fixed". You just need to wait for the ARM builds to complete
> before pushing on the other branch, as the buildsystem does not allow
> concurrent builds with same NEVR on different branches. Though it could be
> made to allow it altogether IMO, I don't see the need for this restriction.

To be clearer, IIRC the same limitation already happened prior to the ARM port, it was just less painful as builds did not take that long. But in case it was actually possible to push core+tainted at the same time before Mageia 6, then I'm wrong and it's actually a regression that needs to be fixed.

ARM is a secondary arch.  It's not supposed to interfere with the normal workings of supporting our primary architectures.  ARM builds take freaking forever (sometimes days).  We can't have this.

both core and tainted rpms are in the repo

CC: (none) => mageia
Assignee: shlomif => qa-bugs

(In reply to Nicolas Lécureuil from comment #9)
> both core and tainted rpms are in the repo

No Nicolas, the tainted ones are not correct.  They have a subrel and they should not.  They need to be removed and rebuilt without the subrel.

CC: (none) => qa-bugs
Assignee: qa-bugs => shlomif

in progress

Saving advisory for whenever tainted finally builds.

Note that there are core and tainted builds for this package.

Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=8065#c6
https://bugs.mageia.org/show_bug.cgi?id=14042#c6

Advisory:
========================

Updated ffmpeg packages fix security vulnerabilities:

This update provides ffmpeg version 3.3.3, which fixes several security
vulnerabilities and other bugs which were corrected upstream.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9608
https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.3.3
http://ffmpeg.org/download.html
http://ffmpeg.org/security.html

Assignee: qa-bugs => mageia

mga6  x86_64

Installed the core updates and played some video files using mplayer.  Codec packages were pulled in at the same time.

$ rpm -qa | grep ffmpeg
lib64ffmpegthumbnailer4-2.2.0-3.mga6
ffmpeg-3.3.3-1.mga6

Extract from dependency check:
$ urpmq --whatrequires ffmpeg
clipgrab
devede
exmplayer
kdenlive
peek

Checked the very extensive commandline help system and noted that ffmpeg supports just about every codec and format known.

Installed peek and used it to record half a minute of desktop activity as a GIF and played it back via eom (Eye of Mate).

Ran some conversions on several files, including those linked in earlier comments.

$ ffmpeg -i 'MP4_DIVX_AAC-LC-(mkvmerge).mkv' output.avi
This failed, ending with: 
MP4_DIVX_AAC-LC-(mkvmerge).mkv: Invalid data found when processing input
$ ffmpeg -i Fashion_DivX720p_ASP.divx fashion.avi
This worked and played OK in mplayer.
$ ffmpeg -i Toto_Rosanna.mkv Rosanna.flv
Same with this one but in all these cases the video is degraded but the sound is fine.
$ ffmpeg -i Rosanna.flv rosanna.mkv
Conversion back to the original format works.
$ ffmpeg -i LetTheBrightSeraphim_ReneeFleming.flv handel.webm
Sounded perfect.

Replaced ffmpeg by the version from Tainted Updates Testing and carried out similar tests.

The MP4_DIVX_AAC-LC-(mkvmerge).mkv conversion failed as before.
Converted an MP4 video file to FLAC which resulted in a .flac audio file which played OK in mplayer.
$ ffmpeg -i RedRedWine.ogg redredwine.mp3
$ ffmpeg -i BillieHoliday_StrangeFruit.mkv billie.webm
$ ffmpeg -i PadstowMaySong.wav steeleyespan.flac
All OK in mplayer.

This should be good enough for 64-bits.

In the days when BBC get_iplayer worked I used something like the following recipe to combine video and subtitle tracks.  Cannot test this now without an srt file but am adding this note in case anybody wants to try it.  There was another package needed, something like 'rmtf'.
$ ffmpeg -n -i programme.mp4 -f srt -i programme.srt \
	-c:s mov_text -metadata:s:s:0 \
	language=eng -c:v copy -c:a copy new.mp4

CC: (none) => tarazed25

Updated packages in {core,tainted}/updates_testing:
========================
ffmpeg-3.3.3-1.mga6
libavcodec57-3.3.3-1.mga6
libpostproc54-3.3.3-1.mga6
libavformat57-3.3.3-1.mga6
libavutil55-3.3.3-1.mga6
libavresample3-3.3.3-1.mga6
libswscaler4-3.3.3-1.mga6
libavfilter6-3.3.3-1.mga6
libswresample2-3.3.3-1.mga6
libffmpeg-devel-3.3.3-1.mga6
libffmpeg-static-devel-3.3.3-1.mga6

from ffmpeg-3.3.3-1.mga6.src.rpm

CC: qa-bugs => (none)

Installed tainted versions into a 32-bit install on real 64-bit hardware (including nvidia 340 video card).

Watched several mp4 videos with vlc. All played as they should. I would have tried other formats, but mp4 is all I have handy.

I can give this a tentative 32-bit OK, but as I have not tested the core version, and did not do testing of other functions I hesitate to do so.

CC: (none) => andrewsfarm

Advisory taken from from Comment 12, Comment 14. Not too sure about the SRPM core/tainted mix, did it thus:
src:
  6:
   core:
     - ffmpeg-3.3.3-1.mga6
   tainted:
     - ffmpeg-3.3.3-1.mga6.tainted

Validating as we have a core & tainted, 32 & 64 bit covered.

Keywords: (none) => validated_update
Whiteboard: MGA6-64-OK MGA6-32-OK => MGA6-64-OK MGA6-32-OK advisory
CC: (none) => lewyssmith

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0262.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

CVE-2017-11399, CVE-2017-11665, CVE-2017-11719 also fixed with this update:
https://www.debian.org/security/2017/dsa-3957
http://ffmpeg.org/security.html