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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jun 18, 2026 at 10:42:15AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2026 at 02:20:58PM +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>
> 
> Thanks for taking on this. One question:
> 
> 
> > ---
> >  contribute/report-a-bug.md     |   9 +-
> >  contribute/security-process.md | 309 +++++++++++++++------------------
> >  2 files changed, 148 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.
> > +
> >  * Reproduce the problem with the latest upstream QEMU release.
> >    Reports against older versions may not be acted upon with
> >    with the same priority.
> 
> 
> There's a problem here in that confidential marking is later
> erased. I feel would is benefitial to tag the security bugs
> in some way that does not go away so easily. Any idea?

Yes, see this paragraph....

> > + * If confirmed as a security flaw, a maintainer will add the
> > +   **"Kind::Security"**, **"Workflow::Confirmed"** and
> > +   **"CVE::Required"** labels.. The latter indicates the need
> > +   for a CNA to allocate a CVE.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|