RFC: GitLab issues for security disclosures

["Daniel P. Berrangé" <berrange@redhat.com>]

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

In all three cases, if a GitLab issue is determined to be security
relevant, any maintainer could send a request to qemu-security list
to get Red Hat product security to allocate a CVE.

Out of those I'd probably lean towards (2) which is slightly
more restrictive than the kernel new policy but not by much.

Some key benefits of using GitLab for security disclosures

 * We can trivially make disclosures public if we classify them
   as a non-virtualization use case, or when the fix is ready.

 * We can formally track the lifecycle of disclosures through to
   the final fix, for both virtualization & non-virtualization
   use cases. The only difference will be that the former can
   request a CVE assignment

 * We can do reports/queries of outstanding issues
 
 * We can more easily use automation to process issues

 * Maintainers can see bugs without waiting for someone to triage
   and forward it on their way.

 * The small number of security bug triage people are no a bottle
   neck anymore

Some downsides/implications

 * Every disclosure in a confidential issue will be visible to every
   maintainer who has joined the qemu-project repo on GitLab. IOW
   that is treating every maintainer as equally trusted.

   We do have qemu-security though we could be mailed if someone
   considered their disclosure to be severely impactful but the triage
   team can't make that decision.

 * We must NOT grant membership to qemu-project at a Reporter level
   for anyone whom is not an active maintainer. They must be limited
   to the "Guest" role at most.

 * No one is formally responsible for GitLab issue triage. We have
   had Thomas do it in the past periodically with script assistance.
   We have Alex doing some of it now with bot assistance. The danger
   is security disclosures get ignored as "somebody else's problem"
   no one has accountability.

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 :|