From: "Mickaël Salaün" <mic@digikod.net>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org
Subject: Re: ANN: new LSM guidelines
Date: Thu, 3 Aug 2023 11:44:21 +0200 [thread overview]
Message-ID: <20230803.alohoMev7thu@digikod.net> (raw)
In-Reply-To: <CAHC9VhQhf+ik5S_aJOVn59pax1Aa0vO5gJ4YoxrtGRKtoWh7sA@mail.gmail.com>
On Wed, Aug 02, 2023 at 06:00:22PM -0400, Paul Moore wrote:
> On Tue, Aug 1, 2023 at 6:47 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > I've updated the README.md doc based on the feedback, and copied the
> > two new sections below for easier review. If anyone has any
> > additional feedback or concerns, please let me know.
>
> Another update based on feedback received (thanks everyone!). Just as
> before, I welcome any comments or feedback you are able to share.
>
> ## New LSM Hook Guidelines
>
> While LSM hooks are considered outside of the Linux Kernel's stable API
s/Kernel/kernel/g
[...]
> * New LSMs must be accompanied by a test suite to verify basic functionality
> and help identify regressions. Test coverage does not need to reach a specific
> percentage, but core functionality and any user interfaces should be well
> covered by the test suite. Integration with existing automated Linux Kernel
> testing services is encouraged.
I'd suggest to require tests to be publicly available and easy (or not
too difficult) to run for the sake of sanity of other kernel developers
that might need to quickly fix (critical) bugs even without the help of
the maintainer (who might be unavailable for various reasons). I guess
you could argue that decent kernel code needs a reasonable bus factor
protection, but making tests available and easy to use is a quality
guarantee.
next prev parent reply other threads:[~2023-08-03 9:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 20:42 ANN: new LSM guidelines Paul Moore
2023-07-07 0:32 ` Casey Schaufler
2023-07-07 22:02 ` Paul Moore
2023-08-01 22:47 ` Paul Moore
2023-08-02 18:38 ` Mickaël Salaün
2023-08-02 21:56 ` Paul Moore
2023-08-02 22:36 ` Randy Dunlap
2023-08-03 20:55 ` Paul Moore
2023-08-03 9:44 ` Mickaël Salaün
2023-08-03 21:36 ` Paul Moore
2023-08-02 22:00 ` Paul Moore
2023-08-03 9:44 ` Mickaël Salaün [this message]
2023-08-03 21:24 ` Paul Moore
2023-08-03 21:38 ` Paul Moore
2023-08-04 7:58 ` Mickaël Salaün
2023-08-07 21:52 ` Paul Moore
2023-09-07 22:12 ` Paul Moore
2023-09-08 16:02 ` Casey Schaufler
2023-09-08 17:29 ` Paul Moore
2023-09-08 20:53 ` Casey Schaufler
2023-09-09 0:46 ` Tetsuo Handa
2023-09-11 13:03 ` Serge E. Hallyn
2023-09-11 20:04 ` Paul Moore
2023-09-12 1:29 ` Tetsuo Handa
2023-09-12 18:08 ` Paul Moore
2023-09-12 18:39 ` Casey Schaufler
2023-09-12 19:00 ` Paul Moore
2023-09-12 19:03 ` Paul Moore
2023-09-25 0:55 ` Tetsuo Handa
2023-09-25 1:32 ` Kees Cook
2023-09-25 4:32 ` Tetsuo Handa
2023-09-26 21:23 ` Paul Moore
2023-09-15 11:29 ` Tetsuo Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230803.alohoMev7thu@digikod.net \
--to=mic@digikod.net \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.