Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[Julian Andres Klode <jak@debian.org>]

On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: simon@josefsson.org
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
> * Package name    : apt-verify
>   Version         : 2.0
>   Upstream Contact: Simon Josefsson <simon@josefsson.org>
> * URL             : https://gitlab.com/debdistutils/apt-verify
> * License         : AGPLv3+
>   Programming Lang: Shell script
>   Description     : extend apt's gpgv-based verification mechanism
> 
> Apt-verify extends apt to call all tools in /etc/verify.d/ instead of
> always only calling gpgv, to verify apt archive integrity and
> authenticity.  A symbolic link in /etc/verify.d/gpgv is installed by
> default to provide full backwards compatibility.


David already said a lot of good things but let me extend on that:

- apt-key use is slated for removal no later than Feb 29th.
- apt signature verification should not involve shell scripts
  (hence the removal in the first place)
- apt-verify looks like it's an apt tool and is easy to confuse
  with apt-sign, apt's openpgp replacement, and what will likely
  be the name of the method verifying apt-ed25519 signatures,
  'verify'

In closing let me say I consider overriding APT's signature verification
to be RC-buggy and would immediately file an RC bug should that package
be accepted.

-- The road forward, signature verification and sandboxing concerns

I do not think we currently have a way to move forward with signature
verification hooks due to issues with the download sandbox. If we want
to come up with solutions to plug in additional verification steps, we
first need to

1) finish the sandboxing to move verification of files outside the
   sandbox, or writes from the download and decompressor steps into
   a deeper sandbox

   Essentially my consideration is to replace the entire acquire stack
   with a new event-based stack that's easier to reason about because at
   this point the interactions between the classes we have are
   unreasonable and not understandable.

2) figure out how we can integrate additional verification steps
   with well known security properties that ensure reliability of
   the sandbox. We don't just want to run arbitrary hooks in the
   sandbox (or as root really).

3) figure out a protocol for this. My goal is to adopt varlink in
   APT for IPC to provide a daemon for APT as well as to replace
   custom IPC protocols we currently have like the various classic
   hooks, the JSON hooks, and the acquire protocol.

   Then it would be nice to be able to say "hook in after
   'org.debian.apt.verify' and do additional things".

This will probably take until 2030 or so if I'm the only one working on
it but that's the position that we should aim for rather than blindly
hooking in things where they're not expected or creating hooks that we
don't know how they will work in the final design.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en