On Tue, 11 Sep 2018 13:22:17 +0200 Bastien Nocera <had...@hadess.net> wrote:
> On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list > wrote: > > On Tue, 11 Sep 2018 at 03:11, Magnus Bergman > > <magnus.berg...@snisurset.net> wrote: > > > On Tue, 11 Sep 2018 00:07:27 +0200 > > > Bastien Nocera <had...@hadess.net> wrote: > > > > 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 see what you mean. A few of them (although none of the more > > > serious > > > ones) were even related to the GIF loader specifically. But the > > > sheer > > > volume kind of speaks for itself otherwise. :( > > > > IM joined Google's OSS-Fuzz programme last year: > > > > https://github.com/google/oss-fuzz > > > > The huge surge in CVEs was caused by that --- they've been fixing > > one or two a day ever since. Once they are through this very painful > > process, IM ought to be rather safe. > > > > I do agree though that it's a large and complex thing to use for > > such a (relatively) simple task. > > I maintained ImageMagick in RHEL a long time ago, it was already that > way though security issues cropped up a bit less often than every day > (!). I don't see any reason for us to want to us it. Understandable. Anyway, I made a third GIF loader based on libnsgif and released it. This one also handles all images in the test suit and displays 1_partyanimsm2.gif nicely too (before I even found something that could view it I wasn't sure if it was supposed to show garbage or not). Since libnsgif is very straight forward to use I guess you prefer to write your own loader instead of having abydos in the middle. If you don't already know the API of libnsgif (it lacks documentation) it is probably very easy to get started by porting the abydos plugin to gdk-pixbuf. And here are some tips about things you might want to implement differently: The pixel format libnsgif uses happens to be the same as for gdk-pixbuf (both for big and little endian). This means that the bitmap_create callback can be used to create a GdkPixbuf and bítmap_get_buffer to return the pixels of the GdkPixbuf, so libnsgif can draw directly into it. However this assumes that the rowstride equals the width (which I guess is a valid assumption for RGBA). It would be easy just returning a copy of this GdkPixbuf then requested and use gif_decode_frame() to change the frame then needed (obviously using locking since several independent GdkPixbufAnimationIter could theoretically be used at the same time even if it's a highly unlikely use case). This will possibly make it even simpler and more readable than the approach I took with the abydos loader. The reason I chose to decode all frames directly upon load and then throw away the gif_animation was manly because the conversion of abydos doesn't require the pixels to be copied. Also note that progressive loading is supported by libnsgif, but instead of just feeding it the new bytes, it needs a buffer containing all the previous bytes as well. And you probably want to add support for (netscape style) looping, which is something abydos doesn't support yet. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
