I’m wondering primarily for https://snapcraft.io/pinta whether the Glycin image encode/decode stack for Gnome will be ready in snapd? Relating to this blog.
Copying my comments from elsewhere, are these statements accurate? And if so are they being addressed?
a high level it likely involves:
Changes to the desktop interface to accomodate new DBus calls
Changes to snapd via the snapctl binary in the runtime environment to allow it to replace the functionality of flatpak-spawn
Patches to Glycin to become aware of the snapctl changes so it can make use of them to create the subsandbox.
If the first bullet is required, this would also require a new minimum snapd version. Thankfully across most platforms, snapd either updates itself, or is updated in the distribution repos separately. But that might mean these changes get pushed back to Core26 depending on how the implementation ends up proceeding.
This library is now causing problems in one of my projects already.
Has there been any mention of this as part of future Gnome extension updates? I can’t see anything on my end and my concern is that if we don’t patch this library to avoid expecting to micromanage its own sandbox, we will break nearly every consumer application in the ecosystem. From what I’ve read of the source code, this is actually trivial if we simply force the library to always run in development mode, it’s no less secure than the security today, and still gains memory safety benefits from being Rust - better solutions can be worked on in time .
.