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. 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
