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

Attachment: signature.asc
Description: PGP signature

Reply via email to