patatt: end-to-end developer attestation for patches

patatt: end-to-end developer attestation for patches

[Konstantin Ryabitsev]

Hi, all:

I would like to introduce patatt, which is a small tool/library for end-to-end
cryptographic attestation of patches sent via email. It aims to solve the
problem of needing to trust mail gateways, mailing list archives, or any other
kind of inherently untrustworthy infrastructure.

# How it works

Patatt works by adding a separate header containing a cryptographic signature
attesting the body of the message, plus the headers relevant to git commit
operations ("From" and "Subject", specifically). The hashing and signing is
done using a slightly adapted version of the widely used DKIM standard.

Since the signature is placed into its own email header, it will stay
completely out of the way of any existing tools operating on patches (git-am,
patchwork, stgit, quilt, etc), so patches carrying attestation will not break
any of the existing workflows but will be picked up and checked using tools
like b4 (starting with version 0.7).

For more technical details, please see:
https://pypi.org/project/patatt/#basic-concepts

You can also watch the presentation I made to the OpenSSF developer
attestation WG:
https://www.youtube.com/watch?v=no6r1iUqY1A

# How to start signing your patches

It is very easy to start signing all your patches, especially if you use
git-send-email.

1. install patatt (e.g. with "pip install --user patatt")
2. tell it which PGP key to use, or generate a new ed25519 key
3. add a sendemail-validate hook

See instructions here for full details:
https://pypi.org/project/patatt/#getting-started-as-contributor

# How to start verifying attestation as a project maintainer

The only tool currently implementing patatt attestation is b4, and if you're
using a workflow that relies on patches sent to mailing lists, I invite you to
try b4 out for your needs. B4 can either work with remote public-inbox
repositories, or fully local mailboxes. To install b4, you can use:

pip install --user b4

## Maintaining a project keyring

Patatt/B4 can use your global GnuPG keyring for validation, or a separate
keyring maintained as part of the project's git repository. It can be kept
either in the main development branch, in a dedicated repository ref, or in a
wholly external repository used just for the keyring.

Please see this here for the concepts and general overview of in-git
contributor keyrings:
https://pypi.org/project/patatt/#in-git-pubkey-management

Here is an example of b4 retrieving an attested patch series:

    $ b4 am -o/tmp 20210521184811.617875-1-konstantin@linuxfoundation.org
    Looking up https://lore.kernel.org/r/20210521184811.617875-1-konstantin%40linuxfoundation.org
    Analyzing 3 messages in the thread
    Checking attestation on all messages, may take a moment...
    ---
      ✓ [PATCH 1/3] Sign Message-Id header if present
      ✓ [PATCH 2/3] Make header order deterministic
      ✓ [PATCH 3/3] Release as 0.4.0
      ---
      ✓ Signed: openpgp/konstantin@linuxfoundation.org
      ✓ Signed: DKIM/linuxfoundation.org
    ---
    Total patches: 3
    ---
     Link: https://lore.kernel.org/r/20210521184811.617875-1-konstantin@linuxfoundation.org
     Base: not found
           git am /tmp/20210521_konstantin_sign_message_id_header_if_present.mbx

As you can see, b4 will validate both the DKIM signature, and the
X-Developer-Signature header when it finds it.

# Questions welcome

This is still considered an experimental feature, so I would be happy to
receive feedback about the concepts and implementation.

Best regards,
-Konstantin