Hi! On Fri, 2024-10-04 at 18:21:01 +0000, Stefano Rivera wrote: > Picking up a thread that started on debian-python@lists.debian.org: > https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea > > Upstreams that care about supply chain security have been building > mechanisms to authenticate their releases, beyond PGP signatures. > For example, Python started providing sigstore signatures a couple of > years ago, and is now talking about the idea of dropping PGP signatures. > https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058
Hmm, I find this usual conflation (in the upstream discussion) of GPG (or GnuPG) as if it was OpenPGP itself rather problematic, because the OpenPGP ecosystem is way richer than that, and as such way more active, and there has been and there is lots of work going on to implement and provide more usable, intuitive, secure and modern interfaces and code, be those CLI or library-first ones (not just wrapping a CLI from a library), including implementation neutral interfaces like the Stateless OpenPGP CLI (SOP). The OpenPGP work group also just got a new RFC9580 published that obsoletes RFC4880. Of course the schism between GnuPG and the OpenPGP work group is rather problematic too, but I'd hope we can manage to move into something like SOP backed by any of the many new implementations that provide it (see [S]), or barring that into any of the native interfaces by implementations that provide easier and more secure to use ones, all of which while eventually following the new RFC. [S] https://gitlab.com/dkg/openpgp-stateless-cli/-/wikis/Stateless-OpenPGP-status For an example of the activity that is going on in the OpenPGP ecosystem, here's a list of some of the non-GnuPG implementations already present in Debian, by programming language: * Rust: - Sequoia-PGP - rPGP * Haskell: - hOpenPGP * Golang: - GopenPGP * Java: - Bouncy Castle - PGPainless * Python: - PGPy * C: - RNP In addition, I'd strongly recommend checking SOP (https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/), which should be nicer to integrate into test suites and tools, by way of any of the currently available implementations in Debian, such as: * sqop / sqopv (Rust) * rsop / rsopv (Rust) * pgpainless-cli (Java) * gosop (Golang) * sopv-gpgv (C + Python) For the sopv subset we also now have a virtual package. And finally, I'd also recommend taking a look at both the Sequoia-PGP native interfaces (but note these are not yet stable, but should be RSN AFAIUI!): * sq / sqv / sq-wot / sq-keyring-linter Where in addition to the usual commands to verify, sign, etc, you have extremely useful stuff like: $ sq inspect ... $ sq cert ... $ sq toolbox keyring ... $ sq toolbox packet ... $ sq network ... $ sq ... And its GnuPG compatibility drop-in replacements, for either: * CLI: - sequoia-chameleon-gnupg (gpg-sq / gpgv-sq) - gpg-from-sq / gpgv-from-sq * Thunderbird (if you use that): - libsequoia-octopus-librnp Oh, and you can already use either SOP or the Sequoia-PGP interfaces with dpkg itself! See dpkg-buildpackage's --sign-backend. > We currently support including PGP signatures in source packages, and > verifying them in uscan. > > Should we expand this to include some of these new mechanisms? > Things brought up in the debian-python thread include: > 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 not sure how reliant on centralization this is, or on the apparent specific OIDC providers currently in use, about offline operations and whether that is a first class use, or if that implies limitations, etc. 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. I've not checked either what is the format of the certificates and signatures for this, how detectable they are, their size, etc. 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. :) > 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? > 3. signify https://man.openbsd.org/signify.1 The certificates and signatures are extremely short, as in around 100 chars or so? But they are going to be hard to detect, as there is no marker, besides a convention of a prefixed line with «untrusted comment: <comment-here>». This looks short enough that perhaps instead of shipping it in a file, it could be added somewhere as a field value? The signify-openbsd package is rather tiny, and its CLI is not too bad. I assume projects with strong BSD origins might use this to sign releases, but how common is this? > 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. > Some, like sigstore, can be used in multiple modes, we'd have to make > some selections. > 2. Support in uscan to verify at download/checkout time. > 2.1: Syntax in watch files to locate signature files. > 2.2: Path in source packages / watch files to declare trusted signers. Right, see my comments about detectability, so we might need to place some of these in different places to make them easily recognizable or distinguishable from other things. > 2.3: Syntax in watch files for signature verification in git mode. > 3. Support in dpkg-source to include detached signatures in source > packages. > 3.1: Declare expected formats and filename extensions. dpkg-source currently normalizes binary OpenPGP signatures into ASCII armored ones, includes references to them into the .dsc when building, and verifies the signatures (using the upstream signing certificates) on build and extraction. It also warns when there's a signing certificate but no signature present. > 4. Support in the archive? (Is anything necessary?) Yes, DAK needs explicit support for this. (At least AFAIR from when adding the current upstream signature support.) > Is this something people are interested in pursuing? In a way the fragmentation in the signing formats and WOT, seems rather annoying. I understand some people (for whatever reason) are not happy with OpenPGP, so that reaction seems to be expected, but it's still a bit meh. :) I'm not sure all new contenders might be ideal to integrate, and doing so also implies "legitimizing" them. For the dpkg part I'm of course open to considerations, but I'm not sure what level of integration might end up making sense there TBH. Thanks, Guillem
