[gst-devel] [gst-cvs] thomasvs gst-ffmpeg: gst-ffmpeg/ gst-ffmpeg/ext/ffmpeg/

[Edward Hervey]

On 2/14/07, Loïc Minier <lool+sf at via.ecp.fr> wrote:
> On Tue, Feb 13, 2007, Ronald S. Bultje wrote:
> > I don't know what you guys smoke, but don't do this, it's a bad idea
> > [tm].
>
>  I am aware of the consensus against such a practice among the GStreamer
>  developers, but you have to take into account the load in case of
>  security fixes for distributions as well.
>
>  I'm not in favor for such a split in gst-ffmpeg which is very special
>  in the way it intereacts with ffmpeg, but I think it is needed for most
>  software building against ffmpeg such as mplayer, vlc, or xine-lib.
>  gst-ffmpeg is special in that it maps higher level concepts to the
>  "simple" concepts exposed in the ffmpeg API, and hence it really needs
>  an up-to-date mapping between the two, so I think it warrants an
>  exception. (Oh well, you know all this.)

  I'm not sure everybody knows the generic issue you've exposed quite
clearly, and I'm glad outside people realize that.

>
>  Nevertheless, you'll see Debian switch gst-ffmpeg to the system ffmpeg
>  in the next Debian release due to pressure to 1) include support for
>  codecs of the system's ffmpeg in gst-ffmpeg and 2) avoid the code
>  duplication (security team).
>
>  Request of the security team to drop gst-ffmpeg (0.8) due to embedded
>  copies:
>  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410352>
>
>  Request to the technical comittee to rule for a system linking for the
>  etch timeframe:
>  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402793>
>  (Result will likely be: not possible in the etch timeframe, must be
>  implemented for lenny.)
>
>  [ See <http://lists.debian.org/debian-devel/2006/12/threads.html#00138>
>  for background (the thread was about the removal of GStreamer 0.8 but
>  was hijacked by Josselin <http://np237.livejournal.com/11895.html> who
>  wanted h264 and wmv9 support
>  <http://lists.debian.org/debian-devel/2006/12/msg00140.html>). ]
>
>  Sample painful handling of ffmpeg security issues; 6 uploads for the
>  same two vulnerabilities; gst-ffmpeg:
>  http://packages.qa.debian.org/g/gst-ffmpeg/news/20070124T130202Z.html
>  http://packages.qa.debian.org/g/gst-ffmpeg/news/20070121T191710Z.html
>  http://packages.qa.debian.org/g/gst-ffmpeg/news/20070120T140202Z.html
>  gstreamer0.10-ffmpeg:
>  http://packages.qa.debian.org/g/gstreamer0.10-ffmpeg/news/20070124T124703Z.html
>  http://packages.qa.debian.org/g/gstreamer0.10-ffmpeg/news/20070121T190202Z.html
>  ffmpeg:
>  http://packages.qa.debian.org/f/ffmpeg/news/20070129T164704Z.html
>

  I propose a better consensus. Today I'm going to work on bringing
our mirror up to date, which should annihilate all those security
issues. In addition to that, I'm going to fully document the mirror
process and how to easily patch up the ffmpeg mirror in case of
security issues. This would allow maintainers to *easily* patch up
gst-ffmpeg. Of course, filing a bug would the patch would be even
better so we can either patch up our mirror, or update to a more
recent copy.

  What do you think ?

    Edward

>
>  No, it's not funny, yes I would rather prefer shipping a tested
>  gst-ffmpeg, but you can bet it wont be the case in Debian lenny.
>
> --
> Loïc Minier <lool at dooz.org>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>


-- 
Edward Hervey
Multimedia editing developer / Fluendo S.A.
http://www.pitivi.org/