XPost: linux.debian.devel, linux.debian.maint.python
From: guillem@debian.org

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?


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)