Am Mo., 1. Feb. 2021 um 10:37 Uhr schrieb Simon McVittie <s...@debian.org>: > > 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.
Ok, thanks for the Explanation. > > 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. Should I open an issue for that package, or on some gnome package? heif/heic is getting common, would be nice to have support "out of the box" Norbert
