Bug#981538: libgdk-pixbuf2.0-bin: supported mimetypes are not extended with additional gdk-pixbuf loader

[Simon McVittie]

Control: reassign -1 heif-gdk-pixbuf 1.10.0-2
Control: retitle -1 heif-gdk-pixbuf: should have Recommends on heif-thumbnailer?

On Mon, 01 Feb 2021 at 09:19:58 +0100, Norbert Lange wrote:
> I was not getting thumbnails for heic/heif files.
> 
> I would expect that installing the heif-gdk-pixbuf should
> be enough to enable support, but it needed editing the file
> /usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer,
> and adding the image/heif Mimetype.
> 
> Naturally this change will be lost everytime this package
> will be upgraded.

I don't think this is really something that the gdk-pixbuf package can or
should solve on its own. The thumbnailer files in /usr/share/thumbnailers
are static, not dynamic, and gdk-pixbuf-thumbnailer.thumbnailer is
only designed to describe the formats that are supported by the base
gdk-pixbuf library.

One way it can be solved in packages that extend gdk-pixbuf would be for
them to have a Suggests, Recommends or Depends on libgdk-pixbuf2.0-bin, and
install a /usr/share/thumbnailers/foo-gdk-pixbuf.thumbnailer
that runs the same gdk-pixbuf-thumbnailer command, but has MimeType set
according to the MIME types for which this package adds support.
That's a direct equivalent of what happens in the librsvg2-common package,
also from GNOME, to add SVG support to gdk-pixbuf, which suggests that it
is the upstream-supported approach to getting more MIME types thumbnailed
via gdk-pixbuf.

However, in the particular case of libheif it seems that this is
unnecessary, because there is also a heif-thumbnailer package that
provides its own, more specific thumbnailing code (extracting a thumbnail
from metadata if available, rather than loading the entire HEIF image just
to scale it down). I would recommend installing that if you are interested
in HEIF files.

Authors of gdk-pixbuf plugins and .thumbnailer files should be aware that
file managers like Nautilus will trigger thumbnailing for downloaded files
(for example in ~/Downloads), and some web browsers will download files
into ~/Downloads without prompting under some circumstances (a "drive-by
download"). Combining these two factors means that a thumbnailer adds
significant attack surface to the system, so authors of gdk-pixbuf plugins
should not provide a corresponding .thumbnailer file for formats whose
decoder is not written defensively, with maliciously-crafted image files
in mind. Nautilus and libgnome-desktop attempt to mitigate any exploitable
bugs in thumbnailers by running them in a restricted sandbox environment,
but I don't think all consumers of the .thumbnailer mechanism do this.

As a result, even if it was straightforward to implement, I think it would
be inappropriate for gdk-pixbuf to automatically provide thumbnailing
services for unknown gdk-pixbuf plugins: the authors of plugins that
are believed to be robust against maliciously-crafted image files need to
take action to opt-in to participating in the thumbnailing mechanism, and
take responsibility for the consequences.

libheif maintainers: if heif-thumbnailer is considered safe for use,
then I think heif-gdk-pixbuf should probably have a Recommends (or
even Depends?) on heif-thumbnailer, to meet user expectations around
thumbnailing. If it's a Depends, then heif-thumbnailer should probably
become Multi-Arch: foreign, so that it does not prevent heif-gdk-pixbuf
from being Multi-Arch: same.

    smcv