Bug#847417: depends on gstreamer-plugins-bad, which is an ongoing source of security holes

[Sebastian Dröge]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gstreamer-maintainers/attachments/20161210/b80a7c6d/attachment.sig>