A new image loading machinery, called glycin, has been in the works for a while. It is already used by GNOME’s default Image Viewer (Loupe), as well as by a bunch of other apps. Glycin provides many security benefits over existing solutions due to the use of the Rust programming language and sandboxing. Distributions will now be able to use the security benefits and broader format support of glycin for other GNOME apps, thumbnailers, and GNOME Shell, whithout changing any existing software. This is made possible by a new option for GNOME’s legacy image-loading library, GdkPixbuf, to use glycin internally.
↫ Sophie Herold
Clearly, this is an improvement over the previous image loading library, but there’s a bit of a catch that is in line with GNOME’s increased reliance on systemd features: glycin only works on Linux due to its sandbox mechanisms and how it communicates with its loaders. However, there’s no need to fret this time, and that’s why I’m posting this item – you just know this tiny little tidbit will find their way into internet discussion forums and social media as another example of GNOME not caring about non-Linux users.
While some of the sandboxing and communication features in glycin can be made to work on the BSDs and perhaps macOS, it won’t be perfect. As such, great care has been taken to ensure non-Linux platforms can continue to use GdkPixbuf just fine, since support for other platforms is part of the goals of this change before traditional loaders are removed.
As a general solution for other platforms, I am planning a mechanism to compile the loaders into the library. This will not provide sandboxing and format extendability without recompilation. But since most loaders are written in Rust, this is still a huge step-up security wise. Contributions for support on other platforms are welcome. For GdkPixbuf users, this will not pose an immediate issue since traditional gdk-pixbuf loaders are not going away until all platforms it supported, are supported by glycin.
↫ Sophie Herold
There are a few other issues, as any change like this tends to cause, like the list of supported images formats. Glycin supports AVIF, BMP, DDS, Farbfeld, QOI, GIF, HEIC, ICO, JPEG, JPEG XL, OpenEXR, PNG, PNM, SVG, TGA, TIFF, and WEBP out of the box, but some of the subformats within each of these might potentially not work entirely correctly due to incorrect implementations by, say, camera manufacturers. A special case here is the TIFF format, which apparently still has a number of issues and might end up relying on a fallback.
Glycin brings a ton of benefits, such as improved colour support for things like HDR and wider colour gamut displays, better metadata support, basic image editing functions out of the box, increased performance, as well as the benefits inherent in using a memory-safe language like Rust.
So for every image to load, a new process gets forked, a unix socket instantiated, and content is streamed over the unix socket. That’s at least 3 copies of the file (unless using io_uring, which I kind of doubt).
I’m curious about the performance numbers. Those can’t be too good.
But it’s security! Just buy the most expensive SSDs you can get and raid 0 them!
It’s in the Jesus language so it can’t be wrong!
On a more serious note, I wonder if they load their button icons through this and how many times per run in a single application…
Serafean,
It could be worse, at least it’s not implemented as a google/amazon/ms service! That’s what goes for innovation these days. Like the addition of python scripts to excel: it’s a genuinely useful feature to replace antiquated VBS, which everyone hates. But they engineered the feature run your document’s python scripts on MS servers…WTF nobody wanted this! [/offtopic]
I do see the value of using a memory safe language, but using a separate address space is overkill. It used to be more common to design unix software in different processes, but unsurprisingly there is a performance cost and software like apache have actually evolved in the opposite direction over the years because multiprocess designs are slower and less efficient compared to multithreading and asynchronous designs.
What would be interesting to have is a memory safe language that lets us enforce barriers using logical barriers rather than address space separation. This actually comes fairly naturally to memory managed languages like java/c# and microsoft built an experimental operating system based on this principal…
https://en.wikipedia.org/wiki/Singularity_%28operating_system%29
This could be a really cool feature for rust to incorporate. We could write tons of software modules, all running in the same CPU address space, yet support different trust zones within the same process. Something like this would actually be very useful here and much more elegant and efficient than out of process daemons over dbus.
> What would be interesting to have is a memory safe language that lets us enforce barriers using logical barriers rather than address space separation.
I think you mostly described Erlang…
Serafean,
That’s an interesting comparison. You are right it’s not a new idea and isolated processes is a neat language feature of erlang. Correct me if I am wrong, but I think erlang is based on run time memory management and garbage collection like java and c#. The “problem” with these is that run time checks and garbage collection still carry a stigma for performance sensitive programming. I was thinking it would be interesting for rust because of it’s compile time advantages.
Correct, erlang has everything in userspace/its process space. Unlike Java, AFAIK erlang doesn’t have to freeze the world during GC. It’s why I hate using jetbrains IDEs: from time to time, the UI just freezes, because GC…
https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
The beauty of open source: you can read the code! And even better, you can submit a patch! (Contributing to JUring, I do know what i am talking about.)
Obviously not curious enough to run some basic benchmarks by yourself before questioning the project? Again, you can even submit your benchmarks to the project!
So if i understand it properly: Make all other “non adawaita to look like shit” And pixbuf was basicly already banned in Adawaita already… it is destruction.
Just let IBM have their “linux” failiure named “redhat” and “fedora” that decided that conflicts over politics are more important than solving a problem. To be Fair i do not give a freaking schmooly about the coders sexual orientation or in fact anyone elses.
G* whatever pixbuf has been dead for 20 years. just get qt.