Julian Andres Klode
2024-11-21 20:20:01 UTC
Reply
Permalinkto test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpgv-sq. Previous
discussions with the security team did not reveal any
blockers for that, despite the strenuous nature of
security updates for Rust packages.
My plan here is to use
Depends: gpgv-from-sq | gpgv-sq | gpgv
Recommends: gpgv-sq
To do 2 things:
1) The Depends will install gpgv-from-sq on new systems. The
gpgv-from-sq package diverts /usr/bin/gpgv to gpgv-g10code
and Provides gpgv, installing a symlink to gpgv-sq.
This ensures that while switching to gpgv-sq, the default
bootstrap does not change in exposed functionality: There
is a /usr/bin/gpgv available.
This does not affect existing systems, as the dependency
is already satisfied by the gpgv alternative.
An optimal mechanism would instea
2) The Recommends ensures that the signature verification
as used by APT is changed, as APT also will prefer gpgv-sq
over gpgv if installed.
This means existing systems will have two gpgv implementations:
- /usr/bin/gpgv from GnuPG
- /usr/bin/gpgv-sq from Sequioa
This is not necessarily the best outcome. We could change
it to gpgv-from-sq as well, such that systems remain with
a single /usr/bin/gpgv. I don't particularly like the idea
of forcing a software change on users, but in the sense of
two systems behaving the same way that of course would be
preferable.
As for ports without gpgv-sq, this does not affect them,
they can be served by the gpgv alternative. Once a gpgv-sq
is available, it's important to note that no migration happens
for them: APT does not install Recommends that were previously
unsatisfied.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en