patchwork + nipa + patatt

[vladimiroltean]

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?

[kuba-moo]

Maintainers download the mbox from patchwork when applying patches (we use dborkman/pw.git from korg). So it's nice to run most of the checks on patches which approximate what we will get in our tree before we push. IDK how much processing (other that adding tags) patchwork does, maybe it doesn't matter.
A conservative fix would be to download both the mbox (for most checks) and also real(?) patch from ML archive for patt? Would that be too hacky? Patchwork has a mailing list archive link in patch metadata.

[vladimiroltean]

A conservative fix would be to download both the mbox (for most checks) and also real(?) patch from ML archive for patt? Would that be too hacky? Patchwork has a mailing list archive link in patch metadata.

The problem is that it would break ingest_mdir.py which doesn't assume a Patchwork instance exists.

[kuba-moo]

I assumed ingest_mdir.py would populate both raw_patch and real_patch with the same thing, that's fine. Only in the deployed instance there'd be a difference between the contents of the two. Would that be problematic?