• Re: Alternative signature mechanisms for upstream source verification

    From Mathias Behrle@1:229/2 to All on Fri Oct 4 21:30:01 2024
    XPost: linux.debian.devel, linux.debian.maint.python
    From: mbehrle@debian.org

    * 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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Stefano Rivera@1:229/2 to All on Fri Oct 4 20:30:02 2024
    XPost: linux.debian.devel, linux.debian.maint.python
    From: stefanor@debian.org

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Martin@1:229/2 to Guillem Jover on Sat Oct 5 10:30:02 2024
    XPost: linux.debian.devel, linux.debian.maint.python
    From: debacle@debian.org

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Stefano Rivera@1:229/2 to All on Sat Oct 5 06:10:01 2024
    XPost: linux.debian.devel, linux.debian.maint.python
    From: stefanor@debian.org

    [SoupGate killed MIME-encoded file 00000000.ATT (4659 bytes)]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Simon Josefsson@1:229/2 to Stefano Rivera on Sat Oct 5 12:40:01 2024
    XPost: linux.debian.devel, linux.debian.maint.python
    From: simon@josefsson.org

    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

    -----BEGIN PGP SIGNATURE-----

    iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwEWnRQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoiJzAQCiA63P/cLfQZKPpjVnAYhNfBTNX52l hEWyk7krfYlWWQEArjo1j/4/yWdL48UlmgvWMLaotP8eStD9+AP3Bzu5agk=
    =8MHr
    -----END PGP SIGNATURE-----

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