On Thu, Jun 18, 2026 at 04:07:44PM +0200, Philippe Mathieu-Daudé wrote: > On 18/6/26 15:20, 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é <[email protected]> > > --- > > contribute/report-a-bug.md | 9 +- > > contribute/security-process.md | 309 +++++++++++++++------------------ > > 2 files changed, 148 insertions(+), 170 deletions(-) > > > > +**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 issue (work item) for each potential issue, > > +***marking it as "*confidential*" prior to submission.*** > > + > > +Some important notes when disclosing potential security issues: > > + > > +* The QEMU project cannot provide an SLA for response to security > > + disclosures, or any bug reports in general. Issues will be > > + responded to at the discretion of maintainers, subject to their > > + available time. > > + > > +* Attachments added to GitLab *confidential* issues are not themselves > > + confidential. If someone knows the randomly generated URL for the > > + attachment, they can view the content. Thus be careful where attachment > > + URLs are shared, while the issue remains confidential. > > + > > +* All disclosures will eventually be made public. Thus the content > > + or attachments for any issue must not contain data that the reporter > > + considers to be sensitive / private. > > + > > +* Not all areas of QEMU are considered to provide a security > > + boundary. Consult the [security > > guide](https://www.qemu.org/docs/master/system/security.html) > > + for details on how QEMU classifies features. > > + > > +* If an issue affects a feature within the QEMU security boundary, > > + but the reporter is unsure of the security implications, err on > > + the side of caution and mark it as "*confidential*" initially. > > + > > +* All important information must be disclosed in the issue description, > > + minimizing use of attachments to what is strictly needed. There is > > + a strong preference for individual files to be attached directly. > > + Avoid the use of archives (zip, tar, 7z, etc) to bundle files where > > + practical. > > Except this bullet point, everything LGTM. Here I'd enforce reporters to > attach a reproducer (in command line form, with image attached, pointing > to requiered public images to trigger the issue).
FWIW, I don't think we're going to have a significant problem of insufficient info with current disclosure practices. We've not required this historically but none the less most of the AI assisted disclosures have contained more than enough information to easily reproduce the issues. Either clearly describing the steps in the issue description, or shell/python scripts or qtests to exercise it. Out of ~300 disclosures this year, only a couple have needed a disk image to demonstrate and those were stll trivial. Also note that elsewhere in the file I also explicitly note that the reporter must personally acknowledge that they reproduced the problem, so they should be validating the instructions the AI spat out. > If not provided, personally as a maintainer I'd like -- or let scripts -- > the ability to discard the *confidential* tag to issue with no > reproducer attached, as I don't want to waste time guessing / poking > around, possibly realizing the issue is not reachable. I very much doubt this is going to be a significant problem for any confidential issues we get. The doc is biased towards prompt disclosure though, with the maintainer having the discretion to decide when to do that now. Even if it is a valid security issue a maintainer can decide it should be made public without waiting for a patch if low severity. We don't want issues to remain confidential for more than $SMALL number of days. > Otherwise, > Reviewed-by: Philippe Mathieu-Daudé <[email protected]> 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 :|
