Hi Guillem (2024.10.05_01:32:45_+0000) > > 1. sigstore https://docs.sigstore.dev/ > > Although I've heard of this before, I never really checked what is > the actual design behind it, and its implications.
I'm new to all this too, but I can answer some of those questions from my own reading: > I'm not sure how reliant on centralization this is, or on the apparent > specific OIDC providers currently in use The signing process is reliant on centralization. The signature scheme trusts the central server and OIDC provider to identify the signer. It signs that assertion and stores it in a CT log. > about offline operations Verification is possible offline, the bundle includes CT proof. The downside of verifying offline is that you can miss revocation. > and whether that is a first class use, or if that implies limitations, > etc. There are definitely limitations. The set of trusted parties is much larger than when verifying an OpenPGP signature. Instead of relying on the signer maintaining perfect security of their OpenPGP keys, we are relying on the security of their OIDC server & sigstore. Signatures are publicly auditable, so fraudulent signatures are theoretically detectable by the identity owner. There are revocation mechanisms. A system like this has a chance of being widely adopted in software ecosystems in a way that I don't think OpenPGP has any more. > Even though in the Python upstream thread it's mentioned that many > upstreams are moving into using it, it's not clear to me either what > are the long-term prospects of this either. Yep. Hard to say. We can sit on the fence until it becomes obvious. This is how we often do things :) In the meantime, packages like Python may drop OpenPGP in favor of it. That may be a small loss. We weren't even verifying Python's OpenPGP signatures until yesterday. > I've not checked either what is the format of the certificates and > signatures for this, how detectable they are, their size, etc. The bundle format (capable of offline use) is a JSON document with a mediaType key. It's detectable. > From Python upstream and your comment below, I take the only > implementations are either Python or Golang, which seems problematic as > something to have to pull into say a build-essential chroots by default. > (Not to mention that these are not even yet in Debian. :) We can take a slower approach and not include support in build-essential chroots for these newer schemes. Re-evaluate later, if one of them really blows up in popularity. And of course, we should probably just start with uscan, and talk about adding support to dpkg later, when we can see significant use. > > 2. ssh signatures > > AFAIK these are used via ssh-keygen. The signatures are pretty easy to > detect, as they are surrounded by «-----BEGIN SSH SIGNATURE-----» and > «-----END SSH SIGNATURE-----» and are ASCII encoded. The certificates > and signatures can be few lines or many lines, but should be > relatively small, probably similar to at most an OpenPGP one. I think > depending on the format the certificates can also be easily detectable. > > I'm not sure I'd be comfortable with having to depend (even weakly) on > openssh-client to be able to work with these. At least the implementation > is portable C so it should be available everywhere, so in theory such > (weak?) dependency would be possible everywhere. I'm not sure how you'd > automatically verify signatures if you need to specify the namespace, > the allowed signers and the signer identity, I guess you'd probably > need to store this alongside as well. And the ssh-keygen CLI seems > rather brittle. :/ > > Is this really being used widely, or much at all? I know it's used in some git tag signing. See: #1023140 Those aren't relevant to dpkg, at all (without git source packages). > > I see supporting them in Debian requiring: > > 1. Decisions on which schemes to support. I'd assume we support all that > > are available in Debian and have some significant use. > > I think that just like some compression formats that might be deemed > not worth the effort, to me this could look similar. > > I also think even then, we could decide that we do not want full > support for all of these, but perhaps still partial support might be > good enough for now. Say shipping the signatures and certs somewhere > that requires no integration infra work, for example, or only > supporting them in say uscan. Yes, I think starting with uscan is the obvious way, but I would want to do so in a way that leaves the way open to support in dpkg later. Ideally without any source package API changes, later. Stefano
