Control: reassign -1 libglycin-2-0
Control: found -1 2.1.5+ds-2
On Sun, 13 Sep 2026 at 19:46:46 -0400, Nick Black (Public gmail account) wrote:
In my ideal world, gdk would fall back on some other decoding mechanism
in the absence of kernel seccomp support. I anticipate that this might
be a non-starter either for security or implementation cost reasons.
Yes, this is really a glycin thing rather than gdk-pixbuf, and I suspect
it'll be wontfix for security reasons. Web browsers and image loaders
use seccomp as part of sandboxing components that act on untrusted
(attacker-controlled) content, and the number of people using LLMs to
find image parser vulnerabilities continues to be larger than the number
of people actually fixing the image parsers, so I don't think disabling
CONFIG_SECCOMP is suitable for a general-purpose desktop system in 2026.
it would at least be nice to get obvious and clear failure
diagnostics. This latter choice is most likely done in libglycin itself.
Reassigning to glycin for that. gdk-pixbuf doesn't know the specifics of
what glycin is doing (glycin's use of seccomp in its sandboxing of the
image decoders is opaque to gdk-pixbuf) so it can't produce useful
diagnostics if that fails.
I suspect that providing clear failure diagnostics in glycin will also
be difficult, because it's creating its sandbox by running bubblewrap
(bwrap) as a subprocess, so likely the best it will be able to do is to
provide the error messages from bwrap's standard error stream, which are
low-level and extremely technical.
smcv
