[PATCH 1/3] SECURITY.md: Update security contacts

[PATCH 1/3] SECURITY.md: Update security contacts

[Jason Zaman]

Part of the annual cleanup of security contacts, drop people that are
not as active committers currently. Thanks for all the work over the
years!

Signed-off-by: Jason Zaman <jason@perfinion.com>
---
 SECURITY.md | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index a1d02c4d..49c40e97 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -25,10 +25,6 @@ the issue before it is made public, but we will make every effort to address
 the issue as quickly as possible and shorten the disclosure window.
 
 * Petr Lautrbach, plautrba@redhat.com
-* Nicolas Iooss, nicolas.iooss@m4x.org
-  *  (GPG fingerprint) E25E 254C 8EE4 D303 554B  F5AF EC70 1A1D A494 C5EB
-* Jeffrey Vander Stoep, jeffv@google.com
-* Joshua Brindle, brindle@gmail.com
 * James Carter, jwcart2@gmail.com
   *  (GPG fingerprint) 4568 1128 449B 65F8 80C6  1797 3A84 A946 B4BA 62AE
 * Paul Moore, paul@paul-moore.com
@@ -37,7 +33,6 @@ the issue as quickly as possible and shorten the disclosure window.
   *  (GPG fingerprint) 578C 4211 832F 0A7E A2C5  A7C2 21A4 6E60 3F74 4ECF
 * Jason Zaman, perfinion@gentoo.org
   *  (GPG fingerprint) 6319 1CE9 4183 0986 89CA  B8DB 7EF1 37EC 935B 0EAF
-* Steve Lawrence, slawrence@tresys.com
 * Ondrej Mosnacek, omosnace@redhat.com
 
 ### Resolving Sensitive Security Issues
-- 
2.54.0

[PATCH 2/3] ci: Drop circleci config

[Jason Zaman]

We have not used circleci in many years, the configs are very out of
date compared to the github actions so need to get cleaned up.

Signed-off-by: Jason Zaman <jason@perfinion.com>
---
 .circleci/config.yml | 41 -----------------------------------------
 1 file changed, 41 deletions(-)
 delete mode 100644 .circleci/config.yml

diff --git a/.circleci/config.yml b/.circleci/config.yml
deleted file mode 100644
index a75d34c2..00000000
--- a/.circleci/config.yml
+++ /dev/null
@@ -1,41 +0,0 @@
-# Configuration file for https://circleci.com/
-
-version: 2
-
-jobs:
-  build:
-    docker:
-      # Use a Python image from https://hub.docker.com/r/circleci/python/tags/
-      - image: circleci/python:3.6
-
-    steps:
-    - checkout
-
-    # Install dependencies
-    - run: sudo apt-get update -qq
-    - run: sudo apt-get install -qq bison clang clang-tools flex gawk gettext libaudit-dev libcap-dev libcap-ng-dev libcunit1-dev libdbus-glib-1-dev libpcre2-dev python3-dev python-dev ruby-dev swig xmlto
-
-    - run:
-        name: Setup environment variables
-        command: |
-          echo 'export DESTDIR=$HOME/destdir' >> "$BASH_ENV"
-          echo 'export IS_CIRCLE_CI=1' >> "$BASH_ENV"
-
-    # Download and install refpolicy headers for sepolgen tests
-    - run:
-        name: Download refpolicy Makefile
-        command: |
-          curl --location --retry 10 -o refpolicy.tar.bz2 https://github.com/SELinuxProject/refpolicy/releases/download/RELEASE_2_20180701/refpolicy-2.20180701.tar.bz2
-          tar -xvjf refpolicy.tar.bz2
-          sed -e "s,^PREFIX :=.*,PREFIX := $DESTDIR/usr," -i refpolicy/support/Makefile.devel
-          sudo make -C refpolicy install-headers
-          sudo mkdir -p /etc/selinux
-          echo 'SELINUXTYPE=refpolicy' | sudo tee /etc/selinux/config
-          echo 'SELINUX_DEVEL_PATH = /usr/share/selinux/refpolicy' | sudo tee /etc/selinux/sepolgen.conf
-          sed -e "s,\"\(/usr/bin/[cs]\),\"$DESTDIR\1," -i python/sepolgen/src/sepolgen/module.py
-
-    # Run clang's scan-build and store the result as artifacts
-    - run: ./scripts/run-scan-build
-    - store_artifacts:
-        path: scripts/output-scan-build
-        destination: output-scan-build
-- 
2.54.0

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

[Jason Zaman]

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.

Signed-off-by: Jason Zaman <jason@perfinion.com>
---
 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, omosnace@redhat.com
 
+If unsure about whether an issue is in kernel or userspace, feel free to send
+to any and the maintainers will handle it internally.
+
 ### 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

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

[Stephen Smalley]

On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> 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 <jason@perfinion.com>
> ---
>  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, omosnace@redhat.com
>
> +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
>
>

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Stephen Smalley]

On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
>
> Part of the annual cleanup of security contacts, drop people that are
> not as active committers currently. Thanks for all the work over the
> years!
>
> Signed-off-by: Jason Zaman <jason@perfinion.com>

Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

> ---
>  SECURITY.md | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/SECURITY.md b/SECURITY.md
> index a1d02c4d..49c40e97 100644
> --- a/SECURITY.md
> +++ b/SECURITY.md
> @@ -25,10 +25,6 @@ the issue before it is made public, but we will make every effort to address
>  the issue as quickly as possible and shorten the disclosure window.
>
>  * Petr Lautrbach, plautrba@redhat.com
> -* Nicolas Iooss, nicolas.iooss@m4x.org
> -  *  (GPG fingerprint) E25E 254C 8EE4 D303 554B  F5AF EC70 1A1D A494 C5EB
> -* Jeffrey Vander Stoep, jeffv@google.com
> -* Joshua Brindle, brindle@gmail.com
>  * James Carter, jwcart2@gmail.com
>    *  (GPG fingerprint) 4568 1128 449B 65F8 80C6  1797 3A84 A946 B4BA 62AE
>  * Paul Moore, paul@paul-moore.com
> @@ -37,7 +33,6 @@ the issue as quickly as possible and shorten the disclosure window.
>    *  (GPG fingerprint) 578C 4211 832F 0A7E A2C5  A7C2 21A4 6E60 3F74 4ECF
>  * Jason Zaman, perfinion@gentoo.org
>    *  (GPG fingerprint) 6319 1CE9 4183 0986 89CA  B8DB 7EF1 37EC 935B 0EAF
> -* Steve Lawrence, slawrence@tresys.com
>  * Ondrej Mosnacek, omosnace@redhat.com
>
>  ### Resolving Sensitive Security Issues
> --
> 2.54.0
>
>

Re: [PATCH 2/3] ci: Drop circleci config

[Stephen Smalley]

On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> wrote:
>
> We have not used circleci in many years, the configs are very out of
> date compared to the github actions so need to get cleaned up.
>
> Signed-off-by: Jason Zaman <jason@perfinion.com>

Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

> ---
>  .circleci/config.yml | 41 -----------------------------------------
>  1 file changed, 41 deletions(-)
>  delete mode 100644 .circleci/config.yml
>
> diff --git a/.circleci/config.yml b/.circleci/config.yml
> deleted file mode 100644
> index a75d34c2..00000000
> --- a/.circleci/config.yml
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -# Configuration file for https://circleci.com/
> -
> -version: 2
> -
> -jobs:
> -  build:
> -    docker:
> -      # Use a Python image from https://hub.docker.com/r/circleci/python/tags/
> -      - image: circleci/python:3.6
> -
> -    steps:
> -    - checkout
> -
> -    # Install dependencies
> -    - run: sudo apt-get update -qq
> -    - run: sudo apt-get install -qq bison clang clang-tools flex gawk gettext libaudit-dev libcap-dev libcap-ng-dev libcunit1-dev libdbus-glib-1-dev libpcre2-dev python3-dev python-dev ruby-dev swig xmlto
> -
> -    - run:
> -        name: Setup environment variables
> -        command: |
> -          echo 'export DESTDIR=$HOME/destdir' >> "$BASH_ENV"
> -          echo 'export IS_CIRCLE_CI=1' >> "$BASH_ENV"
> -
> -    # Download and install refpolicy headers for sepolgen tests
> -    - run:
> -        name: Download refpolicy Makefile
> -        command: |
> -          curl --location --retry 10 -o refpolicy.tar.bz2 https://github.com/SELinuxProject/refpolicy/releases/download/RELEASE_2_20180701/refpolicy-2.20180701.tar.bz2
> -          tar -xvjf refpolicy.tar.bz2
> -          sed -e "s,^PREFIX :=.*,PREFIX := $DESTDIR/usr," -i refpolicy/support/Makefile.devel
> -          sudo make -C refpolicy install-headers
> -          sudo mkdir -p /etc/selinux
> -          echo 'SELINUXTYPE=refpolicy' | sudo tee /etc/selinux/config
> -          echo 'SELINUX_DEVEL_PATH = /usr/share/selinux/refpolicy' | sudo tee /etc/selinux/sepolgen.conf
> -          sed -e "s,\"\(/usr/bin/[cs]\),\"$DESTDIR\1," -i python/sepolgen/src/sepolgen/module.py
> -
> -    # Run clang's scan-build and store the result as artifacts
> -    - run: ./scripts/run-scan-build
> -    - store_artifacts:
> -        path: scripts/output-scan-build
> -        destination: output-scan-build
> --
> 2.54.0
>
>

Re: [PATCH 2/3] ci: Drop circleci config

[Paul Moore]

On Thu, Jul 23, 2026 at 9:48 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> wrote:
> >
> > We have not used circleci in many years, the configs are very out of
> > date compared to the github actions so need to get cleaned up.
> >
> > Signed-off-by: Jason Zaman <jason@perfinion.com>
>
> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

Reviewed-by: Paul Moore <paul@paul-moore.com>

-- 
paul-moore.com

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Paul Moore]

On Thu, Jul 23, 2026 at 9:42 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
> >
> > Part of the annual cleanup of security contacts, drop people that are
> > not as active committers currently. Thanks for all the work over the
> > years!
> >
> > Signed-off-by: Jason Zaman <jason@perfinion.com>
>
> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>

Reviewed-by: Paul Moore <paul@paul-moore.com>

-- 
paul-moore.com

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Thiébaud Weksteen]

On Fri, Jul 24, 2026 at 3:41 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jul 23, 2026 at 9:42 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
> > >
> > > Part of the annual cleanup of security contacts, drop people that are
> > > not as active committers currently. Thanks for all the work over the
> > > years!
> > >
> > > Signed-off-by: Jason Zaman <jason@perfinion.com>
> >
> > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>
> Reviewed-by: Paul Moore <paul@paul-moore.com>
>

It would be great if Android could still be included here. I'd like to
propose myself for inclusion, if that's possible. Thanks.

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Paul Moore]

On Thu, Jul 23, 2026 at 8:24 PM Thiébaud Weksteen <tweek@google.com> wrote:
> On Fri, Jul 24, 2026 at 3:41 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Jul 23, 2026 at 9:42 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
> > > >
> > > > Part of the annual cleanup of security contacts, drop people that are
> > > > not as active committers currently. Thanks for all the work over the
> > > > years!
> > > >
> > > > Signed-off-by: Jason Zaman <jason@perfinion.com>
> > >
> > > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> >
> > Reviewed-by: Paul Moore <paul@paul-moore.com>
>
> It would be great if Android could still be included here. I'd like to
> propose myself for inclusion, if that's possible. Thanks.

I believe the goal was to limit the number of people who receive
vulnerability reports to active maintainers.  Unfortunately, none of
the Google/Android folks currently listed are active contributors
which is why I believe the patch removes them (and others) from the
contact list.  Like almost all Open Source projects, the best way to
stay informed of these things is to establish yourself as an active
contributor over a period of time.  I can't speak to how the userspace
maintainers view your activity thus far, however, from my perspective
you have made some nice contributions but only over a limited period
of time.  I would like to see you demonstrate a continued involvement
over a longer period (historically this has been an issue for Google
contributors).

I also know there has been some discussion regarding notifying distros
prior to a wider, public security advisory release, although I'm not
certain of the current status of that idea.

--
paul-moore.com

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Thiébaud Weksteen]

On Fri, Jul 24, 2026 at 12:27 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jul 23, 2026 at 8:24 PM Thiébaud Weksteen <tweek@google.com> wrote:
> > On Fri, Jul 24, 2026 at 3:41 AM Paul Moore <paul@paul-moore.com> wrote:
> > > On Thu, Jul 23, 2026 at 9:42 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
> > > > >
> > > > > Part of the annual cleanup of security contacts, drop people that are
> > > > > not as active committers currently. Thanks for all the work over the
> > > > > years!
> > > > >
> > > > > Signed-off-by: Jason Zaman <jason@perfinion.com>
> > > >
> > > > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > >
> > > Reviewed-by: Paul Moore <paul@paul-moore.com>
> >
> > It would be great if Android could still be included here. I'd like to
> > propose myself for inclusion, if that's possible. Thanks.
>
> I believe the goal was to limit the number of people who receive
> vulnerability reports to active maintainers.  Unfortunately, none of
> the Google/Android folks currently listed are active contributors
> which is why I believe the patch removes them (and others) from the
> contact list.  Like almost all Open Source projects, the best way to
> stay informed of these things is to establish yourself as an active
> contributor over a period of time.  I can't speak to how the userspace
> maintainers view your activity thus far, however, from my perspective
> you have made some nice contributions but only over a limited period
> of time.  I would like to see you demonstrate a continued involvement
> over a longer period (historically this has been an issue for Google
> contributors).

No worries, that makes sense. Thanks for the honest feedback Paul.

Re: [PATCH 1/3] SECURITY.md: Update security contacts

[Stephen Smalley]

On Thu, Jul 23, 2026 at 1:37 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jul 23, 2026 at 9:42 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Thu, Jul 23, 2026 at 2:24 AM Jason Zaman <jason@perfinion.com> wrote:
> > >
> > > Part of the annual cleanup of security contacts, drop people that are
> > > not as active committers currently. Thanks for all the work over the
> > > years!
> > >
> > > Signed-off-by: Jason Zaman <jason@perfinion.com>
> >
> > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>
> Reviewed-by: Paul Moore <paul@paul-moore.com>

I re-based this on top of Nicolas' patch removing himself and merged
the first two,
leaving the third one (the RFC PATCH) for another spin based on feedback.

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

[Stephen Smalley]

On Thu, Jul 23, 2026 at 9:30 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> 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 <jason@perfinion.com>
> > ---
> >  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, omosnace@redhat.com
> >
> > +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

We may also want to add something like the following to SECURITY.md:
Bugs in libsepol that only affect policy compilers (checkpolicy,
checkmodule, secilc) are not considered
security vulnerabilities. The policy compilers are typically run
without any privileges and attackers who
can feed them arbitrary inputs can do more interesting things. We will
fix such bugs but will not create
security advisories for them.

>
> > +
> >  ### 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
> >
> >

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

[Stephen Smalley]

On Wed, Jul 29, 2026 at 8:45 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Jul 23, 2026 at 9:30 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> wrote:
> > > +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
>
> We may also want to add something like the following to SECURITY.md:
> Bugs in libsepol that only affect policy compilers (checkpolicy,
> checkmodule, secilc) are not considered

I would also add the semodule-utils (semodule_expand/link/package) as
well to the list above.

> security vulnerabilities. The policy compilers are typically run
> without any privileges and attackers who
> can feed them arbitrary inputs can do more interesting things. We will
> fix such bugs but will not create
> security advisories for them.

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

[Johannes Segitz]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Wed, Jul 29, 2026 at 09:06:39AM -0400, Stephen Smalley wrote:
> On Wed, Jul 29, 2026 at 8:45 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, Jul 23, 2026 at 9:30 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <jason@perfinion.com> wrote:
> > > > +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
> >
> > We may also want to add something like the following to SECURITY.md:
> > Bugs in libsepol that only affect policy compilers (checkpolicy,
> > checkmodule, secilc) are not considered
> 
> I would also add the semodule-utils (semodule_expand/link/package) as
> well to the list above.

Maybe don't list any components, but just state that issues that require an
attacker controlled policy source are bugs, but not security issues

Johannes
-- 
GPG Key                EE16 6BCE AD56 E034 BFB3  3ADD 7BF7 29D5 E7C8 1FA0
Subkey fingerprint:    250F 43F5 F7CE 6F1E 9C59  4F95 BC27 DD9D 2CC4 FD66
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany
www.suse.com, Geschäftsführer: Jochen Jaser, Andrew McDonald, Abhinav Puri, (HRB 36809, AG Nürnberg)


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 870 bytes --]