On 11/1/25 8:34 PM, Simon Josefsson wrote:
Andrey Rakhmatullin <wrar@debian.org> writes:On Sat, Nov 01, 2025 at 02:29:06PM +0100, Simon Josefsson wrote:BTW, reaching for "modern" means that you will never succeed. It will always be what's coming next.A (reduced feature) variant of 'apt' in perl or pythonWithout signing support, I assume?Implementing the subset of a PGP verifier in perl or python that handle the Debian signatures is relative low complexity, especially compared to the complexity of all of apt today. Although I think we are seeing the end of PGP utility in this context, and I believe before soon it is reasonable to demand transparency chain signatures rather than traditional signatures that allows the "hidden release" attack by the private key holder. The python ecosystem already has migration towards Sigstore and there are Go and C code signed this way already, besides the large Docker container ecosystem.
I was actually looking into this recently, but Sigstore is also in flux right now: they have a new tile-based log format that is not quite ready yet, they dropped OpenPGP support in the most recent revision, and the signing key types I think cannot currently express our Elliptic Curve keys (although RSA4096 worked fine).
In trying to retrofit this I also ran into the classic "and now I have an additional file to InRelease to provide the inclusion proof" problem.
I'd be interested in working on a design for this. The thing is that I think we need to keep the PGP bits for a long while and it would probably make more sense to try at least some retrofitting to bring the verification possibilities to the current ecosystem before potentially replacing the signature scheme[1].
Kind regards Philipp Kern[1] Where I realize that OpenPGP keys might have both too many functions and potentially not the right ones to do what we want. But that'd require some requirements analysis.