Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 10, 2026 at 12:10:04PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 10, 2026 at 07:06:38AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jun 10, 2026 at 12:02:43PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> > > > > It is no longer viable to handle the incredible volumes of
> > > > > AI assisted security disclosures via email, nor are extended
> > > > > embargos practical or useful.
> > > > > 
> > > > > Remove all information about the current security process and
> > > > > instruct reporters to use 'confidential' issues. In contrast
> > > > > to the old highly restrictive "need to know" approach, the
> > > > > new approach makes all security issues visible to all QEMU
> > > > > maintainers immediately.
> > > > > 
> > > > > The focus is on making issues public as soon as possible with
> > > > > a viable patch. Co-ordinated disclosure will no longer be
> > > > > attempted and nor will requests to embargoes be accepted.
> > > > > 
> > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > > > ---
> > > > >  contribute/report-a-bug.md     |   9 +-
> > > > >  contribute/security-process.md | 280 ++++++++++++++-------------------
> > > > >  2 files changed, 119 insertions(+), 170 deletions(-)
> > > > > 
> > > > > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> > > > > index fd3bc6b..b506f9f 100644
> > > > > --- a/contribute/report-a-bug.md
> > > > > +++ b/contribute/report-a-bug.md
> > > > > @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
> > > > >    requested pieces of information that are relevant to the
> > > > >    discovered bug.
> > > > >  
> > > > > +* Bugs which are suspected, or known, to have security implications
> > > > > +  **must** be marked as "*confidential*" prior to submitting the
> > > > > +  disclosure. Consult the [security process](../security-process)
> > > > > +  for further guidance on security issue handling.
> > > > > +
> > > > 
> > > > Do we want to do like linux does, and make AI found issues public,
> > > > on the assumption that bad guys can find them just as easily?
> > > 
> > > I'm pretty sympathetic to the idea that AI discovered issues
> > > are "effectively public", but IMHO that's not quite the same
> > > as "actually public".
> > > 
> > > While people can re-discover things, that doesn't mean we should
> > > do the job for them by publicising everything immediately.
> > > 
> > > To me, the main implications of the "effectively public" view
> > > point are
> > > 
> > >  * Minimizing time-to-fix is the core priority
> > >  * Process needs to be low cost minimal external dependencies
> > > 
> > > Delaying disclosure to suit arbitrary downstream vendor's or user's
> > > update schedules is not helpful. The only delays to publication should
> > > be to allow a maintainer to get a patch prepared, nothing beyond that.
> > > "Low" severity bugs can be public immediately regardless of a patch.
> > > 
> > > With regards,
> > > Daniel
> > 
> > 
> > Ok so you are saying the process will be: 
> > - patch posted on public list -> maintainer makes the bug public?
> 
> Yes, I even wrote that in this patch :-)
> 
>  + * At the time the proposed patches are sent to qemu-devel, the
>  +   maintainers should remove the "*confidential*" marker from the
>  +   GitLab issue.
> 

Right, you did.

> > and if the issue is coming with a patch?
> 
> If the reporter provides a patch, the maintainer merely needs to
> review it. If happy, either the reporter or maintainer can send
> it to qemu-devel immediately.
> 
> With regards,
> Daniel

Presumably with a Fixes tag.