On Tue, 03 Jun 2025 at 06:51:11 -0400, Daniel Kahn Gillmor wrote:
On Mon 2025-06-02 19:15:01 +0100, Simon McVittie wrote:
What is "the system default OpenPGP verifier"? Is that a
yet-to-be-designed mechanism, or some sort of default-sopv virtual
package or metapackage, or what?
i'd expect the system default OpenPGP verifier to be whatever package
Provides: sopv, and is pointed to by sopv in the default $PATH. At the
moment, that's an update-alternatives question.
That answers the question for this one specific installation ("the
system" in the sense of "this system I'm typing my email into"), but it
doesn't answer the question for "the Debian system". The system default
MTA is the package that provides /usr/sbin/sendmail, but deciding that
wasn't enough: we also needed to choose Exim. That isn't the only choice
we could have reasonably made - Ubuntu chose Postfix instead, and in
fact I use the non-default Postfix on my own Debian systems - but it's
necessary that each distro did choose one, so that sysadmins can predict
the behaviour of a new installation.
And, similarly, if Debian decided to switch our default to Postfix, or
if Ubuntu decided to switch their default to Exim, that would be
completely fine (both are entirely reasonable MTAs), as long as it's
someone's deliberate decision rather than something that happened by
mistake.
I'd love to get more feedback on what you (and others) think a stable
and simple way to have that be a stock choice for debian.
I think the design that's used for MTAs and the D-Bus message bus could
make a lot of sense for sopv:
- packages that want to verify signatures via this interface and don't
particularly care about the specifics have Depends: default-sopv | sopv
- at most one package per architecture Provides the default-sopv virtual
package at any one time, so that there is no ambiguity about what it
means
D-Bus is perhaps a more interesting example here than MTAs, because the
default-dbus-session-bus virtual package is genuinely implemented by
different real packages on Linux (dbus-user-session) and non-Linux
(dbus-x11), as a result of dbus-user-session requiring systemd which is
non-portable.
Or default-sopv could be a real metapackage/dependency package instead
of a virtual package, more like default-jdk; that would be fine too.
For historical reasons default-mta and mail-transport-agent use
different names, as do default-jdk and java-sdk; but the precedent I've
tried to set with the D-Bus virtual packages is that Debian's default
implementation of the virtual package FOO should be named default-FOO,
and I think that's a good pattern to follow in future. For D-Bus, the
values of FOO are dbus-session-bus and dbus-system-bus. For the PGP
ecosystem, I imagine the values of FOO would be sop and sopv, and
possibly others.
Either of those designs means that if/when we want to change the default
implementation, we can change the O(1) packages involved in providing
the implementation of the interface, and all consumers of that interface
can continue to depend on "default-FOO | FOO" and will automatically
pick up the new default.
sqopv seems to exist on all release architectures, and on all -ports
architectures that have a working rustc/cargo. Even if we're assuming
that non-Rust -ports architectures are important, the the minimum to get
a predictable installation would be to list some real package that
exists on those architectures as higher-preference than (i.e. before)
the sopv virtual package, like maybe:
sqopv # real package, but not on all architectures
| gpgv # real package, portable fallback
| sopv # virtual package
I think this order would be a mistake. We should prefer sopv over gpgv,
because the sopv semantics and interface are deliberately minimalist,
stable, and well-understood.
OK, in that case:
sqopv | sopv-gpgv | sopv
or perhaps
sqopv | sopv-gpgv | sopv | gpgv
The desirable property here is that on every architecture, there is an
existing, "real" package listed before the first virtual package:
- on architectures with Rust, apt will prefer sqopv unless told otherwise,
giving us predictability; it won't install a randomly chosen one of
{ sqopv, rsopv, sopv-gpgv } based on the phase of the moon
- and similarly on architectures without Rust, apt will prever
sopv-gpgv, rather than choosing a random implementation of sopv
What I'm trying to avoid is that when I bootstrap a container with
Essential + apt, either in Debian or in a Debian derivative that I'm
responsible for, I get sqopv one week and rsopv the next, without anyone
having made a conscious decision to change the default. I don't really
care which one I get, and I'm happy to defer to your much-more-expert
opinion on which one should be preferred, as long as what I get is
predictable and mostly stable, only changing if the relevant facts or
opinions have changed.
smcv
