Re: [PATCH 3/3] RFC: SECURITY.md: Rough draft of codifying the maintainer process

On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <[email protected]> wrote:
>
> Since security issues are quite rare, best to codify the processes so
> when they come along we can fall back to this and dont forget any steps.

don't or do not

>
> Signed-off-by: Jason Zaman <[email protected]>
> ---
>  SECURITY.md | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/SECURITY.md b/SECURITY.md
> index 49c40e97..145a2714 100644
> --- a/SECURITY.md
> +++ b/SECURITY.md
> @@ -35,6 +35,9 @@ the issue as quickly as possible and shorten the disclosure window.
>    *  (GPG fingerprint) 6319 1CE9 4183 0986 89CA  B8DB 7EF1 37EC 935B 0EAF
>  * Ondrej Mosnacek, [email protected]
>
> +If unsure about whether an issue is in kernel or userspace, feel free to send
> +to any and the maintainers will handle it internally.

I'd recommend sending to both rather than any to avoid potential loss/delay.
We should also mention that private vulnerability reporting is now
enabled on GitHub,
so another option is to submit via:
https://github.com/SELinuxProject/selinux/security/advisories

> +
>  ### Resolving Sensitive Security Issues
>
>  Upon disclosure of a bug, the maintainers should work together to investigate
> @@ -57,3 +60,26 @@ lists.
>
>  * https://oss-security.openwall.org/wiki/mailing-lists/distros
>  * https://oss-security.openwall.org/wiki/mailing-lists/oss-security
> +
> +### Maintainer Process
> +
> +This is the process maintainers will follow upon receiving a security notification.
> +
> +1. Make sure all appropriate SELinux maintainers are notified. Regardless of
> +   which maintainer was initially contacted, others should be looped in. This
> +   may also include the kernel maintainers if relevant to the issue.
> +2. After an initial review of the issue, maintainers will agree on one person
> +   to be main point of contact. The response to the initial mail may come from a
> +   different maintainer. If the initial mail was PGP signed/encrypted, the
> +   replies will also be PGP signed/encrypted with one of the above keys.
> +3. Maintainers will work together in private to verify and fix the issue. For
> +   larger fixes, this might involve a github private fork within a draft github
> +   security advisory.
> +4. Maintainers will prepare the fix as soon as reasonable. Maintainers may
> +   invite the reporter to the draft security advisory or private fork to help
> +   verifying the fix.
> +5. We will aim to release the fix publicly quickly, but may request an embargo
> +   period up to 90 days if the complexity of the issue requires it or if
> +   severity of the issue requires coordinated rollout amongst distros.
> +6. Public disclosure will involve pushing the fix to the public repo and
> +   publishing the security advisory on Github and to the mailing list.
> --
> 2.54.0
>
>