On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote: > 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.
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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
