On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote: > * Package name : apt-verify
It is bad enough that apt-* is a free for all name grab outside of the Debian archive, I would very much prefer if we would not encourage it inside Debian at least… Especially as this has zero mentions on deity@ and declares itself a hack that you now want to ship with next stable even through it is utterly unsupportable for Debian as at least I, as an APT developer, am unwilling to declare the apt::key::gpgvcommand option a supported interface & I don't see who else would step up… I added this completely undocumented option in apt-key in 2015 in the process of supporting gpgv2, so that our tests could be run against gpgv, gpgv1 and gpgv2. As we no longer have such a need, that option could disappear any second. apt-key itself is heavily deprecated and might disappear in the future. That it is used by libapt currently is also an implementation detail (again, of the gpg2 supporting kind) we are unwilling to declare a supported interface and could be changed any second. I can't give you an exact time line, but I think Julian even already wrote some PoC code for libapt, so that the parts from apt-key it secretly reuses will no longer be needed. Its definitely on the (long) todo list and has some likelihood of being done before trixie releases. (And that is ignoring if calling gpgv will even remain the only option). So, in summary, while no such thing as a VETO formally exists for ITPs, I intend this mail to be as close to a VETO as possible – by the power of our dear super cow. In terms of what this actually does: I haven't looked too closely, but it seem like you want libapt code not to just call its gpgv-method, but to also (optionally) call a bunch of other methods before and/or after it, which all have to approve before we can proceed. Certainly not the easiest thing in the world to implement, but not that hard either… after all, we have support for client-merged pdiffs (which isn't used much nowadays, as Debian moved to server-merged pdiffs years ago) which are downloaded in parallel and wait on each other before proceeding. So, not rocket-science. It would also solve a bunch of problems you already have ("it is currently not known how to find out which apt repository (apt URL) was used") and the many you will have as soon as you have actual users (I see e.g. apt-canary downloading files) that you can solve only by being a proper part of the acquire process, not by attaching yourself with duck tape and hot glue to its underbelly. Especially not if you want this to be a security feature… Best regards David Kalnischkies
signature.asc
Description: PGP signature