From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Mauro Matteo Cascella" <mcascell@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Thomas Huth" <thuth@redhat.com>
Subject: Re: RFC: GitLab issues for security disclosures
Date: Wed, 20 May 2026 16:09:22 +0100 [thread overview]
Message-ID: <ag3OopKwGVUjSrrV@redhat.com> (raw)
In-Reply-To: <c9cd8228-0a18-49f7-b403-445affeaf972@oss.qualcomm.com>
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.
> > 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%.
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 :|
next prev parent reply other threads:[~2026-05-20 15:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 14:26 RFC: GitLab issues for security disclosures Daniel P. Berrangé
2026-05-19 15:18 ` Michael S. Tsirkin
2026-05-19 16:11 ` Daniel P. Berrangé
2026-05-19 16:19 ` Michael S. Tsirkin
2026-05-20 10:25 ` Mauro Matteo Cascella
2026-05-20 15:01 ` Pierrick Bouvier
2026-05-20 15:09 ` Daniel P. Berrangé [this message]
2026-05-20 17:33 ` Pierrick Bouvier
2026-05-20 17:39 ` Daniel P. Berrangé
2026-05-20 18:28 ` Warner Losh
2026-05-20 23:14 ` Michael S. Tsirkin
2026-05-21 9:06 ` Daniel P. Berrangé
2026-05-21 12:45 ` Mauro Matteo Cascella
2026-05-21 13:06 ` Daniel P. Berrangé
2026-05-21 13:17 ` Mauro Matteo Cascella
2026-05-21 11:09 ` Alex Bennée
2026-05-21 11:21 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ag3OopKwGVUjSrrV@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=mcascell@redhat.com \
--cc=mst@redhat.com \
--cc=pierrick.bouvier@oss.qualcomm.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.