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

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

On Mon, Jun 08, 2026 at 02:39:06PM +0100, Peter Maydell wrote:
> On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <berrange@redhat.com> 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>
> 
> Since I'm not directly involved with the security process, I
> don't have a strong view here and I trust your judgement that
> this is going to work better. I have a couple of minor
> suggestions below.
> 
> > +## How to disclosure a potential issues
> 
> "How to disclose potential issues"
> 
> > +
> > +**The QEMU project no longer accepts security issue disclosures via email.**
> > +
> > +New disclosures must follow the [report a bug](report-a-bug.html)
> > +process to file a GitLab work item for each potential issue, ***marking
> > +it as "*confidential*" prior to submission.***
> > +
> > +If unsure of the security implications of an issue, err on the side
> > +of caution and mark it as "*confidential*" initially.
> 
> "err on the side of caution" doesn't seem to me to interact
> very well with "we get a ton of not very well filtered AI reports".
> I think we should probably emphasise here that we expect the
> submitter to read our description of the virtualization vs
> non-virtualization use cases and not report bugs that clearly
> don't fall under the virtualization case as confidential.


Sadly it seems that only maintainers of specific piece of code
really know if it's non-virtualization use case.

E.g. nvme emulation is non virtualization, I find out.
Wouldn't have guessed.

> At the moment the text below says that it's the people on the
> receiving end that do that as part of triage.
> 
> The old text started up-front with:
> 
> -Note that not all areas of QEMU are considered to provide a security
> -boundary. Consult the guidance [...]
> 
> "People who send us bad security reports" and "people who don't
> read the documentation about our security process and policy"
> probably has a strong overlap, but I think it's still worth
> making sure we have the emphasis pretty strongly on "you as
> the submitter are expected to not report things we're going to
> instantly triage out as not-security-bugs".
> 
> > +## Triage process
> > +
> > + * A maintainer will evaluate the circumstances of the issue
> > +   to determine if it can be misused for malicious purposes.
> > +
> > + * If there is no potential for meaningful exploit, the disclosure
> > +   should be switched to the public bug report process by removing
> > +   the "*confidential*" marker.
> > +
> > + * If confirmed as a security flaw, a maintainer will request
> 
> "request" seems a stray word here ?
> 
> > +   add the **"cve::required"** GitLab label to the GitLab work item,
> > +   which indicates the need for a CNA to allocate a CVE.
> 
> thanks
> -- PMM