Re: Bug#763148: Prevent migration to jessie
Hi,
On 28.09.2014 14:44, Andreas Barth wrote:
* Andreas Cadhalpun (andreas.cadhalpun@googlemail.com) [140928 14:36]:
On 28.09.2014 12:47, Andreas Barth wrote:
The release policy does say "Packages must be security-supportable". I
would be surprised if a statement from the security team (assuming
that Moritz raised that bug report with his security team-hat on and
not privately) that they would like to have only one of libav and
ffmpeg in jessie would be overruled by the release team.
Nonetheless both are in wheezy and will be in jessie, unless chromium
gets removed from testing.
There is a distinction between an old and a new package.
I don't think that makes a difference from a security point of view.
However (and please note that I'm not a member of the security team
and just speak for myself here as always when not otherwise marked) if
it would be possible to replace the internal code copy in chromium
by a reference to ffmpeg
I have created a patch for that and opened bug #763632 [1].
(but it's not possible with libav),
Chromium can't work with Libav, because, similar to MPlayer, it uses
features of FFmpeg, which are not available in Libav, e.g.
av_buffer_get_opaque.
that will
probably lead to a re-evalutation. (That doesn't necessarily mean
"sucess guranteed", but it looks to me as it will not make things
worse.)
Then please start this re-evaluation now.
Perhaps you always intended that, but at least I didn't understand it
that way yet.
Yes, that was what I intended.
I absolutely cannot understand why the security team would prefer to
have an embedded code copy instead of a properly packaged library.
I don't think they do that.
How do you interpret the last message from Moritz then?
"Chromium using a local copy of the lib doesn't matter" [2]
However, I can understand why one embedded
code copy is better than one embedded code copy plus a library in
addition to it.
This would be understandable, yes.
There are now two options:
a) Let FFmpeg migrate to testing and make chromium use it.
b) Don't let FFmpeg migrate and let chromium continue to use the
embedded copy, in spite of the policy violation.
If this really would be preferred, then the FFmpeg libraries and
tools could be build from the chromium source package, because that
can't increase the security workload, as the source is already in
wheezy.
If you ask me, only one of these options is a sane thing to do.
Best regards,
Andreas
1: https://bugs.debian.org/763632
2: https://bugs.debian.org/763148#34
Reply to: