I previously raised the idea of using GitLab issues for security disclosures:
https://lists.gnu.org/archive/html/qemu-devel/2026-05/msg04582.html 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
