Julian Andres Klode <j...@debian.org> writes: > I'm strongly opposed to add support for these off-the-shelve solutions. > We need end-to-end control of all aspects of signing. > > What we learned with OpenPGP is that we don't want to be tied to third > party off-the-shelve solutions as we cannot control the cryptography and > are subject to the whims of their developers. > > Hence we're still stuck with 1024-bit RSA keys in freaking 2024. > > I have started apt-sign to get rid of the horrors of OpenPGP and get > a sensible format. I still have to make some changes to it, but if > we want to have a solution it essentially will boil down to adding > this to the Signatures field which will have lines of the form: > > <algorithm> <base64-blob> > > where <algorithm> currently is apt-ed448 or apt-ed25519. > > It's entirely possible to require signatures from multiple keys > and implement co-signing that way rather than bolt on off-the-shelve > crap that we cannot control.
That seems interesting, where can we find this implementation? I can't find a branch or merge request. Where is the Signature: field placed? Inside the (In)Release file? All the above seems orthogonal to support for key-usage transparency mechanisms. Do you plan to implement that too? What protocol? If not, your signature method ought to be extended to support some key-usage transparency method, in some similar way to what I proposed how to extend our current PGP-based verification with key-usage transparency support. Sigstore and sigsum are two methods that I am aware of, but there may be others. Or, finally, if there will be no built-in key-usage transparency method in apt, and no support for extensions to add support, this will be supported externally to apt by those who care about it. /Simon
signature.asc
Description: PGP signature
