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
Attachment:
signature.asc
Description: PGP signature