On Wed, May 20, 2026 at 06:39:14PM +0100, Daniel P. Berrangé wrote: > 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 :|
something I was unaware of previously, is that gitlab is a CNA: https://about.gitlab.com/security/cve/ so using gitlab issues means assigning CVE #s should be super easy. -- MST
