Re: RFC: GitLab issues for security disclosures

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, May 19, 2026 at 03:26:51PM +0100, 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.
> 
> 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

or 4. do it like linux did, and move ai assisted disclosured
to the public ML. Fuzzer assisted can stay with human discovered.


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