Prioritize glycin and Papers thumbnailers on GNOME 49

[jakedane]

With GNOME 49 there are now multiple thumbnailers for the same file types:

• GNOME 49 introduced glycin for safer thumbnailing, and much appreciated !, but libavif, libheif, libjxl, librsvg and evince (for tiff) for example on my system also provide a thumbnailer for AVIF, HEIF, JXL, SVG and TIFF image file types which glycin can also thumbnail.
• GNOME 49 added Papers as the new document viewer but Evince can’t be removed as Sushi still depends on it. So, Papers and Evince both provide thumbnailers for document file types.

Is there any logic to prefer certain thumbnailers, or are there plans for such?

As I read it, gnome_desktop_thumbnail_factory_load_thumbnailers_for_dir () in gnome-desktop uses g_dir_read_name () to find the thumbnailers files, which doesn’t guarantee any order. Indeed, using a simple test script on my system:

#!/usr/bin/python3
import gi
from gi.repository import GLib
gdir = GLib.Dir.open('/usr/share/thumbnailers/', 0)
while (name := gdir.read_name()) is not None:
	print(name)

returns this jumble of files:

avif.thumbnailer
gnome-mobi-thumbnailer.thumbnailer
totem.thumbnailer
evince.thumbnailer
gsf-office.thumbnailer
glycin-image-rs.thumbnailer
heif.thumbnailer
gnome-epub-thumbnailer.thumbnailer
librsvg.thumbnailer
glycin-jxl.thumbnailer
papers.thumbnailer
gnome-font-viewer.thumbnailer
jxl.thumbnailer
glycin-heif.thumbnailer
glycin-svg.thumbnailer

Is this the order in which thumbnailers are tried for files? If so that would mean for AVIF, TIFF (evince), HEIF and SVG image types GNOME doesn’t use the glycin thumbnailer!

And same for document types, that would mean GNOME doesn’t use the Papers thumbnailer at all as Evince is higher up in the list.

---

And looking at init_thumbnailers_dirs () in gnome-desktop it adds more complexity as it looks for thumbnailers in XDG_DATA_HOME and XDG_DATA_DIRS, which on my system means it looks for thumbnailers in this order:

/home/jake/.local/share/thumbnailers
/home/jake/.local/share/flatpak/exports/share/thumbnailers
/var/lib/flatpak/exports/share/thumbnailers
/usr/local/share/thumbnailers
/usr/share/thumbnailers

So that would mean if there are user or flatpak thumbnailers for image types those would be prioritized over the safer glycin, even if glycin can thumbnail the same image type. That can’t be the intention of having the safer glycin thumbnailer added in GNOME 49

I’d suggest it’s processing thumbnailer directories the wrong way around — it should prefer system thumbnailers and only use user or flatpak thumbnailers for file types not provided by system thumbnailers. (Or actually I think it should never use user thumbnailers as that’s a security risk.)

Am I reading all this wrong?

[mcatanzaro (Michael Catanzaro)]

I don’t have answers to all your questions, but here are a few thoughts.

@jakedane

• GNOME 49 introduced glycin for safer thumbnailing, and much appreciated !, but libavif, libheif, libjxl, librsvg and evince (for tiff) for example on my system also provide a thumbnailer for AVIF, HEIF, JXL, SVG and TIFF image file types which glycin can also thumbnail.

It doesn’t make any sense to build the libavif/libjxl/librsvg thumbnailers at all anymore, since they depend on gdk-pixbuf2-thumbnailer. We have stopped building them all in Fedora. See: Fedora mailing list discussion.

libheif is a bit different: it’s redundant with the glycin thumbnailer and therefore unnecessary, but it doesn’t depend on gdk-pixbuf, so it’s harmless to keep around.

Regarding Evince vs. Papers: incomplete transitions are sad. No other comment from me.

@jakedane

I’d suggest it’s processing thumbnailer directories the wrong way around — it should prefer system thumbnailers and only use user or flatpak thumbnailers for file types not provided by system thumbnailers. (Or actually I think it should never use user thumbnailers as that’s a security risk.)

That would be the opposite of how things usually work. Normally if you install something yourself in your home directory, it’s because you want to override the distro-provided version. Preferring system thumbnailers over user thumbnailers would be pretty weird. If you’re worried that a thumbnailer might be insecure, then I would recommend not installing it.

[jakedane]

@mcatanzaro

It doesn’t make any sense to build the libavif/libjxl/librsvg thumbnailers at all anymore, since they depend on gdk-pixbuf2-thumbnailer.

Thanks I’ll see if I can address this with my distro maintainers or upstream.

@mcatanzaro

libheif […] doesn’t depend on gdk-pixbuf, so it’s harmless to keep around.

Except for the fact that libheif comes before glycin-heif on my system so it would cause the safer glycin to not be used for HEIF files.

@mcatanzaro

If you’re worried that a thumbnailer might be insecure, then I would recommend not installing it.

It’s more about badware having an entry point to be run without the user noticing.

[sophieherold]

@jakedane

which doesn’t guarantee any order.

Yes, that is bad. Sadly there isn’t even a standard for thumbnailers. I have written one that defines that alphabetic ordering must be followed to at least make systems behave more predictable.

@jakedane

GNOME 49 introduced glycin for safer thumbnailing

Note that thumbnailing on GNOME has been sandboxed for a long time. Glycin adds some additional safety by using a lot of decoders that are written in Rust, but it still uses libheif for avif and heic. The glycin sandbox is not used, since the thumbnailer already provides a sandbox.

@mcatanzaro

libheif is a bit different: it’s redundant with the glycin thumbnailer and therefore unnecessary, but it doesn’t depend on gdk-pixbuf, so it’s harmless to keep around.

I don’t think any of the thumbnailers have been particularly “harmful” since they are sandboxed anyway. However, the glycin libheif loader handles far more cases correctly:

[sophieherold]

@jakedane

Except for the fact that libheif comes before glycin-heif on my system so it would cause the safer glycin to not be used for HEIF files.

As mentioned above, I don’t see any difference in ‘safety’ here since both use libheif and both are sandboxed the same way.

[mcatanzaro (Michael Catanzaro)]

I suspect it’s easy to break out of the thumbnailer sandbox. We recently discovered that have not updated it to account for the past several years’ worth of known CVEs.

[jakedane]

@sophieherold

I have written one that defines that alphabetic ordering must be followed to at least make systems behave more predictable.

Okay, good to have confirmation. And that there’s a proposal to make the order more predictable.

@sophieherold

I don’t see any difference in ‘safety’ here since both use libheif and both are sandboxed the same way.

Thanks for clearing that up. Looking at glycin > Supported Image Formats does that mean for JXL and SVG the safety situation is basically the same, with glycin using libjxl and librsvg for those?

What’s the reason the glycin libheif loader handles more cases correctly than libheif itself?

[jakedane]

@mcatanzaro

It doesn’t make any sense to build the libavif/libjxl/librsvg thumbnailers at all anymore, since they depend on gdk-pixbuf2-thumbnailer. We have stopped building them all in Fedora. See: Fedora mailing list discussion.

Changes for the same were accepted by Arch Linux. Thanks for the suggestion

libavif, libjxl and librsvg on are no longer built with their gdk-pixbuf loader or thumbnailer.

libheif is no longer built with its gdk-pixbuf loader but still includes the thumbnailer, same as on Fedora (libheif-tools). Edit: the next release of libheif will disable the thumbnailer.

Thank you both for your help.

[sophieherold]

@mcatanzaro

I suspect it’s easy to break out of the thumbnailer sandbox. We recently discovered that have not updated it to account for the past several years’ worth of known CVEs.

Can you explain this to me? Do you mean the sandbox is vulnerable if there is a Kernel which has unpatched security issues? If so, you need updated sandbox code to block the syscall, so it would only help in the scenario where you update the sandbox package but not the kernel?

Is there a good source for this information? The shared syscall block list mentions https://groups.google.com/g/libseccomp, but I can’t find anything in the recent history there.

[mcatanzaro (Michael Catanzaro)]

@sophieherold

Can you explain this to me? Do you mean the sandbox is vulnerable if there is a Kernel which has unpatched security issues? If so, you need updated sandbox code to block the syscall, so it would only help in the scenario where you update the sandbox package but not the kernel?

No, I mean the list of seccomp filters has not

Is there a good source for this information? The shared syscall block list mentions https://groups.google.com/g/libseccomp, but I can’t find anything in the recent history there.

The comment you’re looking at, which we’ve copied around between a bunch of different places that we update independently, is ancient. Nowadays the actual upstream is Flatpak and the location for tracking vulnerabilities is here. gnome-desktop has failed to keep pace with updates to Flatpak’s list of seccomp filters.

However, fortunately I think all of the sandbox escapes fixed by Flatpak only matter when the app is running in a terminal, which is very unlikely to be the case for an exploited thumbnailer. So I was wrong to say it would be “easy” to escape the sandbox.