from Konstantin Ryabitsev
For the past few weeks I've been working on a tool to fetch patches from lore.kernel.org and perform the kind of post-processing that is common for most maintainers:
- rearrange the patches in proper order
- tally up various follow-up trailers like
- check if a newer series revision exists and automatically grab it
To use it, all you need to know is the message-id of one of the patches in the thread you want to grab. Once you have that, you can use the lore.kernel.org archive to grab the whole thread and prepare an mbox file that is ready to be fed to
$ b4 am email@example.com Looking up https://firstname.lastname@example.org Grabbing thread from lore.kernel.org Analyzing 26 messages in the thread Found new series v2 Will use the latest revision: v2 You can pick other revisions using the -vN flag --- Writing ./v2_20200313_christian_brauner_ubuntu_com.mbx [PATCH v2 1/3] binderfs: port tests to test harness infrastructure Added: Reviewed-by: Kees Cook <email@example.com> [PATCH v2 2/3] binderfs_test: switch from /dev to a unique per-test mountpoint Added: Reviewed-by: Kees Cook <firstname.lastname@example.org> [PATCH v2 3/3] binderfs: add stress test for binderfs binder devices Added: Reviewed-by: Kees Cook <email@example.com> --- Total patches: 3 --- Link: https://firstname.lastname@example.org Base: 2c523b344dfa65a3738e7039832044aa133c75fb git checkout -b v2_20200313_christian_brauner_ubuntu_com 2c523b344dfa65a3738e7039832044aa133c75fb git am ./v2_20200313_christian_brauner_ubuntu_com.mbx
As you can see, it was able to:
- grab the whole thread
- find the latest revision of the series (v2)
- tally up the
Reviewed-bytrailers from Kees Cook and insert them into proper places
- save all patches into an
- show the commit-base (since it was specified)
- show example
Pretty neat, eh? You don't even need to know on which list the thread was posted — lore.kernel.org, through the magic of public-inbox, will try to find it automatically.
If you want to try it out, you can install
pip install b4
The same, but now with patch attestation
On top of that,
b4 also introduces support for cryptographic patch attestation, which makes it possible to verify that patches (and their metadata) weren't modified in transit between developers. This is still an experimental feature, but initial tests have been pretty encouraging.
I tried to design this mechanism so it fulfills the following requirements:
- it must be unobtrusive and not pollute the mailing lists with attestation data
- it must be possible to submit attestation after the patches were already sent off to the list (for example, from a different system, or after being asked to do so by the maintainer/reviewer)
- it must not invent any new crypto or key distribution routines; this means sticking with PGP/GnuPG — at least for the time being
If you are curious about the technical details, I refer you to my original RFC where I describe the implementation.
If you simply want to start using it, then read on.
Submitting patch attestation
If you would like to submit attestation for a patch or a series of patches, the best time to do that is right after you use
git send-email to submit your patches to the list. Simply run the following:
b4 attest *.patch
This will do the following:
- create a set of 3 hashes per each patch (for the metadata, for the commit message, and for the patch itself)
- add these hashes to a YAML-style document
- PGP-sign the attestation document using the PGP key you set up with git
- connect to mail.kernel.org:587 and send the attestation document to the email@example.com mailing list.
If you don't want to send that attestation right away, use the
-n flag to simply generate the message and save it locally for review.
Verifying patch attestation
b4 am, the tool will automatically check if attestation is available by querying the signatures archive on lore.kernel.org. If it finds the attestation document, it will run
gpg --verify on it. All of the following checks must pass before attestation is accepted:
- The signature must be “good” (signed contents weren't modified)
- The signature must be “valid” (not done with a revoked/expired key)
- The signature must be “trusted” (more on this below)
If all these checks pass,
b4 am will show validation checkmarks next to the patches as it processes them:
$ b4 am 202003131609.228C4BBEDE@keescook Looking up https://lore.kernel.org/r/202003131609.228C4BBEDE@keescook Grabbing thread from lore.kernel.org ... --- Writing ./v2_20200313_keescook_chromium_org.mbx [✓] [PATCH v2 1/2] selftests/harness: Move test child waiting logic [✓] [PATCH v2 2/2] selftests/harness: Handle timeouts cleanly --- [✓] Attestation-by: Kees Cook <firstname.lastname@example.org> (pgp: 8972F4DFDC6DC026) --- Total patches: 2 --- ...
These checkmarks give you assurance that all patches are exactly the same as when they were generated by the developer on their system.
Trusting on First Use (TOFU)
The most bothersome part of PGP is key management. In fact, it's the most bothersome part of any cryptographic attestation scheme — you either have to delegate your trust management to some shadowy Certification Authority, or you have to do a lot of decision making of your own when evaluating which keys to trust.
GnuPG tries to make it a bit easier by introducing the “Trust on First Use” (TOFU) model. The first time you come across a key, it is considered automatically trusted. If you suddenly come across a different key with the same identity on it, GnuPG will mark both keys as untrusted and let you decide on your own which one is “the right one.”
If you want to use the TOFU trust policy for patch attestation, you can add the following configuration parameter to your
[b4] attestation-trust-model = tofu
Alternatively, you can use the traditional GnuPG trust model, where you rely on cross-certification (“key signing”) to make a decision on which keys you trust.
Where to get help
b4 or patch attestation are breaking for you — or with any questions or comments — please reach out for help on the kernel.org tools mailing list: