Bug#1071271: gdk-pixbuf: Consider disabling "other" image decoders as recommended upstream

[Simon McVittie]

Source: gdk-pixbuf
Version: 2.42.10+dfsg-3
Severity: important
Tags: security upstream sid trixie help
X-Debbugs-Cc: Debian Security Team <team at security.debian.org>, gkrellm at packages.debian.org, xsane at packages.debian.org

In response to a security vulnerability in the essentially unmaintained
.ani decoder (CVE-2022-48622), gdk-pixbuf upstream has changed the default
set of loaders that are enabled.

Upstream's position appears to be that gdk-pixbuf should not be considered
to be secure enough for unsandboxed decoding of crafted, malicious images,
even if only the "good" loaders are enabled. At the same time, they are
attempting to mitigate CVEs by disabling the "bad" loaders.

The loaders that are still enabled by default and appear to be considered
to be basically OK are:

- .jpeg: uses libjpeg, built-in since bookworm
- .png: uses libpng, built-in since bookworm
- .tiff: uses libtiff, plugin
- .gif: local C code, plugin

.jpeg and .png are considered to be core functionality, and upstream
recommends having those loaders be built-in so they cannot accidentally
disappear (even if the plugin infrastructure is broken). We follow that
recommendation since bookworm. In older versions, they were plugins like
all the others.

.tiff and .gif are plugins, and it would be technically possible to move
them to a separate binary package if people want to do that (subject to
the usual backwards-compatibility concerns about that breaking apps that
might rely on being able to open those files with no extra dependency).

The loaders that are no longer enabled by default (the "other" loaders) are:

- .ani (Windows animated cursor)
- .bmp (Windows uncompressed bitmap)
- .icns (macOS icon, I think?)
- .ico (Windows icon)
- .pnm (historical Unix)
- .qtif (something to do with Quicktime?)
- .tga (historically used in games)
- .xbm (historical Unix)
- .xpm (historical Unix)

all of which are implemented in local C code and compiled as plugins.

For completeness, we also have several third-party loaders in Debian:

- SVG in librsvg2-common (uses librsvg)
- WebP in webp-pixbuf-loader (uses libwebp)
- HEIF in heif-gdk-pixbuf (uses libheif)
- JPEG-XL in src:jpeg-xl should ideally be enabled too (#1001786)

In Debian unstable, for now I have overridden the default and kept the
poorly-maintained loaders in gdk-pixbuf enabled. This turns out to have
been a good idea, because disabling them is known to break multiple
non-GNOME packages including gkrellm
(<https://gitlab.archlinux.org/archlinux/packaging/packages/gdk-pixbuf2/-/issues/1>,
<https://bugzilla.redhat.com/show_bug.cgi?id=2276464>)
and xsane (<https://bugzilla.redhat.com/show_bug.cgi?id=2276661>).

There is active and contentious discussion upstream, for example on
<https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/169>,
about whether these formats should be enabled by default, disabled by
default, part of gdk-pixbuf, part of a separate source package that is
flagged as legacy, or what. There are good reasons on both sides, and
unfortunately there are people on each side who consider their reasons
to be obviously important and the other side's reasons to be obviously
unimportant.

As a result, if I take any side on this, it's likely to result in me
getting thinly-veiled accusations of incompetence from *someone*, and
I'm sorry but I do not have enough spoons to add more Debian items to
my "must feel guilty about" list; so I am not intending to enter this
fight on either side. If you feel strongly about this, please engage
with upstream; but please don't shoot the messenger, and keep in mind
that the GNOME team in Debian are doing our best to do the least-bad
thing in a situation with no good answer.

It is possible that upstream will force our hand by deleting the "other"
loaders from gdk-pixbuf, in which case it will be increasingly difficult
for us to keep them as part of the same source package downstream, even
if we think that's the best plan.

For Debian, one option would be to keep compiling the "other" loaders,
but move them to one or more separate binary packages that are not
necessarily mandatory. A technical constraint is that the loaders depend
on libgdk_pixbuf-2.0.so.0, so they must have a Depends on the package
that contains libgdk_pixbuf-2.0.so.0, and we should avoid circular
dependencies; ideally we should also avoid circular Depends/Recommends
loops, because those break the ability to autoremove.

For example we could consider this:

    Package: gkrellm
    Depends: libgdk-pixbuf-2.0-0, pixbufloader-xpm

    Package: libgdk-pixbuf-2.0-0
    # note that this cannot be stronger than Suggests without breaking
    # autoremoval of unused packages
    Suggests: gdk-pixbuf-other-loaders, heif-gdk-pixbuf, librsvg2-common, ...
    # contains libgdk_pixbuf-2.0.so.0 only

    Package: gdk-pixbuf-other-loaders
    Depends: libgdk-pixbuf-2.0-0
    # contains libpixbufloader-xpm.so, etc.

or this:

    Package: gkrellm
    Depends: libgdk-pixbuf-2.0-0

    Package: libgdk-pixbuf-2.0-0-minimal
    # contains libgdk_pixbuf-2.0.so.0 only

    Package: libgdk-pixbuf-2.0-0
    Depends: libgdk-pixbuf-2.0-0-minimal
    Recommends: gdk-pixbuf-other-loaders, heif-gdk-pixbuf, librsvg2-common, ...
    # empty metapackage

    Package: gdk-pixbuf-other-loaders
    Depends: libgdk-pixbuf-2.0-0-minimal
    # contains libpixbufloader-xpm.so, etc.

Whatever solution is chosen, we should have a clear and considered
consensus that it's the right one: doing a series of hasty workarounds
and reverts will just make people angry with each other (and with me,
for having opened the discussion) and I don't want that.

    smcv