On 5/20/26 05:51, Simon McVittie wrote: > On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote: >> I wonder if it would be worth proposing a change to whatever system >> component handles opening files (probably something in Glib, or >> xdg-utils, haven't researched that deeply yet) > > It's a general-purpose specification that is designed to be implemented > by an unlimited number of packages, some of them desktop-specific: > > * GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils' > xdg-open(1) reimplementation > * some Qt/KDE library (I'm less familiar with the KDE world, so I don't > know whether this is done in the Qt layer or somewhere in kdelibs) > * xdg-utils' xdg-open(1) (the reference implementation of that name) > * Debian's mailcap package, which translates fd.o MIME handlers into > traditional mailcap(5) handlers > * web browsers like Firefox and Chromium might reimplement it? not sure > * ... > > so any change to how the spec is to be implemented would have to be > fd.o consensus and spread across all of those.
Honestly, I think the open-ended nature makes it inherently insecure. Sandboxes should only allow allowlist of file types and make everything else fall back to a safe default. This could be a simple text editor (no IDE support!) for text files, and a hex editor (or an error) for binary files. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
