On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote: > Package: wnpp > Severity: wishlist > Owner: si...@josefsson.org > X-Debbugs-CC: debian-de...@lists.debian.org > > * Package name : apt-verify > Version : 2.0 > Upstream Contact: Simon Josefsson <si...@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