On Sat, 2016-12-10 at 06:16 +0100, Laurent Bigonville wrote: > > > In ubuntu they are splitting more the package (same for the > gnome-video-effects package actually) and are also moving at build time > some of the plugins to gstreamer1.0-plugins-good. Following what ubuntu > is doing might be an idea but it will require more work from the > gstreamer maintainer I guess (I'm adding them in the loop) and we might > be a bit late in the development cycle to do that now.
Following what Ubuntu does is definitely not a good idea. We shouldn't just randomly move code from one source package to another. Splitting everything more is a possible solution, the question then however is how much splitting should happen. Should each plugin get its own binary package? How would you decide what to group otherwise? It's not that simple I would split per plugin, if it wasn't that much work and wouldn't also cause a lot of work for ftp-master to always move things out of the NEW queue again, and increase the size of what "apt-get update" has to download, and increase the workload for each maintainer (which of these 150 plugins do I need? 2 hours later: ah! those 80 packages). Doing so would also be useful from a dependency chain point of view, gstreamer1.0-plugins-bad has lots of external dependencies. For the other things you mentioned, there's some upstream effort to get things moved from gst-plugins-bad to gst-plugins-good/base, like camerabin and also some of the effects that cheese probably uses. Nonetheless, none of this is going to solve this specific problem. 1) If packages are split, the first time the user finds a specially crafted file of some obscure format, totem would ask the user to install the required package. What do you think are the chances that the user clicks on "ok" to install that package? Note that this semi-automatic codec installation is only for that, codecs / container formats. Not for any other kind of plugin that provides a feature your package might require. 2) Next time there's a security bug, are we also going to split e.g. imagemagick (also used by tracker) to one package per image format it supports (good luck, it has no plugin system AFAICS). Or openssl whenever some of its features has a bug? Or ffmpeg (it also has support for hundreds of obscure formats, in one monolithic library that can't be split), which also has some history of security bugs. If we're going that road, at some point we won't get around having one binary package per source file unless software just stops having bugs. 3) As you might've noticed, one (set) of the problems Chris Evans found was in gstreamer1.0-plugins-good. I'm sure you will also find problems in every other GStreamer package if you just look hard enough, or in any piece of software out there for that matter. I think the only way how to solve this problem is by just fixing bugs as we always do, and mitigation for any so-far unfixed (security) bugs (be it sandboxing relevant parts of the code, ASLR, ...). Splitting the GStreamer packages into more binaries would be worthwhile independent of that, we would have to find a way to keep the workload of everybody at an acceptable level though. And overall, this specific issue seems completely blown out of proportion. Sure there are bugs, they can possibly be exploited and should obviously be fixed. But the problem here is not only GStreamer, and these kind of problems are not only something that would affect GStreamer (ever looked at all the packages getting fixes on debian- security?). It's now just that someone actually took a look at GStreamer, found issues, just put them out there without responsible disclosure and wrote fancy blog posts. That's good as it allows things to get fixed, but it's also nothing special that only affects GStreamer.
signature.asc
Description: This is a digitally signed message part
