On 2025-06-17 18:37, Charles Plessy wrote:
> By the way I wish there were as simple mechanisms to signal to all users (not
> just developers) whether a Debian package has maintainer scripts or not, and
> issuing a warning when the upgrade of a third-party package adds a new
> maintainer script. Maybe a different media type? File browser icon could be
> different, the output of `file` could tell it, and I am sure that even better
> solutions can be found.
I think this may be misleading. There are many paths for code to run as
root: udev triggers and init scripts are just two off the top of my head.
If such a user-visible signal were made, it should indicate something
meaningful---perhaps indicating that all changes were made to some limited
set of locations (say /{etc,usr/{bin,share,lib}}/$packagename), no setuid]
bits, and no maintainer scripts (again, just off the top of my head).
I think this idea of "almost untrusted packages" is not worth it, though.
It would only make sense if it were accompanied by some very strong
sandboxing, which would inevitably make the tool useless for most users
(at least using the primitives currently available).
What I think we all kind of want is something close to the Android
permission system, but using the native Debian libraries (i.e., without
the snap/flatpack/docker overhead). For a short while I was dreaming
about a flatpack runtime that just mounted /usr into the namespace, but
the documentation and tooling at the time was felt something between
indifferent and adversarial to this objective, so I've been using Firejail
instead.
Sorry if this is tangent to your objective, but it seems like we might
be trying to achieve the same goal: limiting the amount of trust that
must be given to an installed Debian package, possibly allowing for
safely lowering the standards of review for packages.
Best,
Antonio
