As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.
Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).
For interactivity that should in principle be a solved problem with debconf, if it's not, we would like to hear what's lacking. If there is a problem with a particular package then a bug report would be appreciated.
What I've been wanting to do is to add a better alternative to the dpkg suite, something that can generate a fully functional repo, matching current standards, something like a dpkg-genrepository or similar (which would supersede dpkg-scanpackages and dpkg-scansources, and perhaps even major parts of mini-dak, which would avoid the need to rewrite it from scratch).
This has been part of the dpkg roadmap for some time now (https://wiki.debian.org/Teams/Dpkg/RoadMap). And something I'm slowly but progressively moving towards. But TBH it has been low priority. Knowing of projects that require it, and specifically which parts, or that are already using the static libdpkg library are very valuable, so that those parts can be improved.
If there's enough interest, my plan could be to expose just a subset of the current libdpkg as a shared library for buster.
> Knowing of projects that require it, and specifically which parts, or that are already using the static libdpkg library are very valuable, so that those parts can be improved.
What would be the best way of contributing this sort of information?
As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.
Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).