giflib appears to have a terrible security profile: * bug 785664 * bug 851945 * bug 918539 In the latest upstream release, they indicated that they aren't interested in any sort of bug reports on invalid input. Please consider, if appropriate, either dropping USE=gif support, package.use.masking it, or perhaps disabling it by default via package.use (given the desktop profiles enable USE=gif by default). If this package is expected to only interact with trusted gifs or you feel it's critical to the functionality of this package, feel free to close as WONTFIX. Thanks. If you're not sure, consider raising this with upstream of this package to see what they suggest.
> giflib appears to have a terrible security profile: As far as I see, those bugs are related to the utility cli program that comes with giflib. Not a vulnerability in the library itself. Imlib2 only uses the library not the provided cli utilities so this should be completely irrelevant for Imlib2 (or any other package that merely uses the library only for that matter of fact).
(In reply to NRK from comment #1) > > giflib appears to have a terrible security profile: > > As far as I see, those bugs are related to the utility cli program that > comes with giflib. Not a vulnerability in the library itself. > That's a fair point. I'd say that I'm not convinced the library is actually flexed by anything well - or it's impossible to use safely - given all the tools in giflib seem to be buggy in one way or another (see also e.g. https://sourceforge.net/p/giflib/bugs/170/), but you're right that it's conjecture then. > Imlib2 only uses the library not the provided cli utilities so this should > be completely irrelevant for Imlib2 (or any other package that merely uses > the library only for that matter of fact). ... so maybe I don't need to panic so much. Still worth us reducing needless use of it I think, as it doesn't look of great quality, but I'm far less worried now.
> Still worth us reducing needless use of it I think Imlib2 doesn't directly need gif (since it's a library itself, not an end user package) but other packages that use imlib2 do (e.g `nsxiv` in guru). I don't know if it's "critical" but an image viewer being able to view one of the most widely used image format is certainly not "needless" :) > so maybe I don't need to panic so much. On this note, I feel like the situation about library packages installing utilities unconditionally is a more broader quality issue. For example, I remember trying to replace some `app-arch/bzip2` dependencies with `app-alternatives/bzip2` but this was a nightmare because `app-arch/bzip2` installs both utility and library. And so there's no way to quickly know whether a certain package wants the library or the utility. Most other distros split such thing into different packages. In gentoo, at the very least we could make it a QA policy to have a `util`/`lib` useflag so that dependencies can be stated more precisely.
Has there been any new discovery here that may change the situation? If not, I think I'm fine with closing this off as either INVALID or WONTFIX.
