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

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

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