Hi, all:
As you may know, I've approached developer patch attestation a few times
already, with mixed results:
- first iteration used separate "attestation documents" via a special
"signatures@xxxxxxxxxx" mailing list, but proved to be too fragile and
convoluted to be practical
- second iteration switched to using in-header signatures using two different
headers, X-Patch-Hashes and X-Patch-Sig. It was better, but I wasn't quite
happy with it, because it required manually parsing patch contents in order
to generate the 3 hashes
Finally, I think I have an implementation that fixes the downsides of the
previous two tries. We still rely on "git mailinfo" to normalize our headers
and body, but we do away with the three different hashes that require parsing
the patch contents. We only generate one header now (X-Developer-Signature),
and the contents of this header are generated using the slightly modified DKIM
standard, covering the following:
- the From header as returned by "git mailinfo"
- the Subject header as returned by "git mailinfo"
- the message body as normalized by "git mailinfo"
This covers all aspects of what is important when it comes to patches and
doesn't result in too much of header bloat. We notably don't sign the "Date"
header because git-send-email will replace it at the time of sending.
Introducing patatt
------------------
I've moved attestation efforts into a standalone tool called "patatt", which
can be found here:
https://git.kernel.org/pub/scm/utils/patatt/patatt.git
https://github.com/mricon/patatt
The codebase is only a few hundred lines of code (plus some scaffolding) and
I am hoping that by moving it into a separate project under a very permissive
license (MIT-0) it will see wider adoption.
You can read full details about patatt here:
https://git.kernel.org/pub/scm/utils/patatt/patatt.git/plain/README.rst
https://github.com/mricon/patatt/blob/main/README.rst (rendered)
The more interesting aspects of this implementation are around keyring
management, so I invite everyone to read that part in the documentation linked
above.
I did a presentation on patatt at the OpenSSF developer identity workgroup
earlier today, so once the recording is available I will send a follow-up
message with the link.
Current b4 attest users
-----------------------
B4-0.7 (currently in development) will pull in the patatt library when
installed from pip, or you can use it via the submodule by running "git
submodule update --init" in the current master branch.
If you currently use "b4 attest" for your patches, you can continue doing so.
In the 0.7 version this operation will switch to using patatt behind the
scenes without any changes to the "b4 attest" flags. Alternatively, you can
switch to using "patatt sign" without waiting for the 0.7 release.
There's some more testing left to do before 0.7 can be considered
release-quality -- plus some outstanding patches I haven't applied -- but I
expect that it will land before much longer.
Best regards,
-K
