Your message dated Mon, 09 Feb 2026 12:20:05 +0000
with message-id <[email protected]>
and subject line Bug#1071271: fixed in gdk-pixbuf 2.44.5+dfsg-3
has caused the Debian Bug report #1071271,
regarding gdk-pixbuf: Consider disabling "other" image decoders as recommended
upstream
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1071271: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071271
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: gdk-pixbuf
Version: 2.42.10+dfsg-3
Severity: important
Tags: security upstream sid trixie help
X-Debbugs-Cc: Debian Security Team <[email protected]>,
[email protected], [email protected]
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
--- End Message ---
--- Begin Message ---
Source: gdk-pixbuf
Source-Version: 2.44.5+dfsg-3
Done: Jeremy Bícha <[email protected]>
We believe that the bug you reported is fixed in the latest version of
gdk-pixbuf, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Jeremy Bícha <[email protected]> (supplier of updated gdk-pixbuf package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Mon, 09 Feb 2026 07:00:40 -0500
Source: gdk-pixbuf
Built-For-Profiles: noudeb
Architecture: source
Version: 2.44.5+dfsg-3
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers
<[email protected]>
Changed-By: Jeremy Bícha <[email protected]>
Closes: 1071271 1116981 1120607
Launchpad-Bugs-Fixed: 2122289
Changes:
gdk-pixbuf (2.44.5+dfsg-3) unstable; urgency=medium
.
* Re-enable glycin for loong64
* Release to unstable
.
gdk-pixbuf (2.44.5+dfsg-2) experimental; urgency=medium
.
[ Alessandro Astone ]
* d/control, d/rules: Enable glycin on i386
.
[ Carlos Henrique Lima Melara ]
* d/rules: remove useless if clause in dh_auto_test override
.
[ Jeremy Bícha ]
* Disable glycin for loong64 because it isn't fully bootstrapped yet.
glycin is now enabled on all other Debian Release Architectures, but not
enabled on any Debian ports.
* Bump Standards Version to 4.7.3
.
[ Simon McVittie ]
* Opt into Salsa CI
.
gdk-pixbuf (2.44.5+dfsg-1) experimental; urgency=medium
.
* New upstream release
* d/rules: Re-enable build test gating
* d/p: Rebase patches
* d/patches: Fix tests with older gdk-pixbuf installed in the rootfs
* d/patches: Use the native xpm and xbm loaders instead of glycin
.
gdk-pixbuf (2.44.4+dfsg-3) experimental; urgency=medium
.
* Enable the legacy non-glycin XPM & XBM loaders for glycin architectures
(Closes: #1120607)
.
gdk-pixbuf (2.44.4+dfsg-2) experimental; urgency=medium
.
* Switch to glycin for release architectures and loong64 except i386
(Closes: #1116981, #1071271) (LP: #2122289)
* Depend on glycin-thumbnailers on those architectures
* libgdk-pixbuf2.0-bin no longer contains a thumbnailer on those
architectures, but still contains gdk-pixbuf-pixdata and
gdk-pixbuf-csource, so stop recommending it on those architectures
* Use dh-exec to manage architecture-specific install rules
* Follow Fedora's example and disable auto features
Checksums-Sha1:
fb65f07f404f2792b433c057f3fa04db12863b43 3403 gdk-pixbuf_2.44.5+dfsg-3.dsc
91af9f5c85e526c232fabe6b72f3fefffb2a9eb6 23704
gdk-pixbuf_2.44.5+dfsg-3.debian.tar.xz
eeb143b58c055cc2cf6bc4174fd659fffb0fd1d5 11727
gdk-pixbuf_2.44.5+dfsg-3_source.buildinfo
Checksums-Sha256:
0070a6e217a5972e4cb83f62579e2e010e9ef40b9765ed69ff74340935612979 3403
gdk-pixbuf_2.44.5+dfsg-3.dsc
8e40f2ddda1a9e647ee0ebbbfd886238bd8aa2ec575f5d341d6d0e4bfe3b9fd5 23704
gdk-pixbuf_2.44.5+dfsg-3.debian.tar.xz
637cafe0ac41863541e37a460bfe654a104e6a1f9945a198a4eb76ace54a0597 11727
gdk-pixbuf_2.44.5+dfsg-3_source.buildinfo
Files:
2b87497532b22dcc7a2dc80aed4a9074 3403 libs optional
gdk-pixbuf_2.44.5+dfsg-3.dsc
35d66db5f6f2097ff5e49ec7be74e971 23704 libs optional
gdk-pixbuf_2.44.5+dfsg-3.debian.tar.xz
72d5e1db7e7c0a8438daf731faadb4ed 11727 libs optional
gdk-pixbuf_2.44.5+dfsg-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmmJzL4ACgkQ5mx3Wuv+
bH3zsQ//ey+nVUfBHwfPK3wSOua0slhXp4PCtPAiDDqTwf9D7REnxZPijWV9n5rs
mSWRRhx8qrUmT9aPVwX04nD+fkcbBQ/a8O+q8ws+e4HXrSO+dBgiQ9ceVUiyMN7L
T2zfSLnRcs9Ix+M72UXIRoBHafKlo+jlpZRvvRnr8RTXuTJv42EZv44HA8B9IVjE
nwY8ZuvLSmsVD1oVZVjGTiSKwtmoDoHZlgwzMcw3ELj/Wibpyd9gShT2VRfUC4b6
rPqbizFKHl/h4Nt77YI8MEH0qW8seM60yhMuF2qj4XETIgK9xhtgOktJrr9XH7hD
WJWnB7SuH+NC+bLTyV9KNMAj2Bx3WNfhhWYrb8F6rlsazJMZt8hsOuSxu1635P1J
10vdz/it+XOtSC0qT3aA0RvyKVJlUratRJ0FuoZSxlU1k+oIe9uk0YQiCBz+gOfV
Us/Y3E9nuyC0VCDVmFhjcA3Ome3vij8Vh2leL49YrG0mrqkxU52h22V3bddonhgq
inxDgTavXzP++1LafDKcTNLTkaoD4tlHed6Xx9qS6ZEJVsj4lMnVXccnLOBWVOPy
0tILGpDs73l2kFFECUXvxYOsrW//N4cyb6WLP89CPRE8lCUsp62afJnoSR1MQHh9
a6ciNyimJ1pYGO7jjMWzO3LtB9qKkXA9NKj9/zQ8kA3L0AdOqFc=
=Bll/
-----END PGP SIGNATURE-----
pgp9juka0qPsb.pgp
Description: PGP signature
--- End Message ---
