Re: An alternative to gdk-pixbuf

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
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.
I will, and hopefully publish the whole thing in a couple of

That's unfortunately not mergeable, and unless you use a library
your GIF plugin in abydos, would just be shifting the potential
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
from disk (but abydos automatically creates temporary files then
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
left as an exercise for the user, and requires a bit of knowledge
the GIF formats and it's quirks. So that plugin isn't built by
ImageMagick on the other hand did much more to be of help, and
far less code to use. So shifting the responsibility to ImageMagick
seems reasonable, I think.

No, it really isn't:

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
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
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
on the GIF format and hopefully get things working better.

It's available here if you want to try it out:

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
desktop needs
- image viewers that rely on gdk-pixbuf ship their additional
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
this is absolutely the best approach.  

Without Flatpak, you're just removing image format support from
viewers, as many packaging guidelines in distributions forbid the
bundling of libraries. They'd want to ship a single copy of the
pixbuf loaders, and the applications wouldn't have any protection
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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]