linux-hardening - patchwork triage process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <202110201522.7C700A80D7@keescook>
Date:   Wed, 20 Oct 2021 15:26:50 -0700
From:   Kees Cook <keescook@...omium.org>
To:     linux-hardening@...r.kernel.org
Subject: patchwork triage process

Hi,

Here's my proposal[1] for handling the patchwork patch states:

New: No activity yet.
 - Move to "Under Review" (possibly with a delegate assigned to do the review).
 - Move to "Superseded" if a newer version of the same patch has been sent
   (the patchwork-bot usually does this automatically).

Under Review: Reviewers need to give feedback on the patch.
 - Move to "Changes Requested" if a new version of the patch is needed
   after review feedback.
 - Move to "Handled Elsewhere" if a non-linux-hardening tree says they are
   applying the patch.
 - Move to "Queued" if a linux-hardening tree applies the patch.
 - Move to "Superseded" if a newer version of the same patch has been sent
   (the patchwork-bot usually does this automatically).
 - In rare cases, a patch can be moved to "Rejected", but that is uncommon,
   as normally review feedback is expected to be acted on.

Handled Elsewhere: Going via another tree, but not yet in linux-next.
 - Move to "Awaiting Upstream" once a patch appears in linux-next (the
   patchwork-bot usually does this automatically).

Queued: Going via a linux-hardening tree, but not yet in linux-next.
 - Move to "Awaiting Upstream" once a patch appears in linux-next (the
   patchwork-bot usually does this automatically).

Awaiting Upstream: In linux-next, but not yet in Linus's tree.
 - Move to "Mainlined" once a patch appears in Linus's tree (the
   patchwork-bot usually does this automatically).

Mainlined: Done! In Linus's tree.


This should let us see each given state, and makes a distinction between
things going via one of the KSPP trees (Queued) vs a different subsystem
(Handled Elsewhere). i.e. we can check for stalled patches by getting
a list of all the "Handled Elsewhere" patches, since any that appeared
in -next should have moved on to "Awaiting Upstream", etc.

Thoughts?

-Kees


[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Patch_Tracking

-- 
Kees Cook