Context: I am trying to deploy a NIPA instance for linux-phy. Thanks for
the amazing work kickstarting and maintaining such an effort.
The end-to-end attestation NIPA test, using patatt, has a problem.
Patch emails are supposed to have the X-Developer-Signature:
and X-Developer-Key: headers, and the hash of the body is supposed to
be able to be verified from the developer's OpenPGP key.
Problem statement: NIPA downloads what it thinks are 'raw' patches from
Patchwork (mbox format, example:
https://patchwork.kernel.org/project/linux-phy/patch/20260216110413.159994-6-krzysztof.kozlowski@oss.qualcomm.com/mbox/)
and runs attestation on those.
But if there was any Reviewed-by: email submitted as a reply to the
original patch, this results in a Reviewed-by tag being automatically
inserted into the body of the mbox file as downloaded from Patchwork.
This effectively corrupts the body as was originally signed, and patatt
validation fails (which means: the patch is no longer in the original
form as submitted by the developer).
Interestingly, the patch, when received from
"b4 mbox 20260216110413.159994-6-krzysztof.kozlowski@oss.qualcomm.com",
is saved as multiple emails into the same file (one per reply),
unsquashed, and patatt validation can be performed individually.
To me this is perhaps more apparent, because I am retroactively building
patches which sat in patchwork for a really long while. But even in
the case of netdev, there is a race condition such that any time the
automated patatt validation runs after receiving a manual Reviewed-by:
tag (slow builder/long queue + fast developer), it will fail.
Do the tools have a problem, or should NIPA not use the patchwork mbox
URL to download the raw_patch, and switch to another fetcher instead?
Context: I am trying to deploy a NIPA instance for linux-phy. Thanks for
the amazing work kickstarting and maintaining such an effort.
The end-to-end attestation NIPA test, using patatt, has a problem.
Patch emails are supposed to have the X-Developer-Signature:
and X-Developer-Key: headers, and the hash of the body is supposed to
be able to be verified from the developer's OpenPGP key.
Problem statement: NIPA downloads what it thinks are 'raw' patches from
Patchwork (mbox format, example:
https://patchwork.kernel.org/project/linux-phy/patch/20260216110413.159994-6-krzysztof.kozlowski@oss.qualcomm.com/mbox/)
and runs attestation on those.
But if there was any Reviewed-by: email submitted as a reply to the
original patch, this results in a Reviewed-by tag being automatically
inserted into the body of the mbox file as downloaded from Patchwork.
This effectively corrupts the body as was originally signed, and patatt
validation fails (which means: the patch is no longer in the original
form as submitted by the developer).
Interestingly, the patch, when received from
"b4 mbox 20260216110413.159994-6-krzysztof.kozlowski@oss.qualcomm.com",
is saved as multiple emails into the same file (one per reply),
unsquashed, and patatt validation can be performed individually.
To me this is perhaps more apparent, because I am retroactively building
patches which sat in patchwork for a really long while. But even in
the case of netdev, there is a race condition such that any time the
automated patatt validation runs after receiving a manual Reviewed-by:
tag (slow builder/long queue + fast developer), it will fail.
Do the tools have a problem, or should NIPA not use the patchwork mbox
URL to download the raw_patch, and switch to another fetcher instead?