On Wed, May 20, 2026 at 12:33:16PM -0500, Pierrick Bouvier wrote: > On 5/20/2026 10:09 AM, Daniel P. Berrangé wrote: > > On Wed, May 20, 2026 at 10:01:14AM -0500, Pierrick Bouvier wrote: > >> Hi Daniel, > >> > >> On 5/19/2026 9:26 AM, 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. > >>> > >> > >> Considering the increase in number of issues, would that be possible to > >> make stricter rules about what is expected? > >> > >> For instance, asking for a working exploit and optionally a VM image + > >> instructions to reproduce it. I am not expert on the topic, but what I > >> see is that if we have this, all duplicates would be eliminated at once. > > > > With the new crop of AI assisted disclosures there is absolutely no > > lack of data provided. > > > > Most come with reproducible exploits, detailed descriptions and analysis, > > and more - everything you could conceivably need to triage the disclosure. > > Reading and interpreting this takes significant mental effort and there's > > too much data to quickly/easily eliminate dupes. > > > > Maybe we need to "standardize" this part then. > Or do something like asking a (GitLab) CI pipeline to be written to > expose the issue. If we can just run this with a specific qemu > remote/branch, it becomes trivial to rerun it when fixes are pushed. > > It definitely does not solve the original scaling issue, but maybe can > help to absorb it, and spend time where it's useful: writing and > upstreaming a fix, and check it "broke" the exploit. > > >>> 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. > >>> > >> > >> Overall, you're right. > >> However, changing the tool won't solve the number of issues sent, and > >> for that, something additional is needed. > > > > I don't expect there to be any change in submission rate. The proposal > > is based on the expectation that the submission rate will continue at > > a high level for a long time. Primarily the goal is to reduce the > > tracking and triage work overhead and to eliminate/reduce single person > > bottlenecks in the process > > > >> I wonder also what is the percentage of duplicates there is from what > >> you observed in the last 2 months. Any rough idea of the number? > > > > Definitely at least 10%, probably closer to 15%. > > > > Ok, interesting number, thanks. I was expecting much more, but I'm > biased having heard Linus this morning talk about this for Linux kernel.
I expect the dupes to increase over time as more people run the same analysis across QEMU, especially given that most of the bugs are not yet fixed. 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 :|
