On Wed, May 20, 2026 at 07:14:41PM -0400, Michael S. Tsirkin wrote: > 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. > > 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.
That's interesting, but I'm not sure it is a match for what we want in practice if you see their process & timeframes... "We will acknowledge receipt of CVE requests the next business day and strive to send regular updates about our progress. Our goal is to determine if the vulnerability is valid and communicate back to the submitter within 30 business days." We don't really need someone to spend time on additional analysis, as we'll already know the bug is valid at this point and just need a CVE assignment, ideally the same day. 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 :|
