On Mon, 10 Sep 2018 11:31:42 +0200
Bastien Nocera <had...@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.

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:

> > > - 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

How and where to implement sandboxing is an interesting question still.
gtk-devel-list mailing list

Reply via email to