Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #16307 > unrolled thread

python devs are planning to stop signing with gpg

Back to article view | Back to linux.debian.maint.python

Contents

  python devs are planning to stop signing with gpg Salvo Tomaselli <ltworf@debian.org> - 2024-09-30 23:50 +0200
    Re: python devs are planning to stop signing with gpg Salvo Tomaselli <ltworf@debian.org> - 2024-10-01 00:20 +0200
      Re: python devs are planning to stop signing with gpg Brian May <bam@debian.org> - 2024-10-01 02:00 +0200
      Re: python devs are planning to stop signing with gpg Stefano Rivera <stefanor@debian.org> - 2024-10-03 17:30 +0200
        Re: python devs are planning to stop signing with gpg Louis-Philippe Véronneau <pollo@debian.org> - 2024-10-03 20:30 +0200
          Re: python devs are planning to stop signing with gpg Jeremy Stanley <fungi@yuggoth.org> - 2024-10-03 22:30 +0200
          Alternative signature mechanisms for upstream source verification Stefano Rivera <stefanor@debian.org> - 2024-10-04 20:30 +0200
            Re: Alternative signature mechanisms for upstream source  verification Mathias Behrle <mbehrle@debian.org> - 2024-10-04 21:30 +0200
            Re: Alternative signature mechanisms for upstream source verification Guillem Jover <guillem@debian.org> - 2024-10-05 03:40 +0200
              Re: Alternative signature mechanisms for upstream source verification Stefano Rivera <stefanor@debian.org> - 2024-10-05 06:10 +0200
              Re: Alternative signature mechanisms for upstream source verification Martin <debacle@debian.org> - 2024-10-05 10:30 +0200
            Re: Alternative signature mechanisms for upstream source verification Simon Josefsson <simon@josefsson.org> - 2024-10-05 12:40 +0200
    Re: python devs are planning to stop signing with gpg Brian May <bam@debian.org> - 2024-10-01 00:30 +0200

#16307 — python devs are planning to stop signing with gpg

[Multipart message — attachments visible in raw view] — view raw

Hello,

I just saw this conversation

https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058

Perhaps someone more expert than me at not making flamewars would like to 
intervene?

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

[toc] | [next] | [standalone]

#16308

[Multipart message — attachments visible in raw view] — view raw

In data martedì 1 ottobre 2024 00:07:46 CEST, Brian May ha scritto:
> Salvo Tomaselli <ltworf@debian.org> writes:
> > I just saw this conversation
> > 
> > https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatu
> > res-for-cpython-artifacts/65058
> > 
> > Perhaps someone more expert than me at not making flamewars would like to
> > intervene?
> 
> In what wee is this going to affect Debian? Do we actually verify GPG
> signatures for upstream sources?

It seems we do not! There should be a file called 
debian/upstream/signing-key.asc
that contains the public key. That's used automatically by uscan when getting 
a new version.

> Is there any other reason I am not aware of why sigstore is a bad
> solution?

sigstore is 3rd party signing. You no longer keep the private key yourself. 
You keep your password/token/whatever to sigstore and they sign your files.

And you hope they'll still be online and secure in the future when you will 
decide to check a signature.

> Somebody needs to post the answers to questions like these to the
> discussion thread.

On that thread they say that it is possible to verify signatures offline. But 
the checker seems to need a number of dependencies.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

[toc] | [prev] | [next] | [standalone]

#16310

Salvo Tomaselli <ltworf@debian.org> writes:

> On that thread they say that it is possible to verify signatures offline. But 
> the checker seems to need a number of dependencies.

"TL;DR: Starting with the next release, --offline will also mean that
sigstore-python performs no automatic trust root updates."

Maybe I am wrong here, maybe this is similar to GPG, but regardless it
made me a bit nervous.
-- 
Brian May @ Debian

[toc] | [prev] | [next] | [standalone]

#16314

Hi Salvo (2024.09.30_22:15:34_+0000)
> > In what wee is this going to affect Debian? Do we actually verify GPG
> > signatures for upstream sources?
> 
> It seems we do not!

Fixed.

> > Is there any other reason I am not aware of why sigstore is a bad
> > solution?
> 
> sigstore is 3rd party signing. You no longer keep the private key yourself. 
> You keep your password/token/whatever to sigstore and they sign your files.

From a quick read of the docs: I think ephemeral keys are used (or can
be?) but the signature is recorded into their CT log, with your account.
That's the bit signed by their key.

> And you hope they'll still be online and secure in the future when you will 
> decide to check a signature.

I see an offline mode is supported.

We should figure out what it would take to support sigstore in Debian
source packages, assuming there is more adoption.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16316

On 2024-10-03 11:29, Stefano Rivera wrote:
> We should figure out what it would take to support sigstore in Debian
> source packages, assuming there is more adoption.

Having that support in uscan and the rest of our tooling would be amazing.

That would let us support things like SSH signatures, like I encountered 
in #1023140.

In general, having viable alternatives to OpenPGP would open an 
interesting door for the general Debian ecosystem...

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#16317

[Multipart message — attachments visible in raw view] — view raw

On 2024-10-03 14:22:09 -0400 (-0400), Louis-Philippe Véronneau wrote:
[...]
> In general, having viable alternatives to OpenPGP would open an
> interesting door for the general Debian ecosystem...

Agreed, OpenBSD projects have been signing release artifacts with
their signify tool for a while, which is (slowly) growing in
popularity too: https://packages.debian.org/signify
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#16321 — Alternative signature mechanisms for upstream source verification

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

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/
2. ssh signatures
3. signify https://man.openbsd.org/signify.1

There is a general trend towards getting upstream sources from Git
rather than tarballs in Debian, but we're a long way from moving across
completely, or even finding consensus to do so.
These signature mechanisms can generally be applied to git commits as
well as tarballs.

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.
   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.
   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.
4. Support in the archive? (Is anything necessary?)

Is this something people are interested in pursuing?

For sigstore, we probably need to package the Python / go client in
Debian. We have rekor-cli for low-level verification, but not tools for
verifying bundles like the ones Python provides.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16324 — Re: Alternative signature mechanisms for upstream source verification

* Stefano Rivera: " Alternative signature mechanisms for upstream source
  verification" (Fri, 4 Oct 2024 18:21:01 +0000):

[...]

> 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/
> 2. ssh signatures
> 3. signify https://man.openbsd.org/signify.1

JFTR: Tryton moved from pgp signatures to signify, so of course I would
appreciate if this format could be handled as well.



-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

[toc] | [prev] | [next] | [standalone]

#16325 — Re: Alternative signature mechanisms for upstream source verification

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

[toc] | [prev] | [next] | [standalone]

#16326 — Re: Alternative signature mechanisms for upstream source verification

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

[toc] | [prev] | [next] | [standalone]

#16327 — Re: Alternative signature mechanisms for upstream source verification

On 2024-10-05 03:32, Guillem Jover wrote:
> 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:

Thanks for the list! I was aware of some of them, but not all.

>  * Python:
>    - PGPy

I wonder, how that could escape my radar ;-) Thanks!

(Need to file an RFP for https://openpgpjs.org/ btw.)

Cheers

[toc] | [prev] | [next] | [standalone]

#16328 — Re: Alternative signature mechanisms for upstream source verification

[Multipart message — attachments visible in raw view] — view raw

Stefano Rivera <stefanor@debian.org> writes:

> 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/
> 2. ssh signatures
> 3. signify https://man.openbsd.org/signify.1

+1

I believe all signatures we trust should be encoded in a non-mutable
transparency log like Sigstore/Sigsum etc.  But the first step towards
that is to add support for verifying that property.

> There is a general trend towards getting upstream sources from Git
> rather than tarballs in Debian, but we're a long way from moving across
> completely, or even finding consensus to do so.
> These signature mechanisms can generally be applied to git commits as
> well as tarballs.

Signatures of git commits is the same as a signature on a SHA1 object
which is broken for authentication purposes.  But it is possible to
discuss these issues separately, paving the way for git commit signing
to be trustworthy when GitHub/GitLab moves to SHA256.

/Simon

[toc] | [prev] | [next] | [standalone]

#16309

Salvo Tomaselli <ltworf@debian.org> writes:

> I just saw this conversation
>
> https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058
>
> Perhaps someone more expert than me at not making flamewars would like to 
> intervene?

In what wee is this going to affect Debian? Do we actually verify GPG
signatures for upstream sources?

The replacement sigstore - verification is online only (at least as per
comments in thread). Do we have a requirement to check signatures
offline?

Is there any other reason I am not aware of why sigstore is a bad
solution?

Somebody needs to post the answers to questions like these to the
discussion thread.
-- 
Brian May @ Debian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web