Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
On Tue, Dec 12, 2006 at 08:03:24PM +0100, Josselin Mouette wrote: > I kindly ask the Technical Committee to rule on the gstreamer0.10-ffmpeg > case. > The gstreamer0.10-ffmpeg package includes its own private ffmpeg copy > and is built against it. Upstream's rationale is that ffmpeg's API and > ABI aren't stable and that they need a frozen version. Linking to > another ffmpeg version often requires changes to the code and means the > software cannot be as widely tested as the upstream version. > However, the multiple copies of ffmpeg in the archive have been > responsible for a security nightmare during the sarge stable cycle. The > security team has asked to replace all such private copies by dynamic > linking to the debian ffmpeg packages. For example, this is holding > mplayer out of etch. > As I explained in the following thread: > http://lists.debian.org/debian-devel/2006/12/msg00138.html > linking to this ffmpeg version is not very complicated, and I asked the > maintainers to migrate to it before the etch release. I submitted bug > #402090 which contains a clean patch that I'm also in the process to > make accepted upstream. > However the maintainer does not want any such change before the release, > and it turned out soon that we would not come to an agreement on this > matter. Which is why I'm forwarding this issue to the Technical > Committee. It is my understanding that this is a request to override the decision of the gst-ffmpeg maintainer, under 6.1.4. Given that neither the security team nor the release team has weighed in with a statement that the package is unsupportable in its present state, I don't believe the technical committee should override the maintainer either. Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
On Tue, Dec 12, 2006, Josselin Mouette wrote: > I kindly ask the Technical Committee to rule on the gstreamer0.10-ffmpeg > case. While I would personally value the tech-ctte as a mean to resolve problematic technical issues and in some cases save us of flames, I don't think it was needed for this issue. It's not very clear whether you think I'm objecting to the changes in all cases, or only before etch. I am against such a change before etch in all cases given where we stand in the release cycle. > The gstreamer0.10-ffmpeg package includes its own private ffmpeg copy > and is built against it. Upstream's rationale is that ffmpeg's API and > ABI aren't stable and that they need a frozen version. Linking to > another ffmpeg version often requires changes to the code and means the > software cannot be as widely tested as the upstream version. That's correct. I would add that upstream is maintaining an organized fork which has other features (such as being autotools based), and which offer finer grained control for them to pull anything they need from the ffmpeg internals if need be; this is obvisouly not necessary currently as your patch demonstrates. Another important point is that the list of GStreamer "caps" (codecs) must be in sync with the supported codecs of the underlying ffmpeg. > However, the multiple copies of ffmpeg in the archive have been > responsible for a security nightmare during the sarge stable cycle. (While I was inclined to think that ffmpeg was a security nightmare, I found only one DSA on ffmpeg in the last 4 years.) But it's enough to consider code copies as evil and the fact that gst-ffmpeg is typically used to read remote media files. It's not like I ever questionned that. In fact *I* filed GNOME #363363: It would be nice if gst-ffmpeg would be built against an out-of-tree ffmpeg snapshot. It's currently painful (for you) to update the ffmpeg snapshot in gst-ffmpeg and autotoolize it, and it's painful for distributions to fix both ffmpeg and gst-ffmpeg if a security problem appears. > The > security team has asked to replace all such private copies by dynamic > linking to the debian ffmpeg packages. For example, this is holding > mplayer out of etch. Yes, and at this time I clarified the nature of gst-ffmpeg with the security team, and they considered the fork to be acceptable for etch (see #395252). Back then, I didn't think gst-ffmpeg would build against the libavcodec / avformat APIs as I thought gst-ffmpeg was also linking directly with some object files. Your latest patch shows that it is possible with the current gst-ffmpeg CVS. > However the maintainer does not want any such change before the release That's correct. I also will put some form of upstream acceptance as a pre-requisite for usage in Debian, even after etch, as I don't intend to fork gst-ffmpeg if I lose upstream support. If upstream accepts the change (for Debian), I accept the additional maintenance burden of updating GStreamer caps in gst-ffmpeg as new ffmpeg source packages will be uploaded to the archive and will likely break gst-ffmpeg. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
Le mercredi 13 décembre 2006 à 01:19 +0100, Loïc Minier a écrit : > It's not very clear whether you think I'm objecting to the changes in > all cases, or only before etch. I am against such a change before etch > in all cases given where we stand in the release cycle. Yes, my request is about the etch release. I'm pretty sure we can come to an agreement after the release. Regards, -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?"
Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
Package: tech-ctte Severity: normal Hi, I kindly ask the Technical Committee to rule on the gstreamer0.10-ffmpeg case. The gstreamer0.10-ffmpeg package includes its own private ffmpeg copy and is built against it. Upstream's rationale is that ffmpeg's API and ABI aren't stable and that they need a frozen version. Linking to another ffmpeg version often requires changes to the code and means the software cannot be as widely tested as the upstream version. However, the multiple copies of ffmpeg in the archive have been responsible for a security nightmare during the sarge stable cycle. The security team has asked to replace all such private copies by dynamic linking to the debian ffmpeg packages. For example, this is holding mplayer out of etch. As I explained in the following thread: http://lists.debian.org/debian-devel/2006/12/msg00138.html linking to this ffmpeg version is not very complicated, and I asked the maintainers to migrate to it before the etch release. I submitted bug #402090 which contains a clean patch that I'm also in the process to make accepted upstream. However the maintainer does not want any such change before the release, and it turned out soon that we would not come to an agreement on this matter. Which is why I'm forwarding this issue to the Technical Committee. Regards, -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]