A Mennucc wrote:
> The overhead [O] may simply be not worth the (supposed) future benefit
> for security.
It's not theoretical, but a genuine problem that affects us here and
today. We've had the whole mess for CVE-2005-4048, we're currently
encountering it with CVE-2006-4799/CVE-2006-4800 and we'll have it
again other the course of December 2006 until June 2009, the time
Etch will be supported.
> Since the development of FFmpeg is done jointly with the
> development of MPlayer , then a security bug in FFmpeg will be fixed in
> upstream MPlayer before than in any other package using FFmpeg. In case
> [O] , applying the fix would require sorting also thru our patches (and
> we cannot even ask help upstream !). In case [N] , it may be the case
> that the fix is more easier to apply. In case [A] , we have double work
> to do (but I will take care of the fix for MPlayer, I promise :-)
For [O] regular security practices would apply, i.e. keeping interfaces
stable, etc. [A] would not only require to roll out updates twice, but
also the need to backport patches to different versions.
> So I think that
> [O] is not worth the effort: we ruin MPlayer (for sure) for hope of a
> (not sure) benefit in security.
I don't buy the argument of a completely crippled MPlayer. E.g. the
libavcodec in Debian supports the native WMV9 from SoC. And the 25% performance
difference mostly apply to the H264 optimization work by Michael and
Loren over the recent weeks, while for most other codecs the difference will
be negligible.
> (I really want to abide to (4): We will be guided by the needs of our
> users and the free software community. )
It may seem suboptimal from an upstream perspective, but from a distribution
perspective a correct implementation gains more weight.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
