On Tue, May 19, 2026 at 05:11:23PM +0100, Daniel P. Berrangé wrote: > On Tue, May 19, 2026 at 11:18:31AM -0400, Michael S. Tsirkin wrote: > > On Tue, May 19, 2026 at 03:26:51PM +0100, Daniel P. Berrangé wrote: > > > The qemu-security mailing list was created several years back now and > > > traditionally saw 1-2 disclosures a month at worst. This was manageable. > > > > > > Since approx March 1st, the new normal is to see as many as 20 disclosures > > > in one single day, more than 200 in total now. This is unsustainable. > > > I was thinking we needed more people on qemu-security to triage, but IMHO > > > this won't really fix the problem. > > > > > > This needs an issue tracker to cope with & email is not an issue tracker. > > > We faked an issue tracker with a shared spreadsheet to prevent us drowning > > > these past few months, but this is still not sustainable & probably won't > > > ever be. > > > > > > The traditional POV was that security disclosures must be dealt with on > > > a strict "need to know" basis until there was a concious decision to make > > > them public. Typically that happened when a patch was published by the > > > maintainer on qemu-devel. Rarely have we applied an embargo period after > > > a maintainer had a patch ready to post, as most bugs were not severe > > > enough. Also in typical usage Libvirt has SELinux/AppArmour to mitigate > > > impact of a guest ecsape into QEMU. > > > > > > QEMU is not alone in this chaos, to quote Linus > > > > > > https://lkml.org/lkml/2026/5/17/896 > > > > > > [quote] > > > the continued flood of AI reports has basically made the security list > > > almost entirely unmanageable, with enormous duplication due to > > > different people finding the same things with the same tools. People > > > spend all their time just forwarding things to the right people or > > > saying "that was already fixed a week/month ago" and pointing to the > > > public discussion. > > > [/quote] > > > > > > They have explicitly changed their policy for disclosure now: > > > > > > > > > https://github.com/torvalds/linux/commit/a03ef333fbd6cd861c8457c3d055ee3643a9baad > > > > > > [quote] > > > If you resorted to AI assistance to identify a bug, you must treat > > > it as public. While you may have valid reasons to believe it is not, > > > the security team's experience shows that bugs discovered this way > > > systematically surface simultaneously across multiple researchers, > > > often on the same day > > > [/quote] > > > > > > IME for qemu-security we've definitely seen the same bugs reported by > > > different people, within days of each other, a couple of times even > > > the same day. Dupes are not the majority - QEMU has so much low > > > hanging fruit - but they're a sizeable chunk. > > > > > > > > > Because we don't have a good automated way to publish disclosures > > > from qemu-security, we don't provide contributors any way to check > > > for duplicates before submission. The burden of checking for dupes > > > thus falls on the qemu-security triage people, or the maintainers > > > we forward issues to. > > > > > > For disclosures in the non-virtualization use case, we ask the > > > reporter to file a gitlab issue or send a patch. They almost never > > > do this. We're lucky to have any reply to emails at all. > > > > > > > > > IMHO we need to move to an issue tracker. GitLab was originally > > > discounted in favour of qemu-security list since "Confidential" > > > issues cannot have visibility managed in a fine grained way. > > > They are visible to everyone with "Reporter" role or higher, > > > which is 70+ people for QEMU. > > > > > > If we accept the kernel's view that AI discovered issues should be > > > considered public immediately because of the high chance of parallel > > > "discovery", then GitLab's limitations don't seem to bad. > > > > > > It is also of note that we've had some people ignoring qemu-security > > > policy and directly filing public gitlab issues for stuff discovered > > > via AI/LLM agents already. Those are not getting attention for CVE > > > assignment, should it be needed which and can't be cross-referenced > > > by general maintaniers to stuff we have received via qemu-security. > > > > > > We have some options IMHO > > > > > > 1. Move all security disclosure to GitLab confidential issues > > > no disclosures via email > > > > > > 2. Move AI/fuzzer assisted disclosures to GitLab confidential > > > issues, keep human discovered issues on qemu-security list > > > > > > 3. Move AI/fuzzer assisted disclosures to GitLab public > > > issues, keep human discovered issues on qemu-security list > > > > or 4. do it like linux did, and move ai assisted disclosured > > to the public ML. Fuzzer assisted can stay with human discovered. > > Linux could do that because of the way they issue CVEs. IIUC, every > bug that goes into stable kernels gets evaluated for whether a CVE > is required. Thus they don't need to do CVE allocation in alignment > with any bug disclosure process. > > While our stable branch process for QEMU is healthier than it has > ever been, it is still essentially a 1 person effort looking for > candidate patches, not a strong enough culture of maintainers > sending patches to stable proactively. So I don't think we're > in a position to replicate Linux's approach to CVE assignment. > > So IMHO we still need to have some issue tracking mechanism to > tag incoming disclosures as needing CVE assignment or not. If > all disclosures end up on qemu-devel and untracked we'll just > never end up getting CVEs for most of them. That doesn't feel > like a viable approach > > > 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 :|
Oh I certainly do not object to that! can be public gitlab+public ML. -- MST
