On Mon, Jun 08, 2026 at 02:39:06PM +0100, Peter Maydell wrote: > On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <[email protected]> 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é <[email protected]> > > 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
