On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
I've just finished more or less, adjusting the APT test suite
to 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.
This has been delayed. There's ongoing investigation into
sqv and sqopv, which are smaller verifiers from Sequoia,
measuring only 2MB and without an SQLite dependency, hence
saving about 6MB.
We also identified issues with keys that are using SHA-1
binding signatures. I'm in the process of adding a crypto
policy override to APT to re-allow these until 2026; but
we also do not have a way to warn people about upcoming
revocations, so lots of stuff will suddenly fail on a new
year.
I don't want unstable users to switch multiple times
if possible.
There's limitations
1. gpgv-sq - this essentially mostly works as gpgv
now, so we get the feedback we are used to
2. sqopv - produces no usable feedback at this time
if signature verification failed, and also does
not respect SEQUOIA_CRYPTO_POLICY.
3. sqv - produces very detailed feedback, but does not
have supported for clearsigned files. This is _less_
of a blocker: APT detaches signatures itself anyhow
for historical reasons - gpgv lacked the ability to
do so before, and we need to ensure that the verified
bits actually match what we read later on.
RHEL 10 is adopting sq and sqv as the tooling to ship;
sqopv is technically much more powerful than sqv, though,
this may be an odd decision that they went with sqv, given
it also does not share an interface with `sq verify`.
I want to spend a day on my 4 day weekend to see if I
can whack sqopv and sqv into apt test suite compliance.
My plan here is to use
Depends: gpgv-from-sq | gpgv-sq | gpgv
Recommends: gpgv-sq
I'm considering adding architecture restrictions to
allow opt-in on architectures, giving ports the ability
to migrate when they deem ready.
In light of the discussion above about sq(op)v, this
may change into
Depends: sqv [architecture list],
gpgv [!architecture list]
We had some further discussion about gpgv not being
in widespread use and removing it from the default
bootstrap possibly being a reasonable way forward.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
-----BEGIN PGP SIGNATURE-----
wsG7BAABCgBvBYJnTyUXCRBvpFjdHbA/cUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmeLsWDZIEG+3W8Ai7iFhG+6o+hPVhFlf13lauI7QImb CBYhBE+1iKhMLd55p0x3h2+kWN0dsD9xAACeDA//cm/46zCf7oXPGdjwDlrAaxnQ Y9t0mscXwie3kR8k7HWqW4uIByHAzjRcD1Oc6P07K0dPsto3cVxNqbj23zFcIPFj KZ317ES9l2b2C0TX8PAsEqY4ZMTjFYV3HP8NIAdWeP5Tdjhwaz+wV47v5/qxVxpm uejo3po1PJ0nn9LFtyadsq9TqRLHGXEKkulGTWEsNdLJfPcgzXFZi2tHa9l0wIUM vBvKYU+/Nzqov0AfnxSA7t28zCGzkYHUYM74wszgtPtWgW/eZKIUHS1qBZC8n/qj vX90njOLovhkedurZ0aRme0DLHQHJt278P5sfBSxIncm2SWG0/HsNNZEXsl94rHO VMhagFFHhcfl6Y6V8+FxvVoMfRSGutQu/eX2z9LyoUXATNQvql10+ZugGmfC2/yl 4ZH9ql+jGYfYTXWGv1BdqV69QWyoM9TOGsBvGWM6be6ONwTzFfB6h4hoyVidizBF zBZbmSPwwFdMEtF05KMvMwFflK69iEaI0kzZ3urtDkyQ2DqCWWveOVtE5vxetrq8 79A5yq7qFAGT1JIQ/eOAVvizqMflWTZSPTSqzlgbPGSnZ/9SYU0L4PK4jX7sOsBR duKborr/P1TfteaJBb2on+lnPsXJrjpP2CdaAznxms3aWChrw9xmWzSTTH