Summary: | media-libs/imlib2: consider dropping or masking USE=gif due to problematic media-libs/giflib dependency | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> |
Component: | Current packages | Assignee: | NRK <nrk> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dlan, nrk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 933163 |
Description
Sam James
![]() ![]() ![]() ![]() > 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. |