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]
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
Hi, as one of the GStreamer maintainers I also wanted to express my oppinion on this issue. First of all I can only second Loic's statement that this is definitely nothing that should be changed at this stage of release before etch. The change is far too intrusive and even if it fixes h264 videos for you, Joss, I bet that there are a bunch of regressions in other parts that need special workarounds in the gstreamer plugin or just a new ffmpeg snapshot. After etch release this can be discussed again though. It's always good to reduce duplication, especially for security considerations. Also sometimes for ease of fixing bugs in only one place instead of 1 different places. These are IMHO the only arguments that are valid for this issue. Contrary to this is, that gst-ffmpeg upstream extensively checks their current ffmpeg snapshot before release, syncs it again from ffmpeg upstream or applies workarounds for random behaviour or API changes in ffmpeg. This guarantees that the gst-ffmpeg releases work at least for great majority of files of types that are supported. If we for example choose a ffmpeg snapshot for gst-ffmpeg just before their last sync it's almost certainly that there are regressions, not only theoretical but seen in the real world. But even if our ffmpeg snapshot is newer than the bundled one with gst-ffmpeg there is a fairly high chance of regressions. Almost every time upstream syncs it's ffmpeg snapshot one can see random bugfixing and working around bugs and adjusting to completely random changes by them. I could imagine that upstream simply rejects bugs with our build with the explanation that one should try to reproduce it with a vanilla build for the above mentioned reasons. So _if_ we change gst-ffmpeg to build and link against Debian's ffmpeg _after etch release_ the following must be given: - The changes required to build with an external ffmpeg are upstream (so Joss, get your patch in a state that is acceptable by them and get it in) - Upstream, even if they don't support this change, will still look at bugreports by us and our users - We can somehow guarantee that our ffmpeg is at least as new as upstream's Bye PS: IMHO even if linking to Debian's ffmpeg saves some work for security updates this discussion definitely has wasted more time than would be necessary for a few security updates of gst-ffmpeg... signature.asc Description: This is a digitally signed message part
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]
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]
