Re: [qemu-web RFC 0/3] switch to GitLab confidential issues for security disclosure

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

On Thu, Jun 04, 2026 at 05:50:45PM +0100, Daniel P. Berrangé wrote:
> I previously raised the idea of using GitLab issues for security
> disclosures:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2026-05/msg04582.html


Thanks a lot for posting this!

Do we want a special

.gitlab/issue_templates/security_bug.md

For this?

It can include guidance in a friendly way.


> This patch proposal formalizes that into a concrete proposal:
> 
>  * qemu-security is entirely discontinued
> 
>  * "confidential" GitLab issues are to be used
> 
>  * The priority is to have a low overhead process that is
>    as close to normal bug & development workflow as
>    possible.
> 
>  * No embargoes will be accepted, beyond the time needed
>    for a maintainer to develop a patch, unless extenuating
>    scenarios apply. A vendor's/user's desire to delay to
>    suit their arbitrary software upgrade schedule is NOT
>    an extenuating scenario.
> 
>  * All confidential issues will be expected to be made
>    public, either when the patch is proposed to qemu-devel,
>    or sooner if a issue is low severity and a patch is not
>    a priority for the manitainer
> 
>  * Eliminate dependency on any single maintainer/person to
>    the greatest extent practical
> 
> Some open questions
> 
>  * I describe using "cve::required" as a gitlab label to
>    track issues that need CVEs allocating. I'm unclear what
>    the best way is to actually do the allocation. This is
>    where it is hardest to eliminate the single person
>    bottleneck / burden.
> 
>    Traditionally I would email Red Hat product security via
>    Mauro (CC'd) but that's still a single point of failure.
> 
>    I'm personally not willing to sign up for QEMU to be a
>    CNA, because they have unreasonable expectations for
>    volunteer projects. I'm not going to give them my phone
>    number nor agree to any SLAs for response to query.
> 
>    From a selfish QEMU upstream maintainer POV, I would say
>    that CVEs are largely devoid of value. The people who
>    care most about them are the downstream vendors who
>    ship old QEMU versions and track bugs for backporting.
>    If we want to pull a security fix into our stable release
>    branches we can do that easily without a CVE.
> 
>    Thus one nuclear option is to say "not our problem" and
>    no longer assign CVEs at all. Instead assign a unique ID
>    of QEMU's invention "QEMU-SEC-nnnnn", and let downstream
>    vendors take the pain of allocating and mapping QEMU's
>    identifiers to CVE identifiers.
> 
>  * We have >100 disclosed issues to qemu-security
>    that were classed as non-virtualization bugs which
>    I asked the reporter to file gitlab issues for.
>    Almost no one followed up to do that. I don't want
>    these bugs to go into a black-hole as they are all
>    basically valid, but I also don't fancy bulk filing
>    100's of issues from my own account.
> 
>    There are also more non-triaged issues some of which
>    are valid security bugs which ought to be tracked
>    rather than sucked into a black-hole. Again that
>    implies more bulk filing of bugs :-(
> 
>  * Moving away from a small dedicated group of people
>    handling security reports, to a distributed
>    responsbility has a notable risk - every maintainer
>    may consider it "someone else's problem" and ignore
>    security disclosures. Some poor sucker then gets to
>    run triage across an ever increasing set of issues
>    and try to encourage maintainers into responding.
> 
>    Based on our experience with normal bug triage work,
>    I'd say it is a near certainty that this will happen
>    to some extent.
> 
>    I don't have any answer here other than even this
>    bad outcome will probably be less bad that the status
>    quo with qemu-security email disclosure. Personally
>    I can/will not continue with the email workflow any
>    more.
> 
>    IMHO this mostly points towards the downstream vendors
>    needing to invest more in QEMU if they want to have a
>    guaranteed security SLA upstream.
> 
> Daniel P. Berrangé (3):
>   contribute: reformat/restructure bug report guidance
>   contribute: add automate tool disclosure to bug reporting
>   contribute: switch security process to gitlab confidential issues
> 
>  contribute/report-a-bug.md     |  63 +++++---
>  contribute/security-process.md | 280 ++++++++++++++-------------------
>  2 files changed, 155 insertions(+), 188 deletions(-)
> 
> -- 
> 2.54.0