On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote: > On Thu, Jun 04, 2026 at 05:50:48PM +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é <[email protected]> > > --- > > contribute/report-a-bug.md | 9 +- > > contribute/security-process.md | 280 ++++++++++++++------------------- > > 2 files changed, 119 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. > > + > > Do we want to do like linux does, and make AI found issues public, > on the assumption that bad guys can find them just as easily?
I'm pretty sympathetic to the idea that AI discovered issues are "effectively public", but IMHO that's not quite the same as "actually public". While people can re-discover things, that doesn't mean we should do the job for them by publicising everything immediately. To me, the main implications of the "effectively public" view point are * Minimizing time-to-fix is the core priority * Process needs to be low cost minimal external dependencies Delaying disclosure to suit arbitrary downstream vendor's or user's update schedules is not helpful. The only delays to publication should be to allow a maintainer to get a patch prepared, nothing beyond that. "Low" severity bugs can be public immediately regardless of a patch. 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 :|
