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
