From: Greg KH <greg@kroah.com>
To: Mark Brown <broonie@kernel.org>
Cc: Dave Hansen <dave@sr71.net>, Sasha Levin <sashal@kernel.org>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Quality standards for embargoed code
Date: Tue, 15 Aug 2023 23:11:01 +0200 [thread overview]
Message-ID: <2023081527-amendment-professed-0a42@gregkh> (raw)
In-Reply-To: <f7b680ae-915b-4783-a177-117553356df6@sirena.org.uk>
On Tue, Aug 15, 2023 at 09:47:43PM +0100, Mark Brown wrote:
> On Tue, Aug 15, 2023 at 09:57:46PM +0200, Greg KH wrote:
>
> > Anyway, the main reason we have NOT added testers (nor allowed
> > developers to use the test systems from their employer) is that those
> > test systems are able to be accessed by a huge/unknown number of other
> > people, none of who should have access to the potential changes under
> > development.
>
> > If that can be solved, with a "private" kernelci/lkft/openssf/whatever
> > test instance, that would be wonderful. Ideally it should be the
> > responsibility of the hardware vendor for which we are fixing their
> > broken hardware with kernel changes to provide this for us.
>
> I think we could usefully have such systems or scripts available which
> people could use at their option as part of setting the baseline,
> ideally something based on free software so people can stand the stack
> up themselves if they want. Probably there will be occasions when it
> gets used, if only by upstream people, and it's less stop energy to
> point people at something they can concretely use rather than a list of
> tests which people might not already know how to run. If it's just a
> list of requirements there's more chance people might mess up running in
> ways that non-obviously don't actually test the thing.
I would _love_ a "stand this stack up myself" type of thing to have,
just that alone might solve most of this issue by allowing the
developers doing this work to "do it themselves" before even offering
the change up to the small group for review.
So consider me someone who would gladly consume this type of thing not
only for hw-embargoed issues, or for "normal" security issues, but also
for my normal development/maintainer workflow as really, they all have
the same need here.
thanks,
greg k-h
prev parent reply other threads:[~2023-08-15 21:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 16:58 [MAINTAINERS SUMMIT] Quality standards for embargoed code Sasha Levin
2023-08-15 17:18 ` Mark Brown
2023-08-15 18:10 ` Sasha Levin
2023-08-15 18:40 ` Mark Brown
2023-08-15 17:19 ` Dave Hansen
2023-08-15 18:19 ` Sasha Levin
2023-08-15 18:34 ` Dave Hansen
2023-08-15 19:57 ` Greg KH
2023-08-15 20:47 ` Mark Brown
2023-08-15 21:11 ` Greg KH [this message]
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=2023081527-amendment-professed-0a42@gregkh \
--to=greg@kroah.com \
--cc=broonie@kernel.org \
--cc=dave@sr71.net \
--cc=ksummit@lists.linux.dev \
--cc=sashal@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).