{"thread":{"id":"55776","subject":"patatt: end-to-end developer attestation for patches","startedAt":"2021-05-26T21:08:05Z","lastAt":"2021-05-26T21:08:05Z","messageCount":1,"participants":["Konstantin Ryabitsev"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425587","messageId":"20210526210756.ue5lfcyexz2dwfa6@nitro.local","threadId":"55776","inReplyTo":null,"subject":"patatt: end-to-end developer attestation for patches","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-05-26T21:07:56Z","receivedAt":"2021-05-26T21:08:05Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"Hi, all:\n\nI would like to introduce patatt, which is a small tool/library for end-to-end\ncryptographic attestation of patches sent via email. It aims to solve the\nproblem of needing to trust mail gateways, mailing list archives, or any other\nkind of inherently untrustworthy infrastructure.\n\n# How it works\n\nPatatt works by adding a separate header containing a cryptographic signature\nattesting the body of the message, plus the headers relevant to git commit\noperations (\"From\" and \"Subject\", specifically). The hashing and signing is\ndone using a slightly adapted version of the widely used DKIM standard.\n\nSince the signature is placed into its own email header, it will stay\ncompletely out of the way of any existing tools operating on patches (git-am,\npatchwork, stgit, quilt, etc), so patches carrying attestation will not break\nany of the existing workflows but will be picked up and checked using tools\nlike b4 (starting with version 0.7).\n\nFor more technical details, please see:\nhttps://pypi.org/project/patatt/#basic-concepts\n\nYou can also watch the presentation I made to the OpenSSF developer\nattestation WG:\nhttps://www.youtube.com/watch?v=no6r1iUqY1A\n\n# How to start signing your patches\n\nIt is very easy to start signing all your patches, especially if you use\ngit-send-email.\n\n1. install patatt (e.g. with \"pip install --user patatt\")\n2. tell it which PGP key to use, or generate a new ed25519 key\n3. add a sendemail-validate hook\n\nSee instructions here for full details:\nhttps://pypi.org/project/patatt/#getting-started-as-contributor\n\n# How to start verifying attestation as a project maintainer\n\nThe only tool currently implementing patatt attestation is b4, and if you're\nusing a workflow that relies on patches sent to mailing lists, I invite you to\ntry b4 out for your needs. B4 can either work with remote public-inbox\nrepositories, or fully local mailboxes. To install b4, you can use:\n\npip install --user b4\n\n## Maintaining a project keyring\n\nPatatt/B4 can use your global GnuPG keyring for validation, or a separate\nkeyring maintained as part of the project's git repository. It can be kept\neither in the main development branch, in a dedicated repository ref, or in a\nwholly external repository used just for the keyring.\n\nPlease see this here for the concepts and general overview of in-git\ncontributor keyrings:\nhttps://pypi.org/project/patatt/#in-git-pubkey-management\n\nHere is an example of b4 retrieving an attested patch series:\n\n    $ b4 am -o/tmp 20210521184811.617875-1-konstantin@linuxfoundation.org\n    Looking up https://lore.kernel.org/r/20210521184811.617875-1-konstantin%40linuxfoundation.org\n    Analyzing 3 messages in the thread\n    Checking attestation on all messages, may take a moment...\n    ---\n      ✓ [PATCH 1/3] Sign Message-Id header if present\n      ✓ [PATCH 2/3] Make header order deterministic\n      ✓ [PATCH 3/3] Release as 0.4.0\n      ---\n      ✓ Signed: openpgp/konstantin@linuxfoundation.org\n      ✓ Signed: DKIM/linuxfoundation.org\n    ---\n    Total patches: 3\n    ---\n     Link: https://lore.kernel.org/r/20210521184811.617875-1-konstantin@linuxfoundation.org\n     Base: not found\n           git am /tmp/20210521_konstantin_sign_message_id_header_if_present.mbx\n\nAs you can see, b4 will validate both the DKIM signature, and the\nX-Developer-Signature header when it finds it.\n\n# Questions welcome\n\nThis is still considered an experimental feature, so I would be happy to\nreceive feedback about the concepts and implementation.\n\nBest regards,\n-Konstantin\n"}]}