Re: An alternative to gdk-pixbuf

[Bastien Nocera <hadess hadess net>]

On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:
> On Mon, 10 Sep 2018 11:31:42 +0200
> Bastien Nocera <hadess hadess net> wrote:
>
> > > I've written loader for GIF that simply wraps abydos. In lines of
> > > code it's about a quarter the size of the current loader, even
> > > including
> > > the GIF plugin for abydos. It might even be slightly smaller with
> > > the whole of abydos included in the equation. On the downside it
> > > probably doesn't pass the test suite since I haven't tried it.
> > > But
> > > I will, and hopefully publish the whole thing in a couple of
> > > days.  
> >
> > That's unfortunately not mergeable, and unless you use a library
> > for
> > your GIF plugin in abydos, would just be shifting the potential
> > bugs
> > to the abydos code base.
>
> I do use a library (or two). I've written one plugin that uses giflib
> and one that uses ImageMagick. I assumed using giflib would be a
> straighter path, but it wasn't. Firstly it only supports reading
> images
> from disk (but abydos automatically creates temporary files then
> needed
> so that didn't add any extra code at least). Secondly it doesn't do
> much more than unpacking the pixels. How to interpret what comes out
> is
> left as an exercise for the user, and requires a bit of knowledge
> about
> the GIF formats and it's quirks. So that plugin isn't built by
> default.
> ImageMagick on the other hand did much more to be of help, and
> required
> far less code to use. So shifting the responsibility to ImageMagick
> seems reasonable, I think.

No, it really isn't:
https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html

We want to have less CVEs, not more.

> I tested them both on all the GIF images included in the gdk-pixbuf
> test suit. Both plugins mostly work, but to varying degree. The one
> based on giflib segfaults with 1_partyanimsm2.gif (because the
> allocation containing the pixels which giflib provides is less than
> the
> images width x height, I haven't yet looked deeper into it). The
> ImageMagick based plugin on the other doesn't crash at least, and all
> the invalid images are correctly classified as invalid. The image
> 1_partyanimsm2.gif still shows as garbage except the first frame. The
> image aero.gif has the frame delay set to zero for every frame but
> the
> first. I'm not sure how that should be interpreted, so I simply
> exchanged zero values for a small delay (0.02 seconds). I will read
> up
> on the GIF format and hopefully get things working better.
>
> It's available here if you want to try it out:
> http://snisurset.net/code/abydos/

Having looked at giflib, and knowing the author, the current plan still
is to have something based on libnsgif in the future.

> > > > - we disable every loader by default except the ones that the
> > > > core
> > > > desktop needs
> > > > - image viewers that rely on gdk-pixbuf ship their additional
> > > > loaders
> > > > in the app's Flatpak[1].  
> > >
> > > I don't care much for Flatpak in particular. But generalised and
> > > rephrased as, leave it to the distributors to decide, I agree
> > > that
> > > this is absolutely the best approach.  
> >
> > Without Flatpak, you're just removing image format support from
> > image
> > viewers, as many packaging guidelines in distributions forbid the
> > bundling of libraries. They'd want to ship a single copy of the
> > gdk-
> > pixbuf loaders, and the applications wouldn't have any protection
> > from
> > files that the loaders would trip over.
>
> I'm not arguing against that. I just think it's an issue best left
> entirely to distributors (including the choice between bundling and
> dependencies).
>
> How and where to implement sandboxing is an interesting question
> still.