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@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
✓ Signed: DKIM/linuxfoundation.org
---
Total patches: 3
---
Link: https://lore.kernel.org/r/20210521184811.617875-1-konstantin@xxxxxxxxxxxxxxxxxxx
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
