RFE: use patchwork to submit a patch

[Daniel Axtens]

> It does bring up that any new workflow has to have security protocol
> and threat model as part of its design.

This is actually something that worries me about the patchwork
workflow. Maintainers seem to trust the patchwork version of a patch
without much (or any) verification that it matches what was sent to the
list.

Say Alice emails a patch that says something like:

 if ((permissions == allowed) && other_stuff) {
    do_things();
 }
 do_more_stuff(permissions);

List members read that email, and many review it in the email client.

However, say that the version in Patchwork actually reads like this:

 if ((permission = allowed) && other_stuff) {
    do_things();
 }
 do_more_stuff(permissions);

(You could get this with a malicious/compromised patchwork admin, or a
sufficiently advanced network adversary - patchwork takes the first mail
for a given message-id + project and later ones are discarded, so
there's a race you can win.)

If the maintainer or someone else happens to apply the patch from
patchwork and then review it, or if tests happen to catch the relevant
case, we'll catch this. Otherwise...

It's not the easiest or lowest risk way to get malicious code into the
kernel, but nonetheless, I worry about it.

I can't think of a sensible way to fix this, unless we want to move to a
world where patch submissions are GPG signed, and teach patchwork to
verify sigs.

Regards,
Daniel