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

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

[Daniel P. Berrangé]

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

[qemu-web RFC 1/3] contribute: reformat/restructure bug report guidance

[Daniel P. Berrangé]

The current bug report bullet points are duplicating an
arbitrary subset of what is already requested in the gitlab
issue template. Rewrite the guidance such that it refers to
the issue template fields being required, where applicable.
Restructure the text in general so that it is all a bullet
point list rather than a strange mix of list items and
separate paragraphs.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 contribute/report-a-bug.md | 55 +++++++++++++++++++++++---------------
 1 file changed, 33 insertions(+), 22 deletions(-)

diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index 8a7c782..6071837 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -3,26 +3,37 @@ title: Reporting a bug
 permalink: /contribute/report-a-bug/
 ---
 
-Bugs can be filed at our
+Bugs affecting upstream QEMU releases should be filed at our
 [bug tracker](https://gitlab.com/qemu-project/qemu/-/issues), which is hosted
-on GitLab. Note: If you've got a problem with how your Linux distribution
-packages QEMU, please use the bug tracker from your distro instead.
-
-When submitting a bug report, please try to do the following:
-
-* Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug.  Reports against the [latest release](/download/#source) or even the latest development tree are usually acted upon faster.
-
-* Include the full command line used to launch the QEMU guest.
-
-* Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
-
-* Include information about the host and guest (operating system, version, 32/64-bit).
-
-QEMU does not use GitLab merge requests; patches are sent to the mailing list according to QEMU's [patch submissions guidelines](../submit-a-patch/).
-
-Do NOT report security issues (or other bugs, too) as "confidential" bugs in the
-bug tracker.  QEMU has a [security process](../security-process) for issues
-that should be reported in a non-public way instead.
-
-For problems with KVM in the kernel, use the kernel bug tracker instead;
-the [KVM wiki](https://www.linux-kvm.org/page/Bugs) has the details.
+on GitLab, taking into account the following guidance.
+
+* Use the provided GitLab issue template, filling in all
+  requested pieces of information that are relevant to the
+  discovered bug.
+
+* Reproduce the problem with the latest upstream QEMU release.
+  Reports against older versions may not be acted upon with
+  with the same priority.
+
+* Problems that have only been demonstrated with an release
+  packaged by an OS distribution vendor must be either reported
+  to the vendor's own bug tracker instead, or reproduced with
+  an upstream QEMU build prior to submission.
+
+* Reproduce the problem directly with a QEMU command-line. Avoid
+  frontends and management stacks, to ensure that the bug is in
+  QEMU itself and not in a frontend and make it easier for
+  maintainers to understand the problematic scenario.
+
+* If patches are available for an issue, they should be sent to
+  the mailing list according to QEMU's [patch submissions
+  guidelines](../submit-a-patch/). QEMU does not use a merge
+  request workflow for contribution.
+
+* Do NOT report security issues (or other bugs, too) as "confidential"
+  bugs in the bug tracker.  QEMU has a [security process](../security-process)
+  for issues that should be reported in a non-public way instead.
+
+* If the problem is believed to lie in the KVM kernel module,
+  following the [KVM wiki bug report](https://www.linux-kvm.org/page/Bugs)
+  guidance to submit an issue to the kernel bug tracker.
-- 
2.54.0

[qemu-web RFC 2/3] contribute: add automate tool disclosure to bug reporting

[Daniel P. Berrangé]

A while back we added a requirement to declare the use of any
automated tooling used in discover of security issues, and set
a rule that the reporter must perform triage before submission
rather than blindly reporting issues. This applies equally
well to normal issue reporting, so copy it over from the
security process guidance.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 contribute/report-a-bug.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index 6071837..fd3bc6b 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -20,6 +20,13 @@ on GitLab, taking into account the following guidance.
   to the vendor's own bug tracker instead, or reproduced with
   an upstream QEMU build prior to submission.
 
+* If any automated tools (AI/LLM based, traditional static
+  analysis, or fuzzers) were used to discover the issue, the
+  reporter is required to declare this at the start of the
+  bug report. Users of such tools are required to perform
+  triage of their output to validate all findings and reproducer
+  scenarios prior to submitting a bug report.
+
 * Reproduce the problem directly with a QEMU command-line. Avoid
   frontends and management stacks, to ensure that the bug is in
   QEMU itself and not in a frontend and make it easier for
-- 
2.54.0

[qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

It is no longer viable to handle the incredible volumes of
AI assisted security disclosures via email, nor are extended
embargos practical or useful.

Remove all information about the current security process and
instruct reporters to use 'confidential' issues. In contrast
to the old highly restrictive "need to know" approach, the
new approach makes all security issues visible to all QEMU
maintainers immediately.

The focus is on making issues public as soon as possible with
a viable patch. Co-ordinated disclosure will no longer be
attempted and nor will requests to embargoes be accepted.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 contribute/report-a-bug.md     |   9 +-
 contribute/security-process.md | 280 ++++++++++++++-------------------
 2 files changed, 119 insertions(+), 170 deletions(-)

diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index fd3bc6b..b506f9f 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
   requested pieces of information that are relevant to the
   discovered bug.
 
+* Bugs which are suspected, or known, to have security implications
+  **must** be marked as "*confidential*" prior to submitting the
+  disclosure. Consult the [security process](../security-process)
+  for further guidance on security issue handling.
+
 * Reproduce the problem with the latest upstream QEMU release.
   Reports against older versions may not be acted upon with
   with the same priority.
@@ -37,10 +42,6 @@ on GitLab, taking into account the following guidance.
   guidelines](../submit-a-patch/). QEMU does not use a merge
   request workflow for contribution.
 
-* Do NOT report security issues (or other bugs, too) as "confidential"
-  bugs in the bug tracker.  QEMU has a [security process](../security-process)
-  for issues that should be reported in a non-public way instead.
-
 * If the problem is believed to lie in the KVM kernel module,
   following the [KVM wiki bug report](https://www.linux-kvm.org/page/Bugs)
   guidance to submit an issue to the kernel bug tracker.
diff --git a/contribute/security-process.md b/contribute/security-process.md
index 5c708f5..a500b16 100644
--- a/contribute/security-process.md
+++ b/contribute/security-process.md
@@ -3,169 +3,117 @@ title: Security Process
 permalink: /contribute/security-process/
 ---
 
-Please report any suspected security issue in QEMU to the security mailing
-list at:
-
-* [\<qemu-security@nongnu.org\>](https://lists.nongnu.org/mailman/listinfo/qemu-security)
-
-Note that not all areas of QEMU are considered to provide a security
-boundary. Consult the guidance at the end of this page for further
-information on how QEMU classifies issues as security vulnerabilities
-vs regular bugs.
-
-## How to report an issue:
-
-* Please include as many details as possible in the issue report.
-  Ex:
-    - QEMU version, upstream commit/tag
-    - Host & Guest architecture x86/Arm/PPC, 32/64 bit etc.
-    - Affected code area/snippets
-    - Stack traces, crash details
-    - Malicious inputs/reproducer steps etc.
-    - Any configurations/settings required to trigger the issue.
-
-* Please share the QEMU command line used to invoke a guest VM.
-
-* Please specify whom to acknowledge for reporting this issue.
-
-* If any automated tools (AI/LLM based, traditional static
-  analysis, or fuzzers) were used to discover the issue, the
-  reporter is required to declare this at the start of the
-  security report. Users of such tools are required to perform
-  triage of their output. Findings and reproducer scenarios
-  output by automated tools must be validated prior to submitting
-  an issue to the QEMU security team.
-
-## How we respond:
-
-* Process of handling security issues comprises following steps:
-
-  0) **Acknowledge:**
-    - A non-automated response email is sent to the reporter(s) to acknowledge
-      the reception of the report. (*60 day's counter starts here*)
-
-  1) **Triage:**
-    - Examine the issue details and confirm whether the issue is genuine
-    - Validate if it can be misused for malicious purposes
-    - Determine its worst case impact and severity
-      [Low/Moderate/Important/Critical]
-
-  2) **Response:**
-    - Negotiate embargo timeline (if required, depending on severity)
-    - Request a [CVE](https://cveform.mitre.org/) and open an upstream
-      [bug](https://www.qemu.org/contribute/report-a-bug/)
-    - Create an upstream fix patch annotated with
-        - CVE-ID
-        - Link to an upstream bugzilla
-        - Reported-by, Tested-by etc. tags
-    - Once the patch is merged, close the upstream bug with a link to the
-      commit
-        - Fixed in: <commit hash/link>
-
-* Above security lists are operated by select analysts, maintainers and/or
-  representatives from downstream communities.
-
-* List members follow a **responsible disclosure** policy. Any non-public
-  information you share about security issues, is kept confidential within
-  members of the QEMU security team and a minimal supporting staff in their
-  affiliated companies. Such information will not be disclosed to third party
-  organisations/individuals without prior permission from the reporter(s).
-
-* We aim to process security issues within maximum of **60 days**. That is not
-  to say that issues will remain private for 60 days, nope. After the triaging
-  step above
-    - If severity of the issue is sufficiently low, an upstream public bug
-      will be created immediately.
-    - If severity of the issue requires co-ordinated disclosure at a future
-      date, then the embargo process below is followed, and upstream bug will
-      be opened at the end of the embargo period.
-
-  This will allow upstream contributors to create, test and track fix patch(es).
-
-### Publication embargo
-
-* If a security issue is reported that is not already public and its severity
-  requires coordinated disclosure, then an embargo date will be set and
-  communicated to the reporter(s).
-
-* Embargo periods will be negotiated by mutual agreement between reporter(s),
-  members of the security list and other relevant parties to the problem.
-  The preferred embargo period is upto [2
-  weeks](https://oss-security.openwall.org/wiki/mailing-lists/distros).
-  However, longer embargoes may be negotiated if the severity of the issue
-  requires it.
-
-* Members of the security list agree not to publicly disclose any details of
-  an embargoed security issue until its embargo date expires.
-
-### CVE allocation
-
-Each security issue is assigned a [CVE](https://cveform.mitre.org/) number.
-The CVE number is allocated by one of the vendor security engineers on the
-security list.
-
-## When to contact the QEMU Security List
-
-You should contact the Security List if:
-* You think there may be a security vulnerability in QEMU.
-* You are unsure about how a known vulnerability affects QEMU.
-* You can contact us in English. We are unable to respond in other languages.
-
-## When *not* to contact the QEMU Security List
-* You have not yet performed human review of the output of an automated tool.
-* You need assistance in a language other than English.
-* You require technical assistance (for example, "how do I configure QEMU?").
-* You need help upgrading QEMU due to security alerts.
-* Your issue is not security related.
-
-## How impact and severity of a bug is decided
-
-**Security criterion:**
-    -> [https://www.qemu.org/docs/master/system/security.html](https://www.qemu.org/docs/master/system/security.html)
-
-All security issues in QEMU are not equal. Based on the parts of the QEMU
-sources wherein the bug is found, its impact and severity could vary.
-
-In particular, QEMU is used in many different scenarios; some of them assume
-that the guest is trusted, some of them don't. General considerations to triage
-QEMU issues and decide whether a configuration is security sensitive include:
-
-* Is there any feasible way for a malicious party to exploit this flaw and
-  cause real damage? (e.g. from a guest or via downloadable images)
-* Does the flaw require access to the management interface? Would the
-  management interface be accessible in the scenario where the flaw could cause
-  real damage?
-* Is QEMU used in conjunction with a hypervisor (as opposed to TCG binary
-  translation)?
-* Is QEMU used to offer virtualised production services, as opposed to usage
-  as a development platform?
-
-Whenever some or all of these questions have negative answers, what appears to
-be a major security flaw might be considered of low severity because it could
-only be exercised in use cases where QEMU and everything interacting with it is
-trusted.
-
-For example, consider upstream commit [9201bb9 "sdhci.c: Limit the maximum
-block size"](https://gitlab.com/qemu-project/qemu/-/commit/9201bb9), an of out of
-bounds (OOB) memory access (ie. buffer overflow) issue that was found and fixed
-in the SD Host Controller emulation (hw/sd/sdhci.c).
-
-On the surface, this bug appears to be a genuine security flaw, with potentially
-severe implications. But digging further down, there are only two ways to use
-SD Host Controller emulation, one is via 'sdhci-pci' interface and the other
-is via 'generic-sdhci' interface.
-
-Of these two, the 'sdhci-pci' interface had actually been disabled by default
-in the upstream QEMU releases (commit [1910913 "sdhci: Make device "sdhci-pci"
-unavailable with -device"](https://gitlab.com/qemu-project/qemu/-/commit/1910913)
-at the time the flaw was reported; therefore, guests could not possibly use
-'sdhci-pci' for any purpose.
-
-The 'generic-sdhci' interface, instead, had only one user in 'Xilinx Zynq
-Baseboard emulation' (hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable
-systems on chip (SoC) device. While QEMU does emulate this device, in practice
-it is used to facilitate cross-platform developmental efforts, i.e. QEMU is
-used to write programs for the SoC device. In such developer environments, it
-is generally assumed that the guest is trusted.
-
-And thus, this buffer overflow turned out to be a security non-issue.
+## How to disclosure a potential issues
+
+**The QEMU project no longer accepts security issue disclosures via email.**
+
+New disclosures must follow the [report a bug](report-a-bug.html)
+process to file a GitLab work item for each potential issue, ***marking
+it as "*confidential*" prior to submission.***
+
+If unsure of the security implications of an issue, err on the side
+of caution and mark it as "*confidential*" initially.
+
+## Handling of disclosures
+
+Disclosures made via "*confidential*" GitLab issues are visible to, and
+may be handled by, any QEMU subsystem maintainer whom has a GitLab
+account [associated with the Reporter role in the project](https://gitlab.com/qemu-project/qemu/-/project_members).
+Triage may also be performed by one or more automated tools and/or
+AI agents run by the project that have been granted access to the
+issue tracker.
+
+The first task upon receiving a disclosure is to evaluate eligibility
+to follow the security triage process.
+
+* Disclosures affecting code / features evaluated to fall under the
+[non-virtualization use case](
+https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case),
+will generally not be eligible for handling as a security flaw.
+Such disclosures should be immediately switched to the public
+bug report process by removing the "*confidential*" marker.
+
+* Disclosures affecting code / features evaluated to fall under the
+[virtualization use case](
+https://www.qemu.org/docs/master/system/security.html#virtualization-use-case),
+will be handled under a lightweight security triage process which
+emphasizes getting a fix merged to the latest development branch
+as quickly as possible.
+
+Any disclosure which gets switched to the public bug report process
+will be fixed at the discretion of the maintainer, if and when time
+allows.
+
+In all cases reporters are encouraged to develop and propose patches
+for issues themselves at time of disclosure, to speed resolution.
+
+**NOTE:** The QEMU project policy is that all security disclosures received
+using GitLab "*confidential*" issues **will eventually be made public**. Any
+information that the reporter considers to be be sensitive / private **must**
+be scrubbed before disclosure.
+
+## Triage process
+
+ * A maintainer will evaluate the circumstances of the issue
+   to determine if it can be misused for malicious purposes.
+
+ * If there is no potential for meaningful exploit, the disclosure
+   should be switched to the public bug report process by removing
+   the "*confidential*" marker.
+
+ * If confirmed as a security flaw, a maintainer will request
+   add the **"cve::required"** GitLab label to the GitLab work item,
+   which indicates the need for a CNA to allocate a CVE.
+
+ * The maintainer(s) will develop and/or review patch(es)
+   for the issue privately, optionally attaching work in
+   progress fixes to the GitLab issues. All patches must
+   include the issue URL in the commit message(s).
+
+ * When a CVE is allocated, it will be recorded as a comment on
+   the GitLab issue, and the **"cve::requested"** label replaced by
+   the **"cve::assigned"** label.
+
+ * The maintainer(s) will update the commit message(s) to include
+   the assigned CVE. If multiple commits are required to fix an
+   issue the CVE must be included in the final commit in the
+   series, and may optionally be included in all prior commits.
+
+ * When the maintainer(s) are satisfied that the patch(es) are
+   suitable to propose for merge, they must be submitted to
+   the qemu-devel mailing list, and follow the normal process
+   for merge henceforth.
+
+ * At the time the proposed patches are sent to qemu-devel, the
+   maintainers should remove the "*confidential*" marker from the
+   GitLab issue.
+
+ * When the patch is merged into the current development
+   branch the issue must be closed. This should usually happen
+   automatically if the git commits referenced the GitLab issue
+   URL in [the normal format](https://docs.gitlab.com/user/project/issues/managing_issues/#default-closing-pattern).
+
+The QEMU project currently co-ordinates with Red Hat for CVE
+assignment, in its role as the [CNA of last resort for OSS projects](
+https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat).
+
+## Embargo policy
+
+The QEMU project policy is to limit the time that a disclosure has the
+"*confidential*" marker applied strictly to the minimum required to develop
+and publish a suitable patch and allocate a CVE.
+
+Given the widespread use of AI/LLM based agents for security auditing,
+as well as ongoing use of traditional fuzzing and static analyis
+tools, the QEMU maintainers consider that any disclosure originating
+from automated tools is highly likely to be independently re-discovered,
+potentially many times over in a very short timeframe.
+
+Thus the QEMU maintainers will generally reject requests for arbitrary
+embargos unless high severity, extenuating circumstances can be
+demonstrated.
+
+If a patch for a confirmed security issue cannot be developed by a
+maintainer in a reasonable time, the maintainers may choose to make
+a disclosure public without having a patch available. This approach
+should only be taken for issues judged to have low severity.
-- 
2.54.0

Re: [qemu-web RFC 1/3] contribute: reformat/restructure bug report guidance

[Peter Maydell]

On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> The current bug report bullet points are duplicating an
> arbitrary subset of what is already requested in the gitlab
> issue template. Rewrite the guidance such that it refers to
> the issue template fields being required, where applicable.
> Restructure the text in general so that it is all a bullet
> point list rather than a strange mix of list items and
> separate paragraphs.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [qemu-web RFC 2/3] contribute: add automate tool disclosure to bug reporting

[Peter Maydell]

On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> A while back we added a requirement to declare the use of any
> automated tooling used in discover of security issues, and set
> a rule that the reporter must perform triage before submission
> rather than blindly reporting issues. This applies equally
> well to normal issue reporting, so copy it over from the
> security process guidance.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  contribute/report-a-bug.md | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index 6071837..fd3bc6b 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -20,6 +20,13 @@ on GitLab, taking into account the following guidance.
>    to the vendor's own bug tracker instead, or reproduced with
>    an upstream QEMU build prior to submission.
>
> +* If any automated tools (AI/LLM based, traditional static
> +  analysis, or fuzzers) were used to discover the issue, the
> +  reporter is required to declare this at the start of the
> +  bug report. Users of such tools are required to perform
> +  triage of their output to validate all findings and reproducer
> +  scenarios prior to submitting a bug report.
> +
>  * Reproduce the problem directly with a QEMU command-line. Avoid
>    frontends and management stacks, to ensure that the bug is in
>    QEMU itself and not in a frontend and make it easier for


Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Peter Maydell]

On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> It is no longer viable to handle the incredible volumes of
> AI assisted security disclosures via email, nor are extended
> embargos practical or useful.
>
> Remove all information about the current security process and
> instruct reporters to use 'confidential' issues. In contrast
> to the old highly restrictive "need to know" approach, the
> new approach makes all security issues visible to all QEMU
> maintainers immediately.
>
> The focus is on making issues public as soon as possible with
> a viable patch. Co-ordinated disclosure will no longer be
> attempted and nor will requests to embargoes be accepted.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Since I'm not directly involved with the security process, I
don't have a strong view here and I trust your judgement that
this is going to work better. I have a couple of minor
suggestions below.

> +## How to disclosure a potential issues

"How to disclose potential issues"

> +
> +**The QEMU project no longer accepts security issue disclosures via email.**
> +
> +New disclosures must follow the [report a bug](report-a-bug.html)
> +process to file a GitLab work item for each potential issue, ***marking
> +it as "*confidential*" prior to submission.***
> +
> +If unsure of the security implications of an issue, err on the side
> +of caution and mark it as "*confidential*" initially.

"err on the side of caution" doesn't seem to me to interact
very well with "we get a ton of not very well filtered AI reports".
I think we should probably emphasise here that we expect the
submitter to read our description of the virtualization vs
non-virtualization use cases and not report bugs that clearly
don't fall under the virtualization case as confidential.
At the moment the text below says that it's the people on the
receiving end that do that as part of triage.

The old text started up-front with:

-Note that not all areas of QEMU are considered to provide a security
-boundary. Consult the guidance [...]

"People who send us bad security reports" and "people who don't
read the documentation about our security process and policy"
probably has a strong overlap, but I think it's still worth
making sure we have the emphasis pretty strongly on "you as
the submitter are expected to not report things we're going to
instantly triage out as not-security-bugs".

> +## Triage process
> +
> + * A maintainer will evaluate the circumstances of the issue
> +   to determine if it can be misused for malicious purposes.
> +
> + * If there is no potential for meaningful exploit, the disclosure
> +   should be switched to the public bug report process by removing
> +   the "*confidential*" marker.
> +
> + * If confirmed as a security flaw, a maintainer will request

"request" seems a stray word here ?

> +   add the **"cve::required"** GitLab label to the GitLab work item,
> +   which indicates the need for a CNA to allocate a CVE.

thanks
-- PMM

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

[Mauro Matteo Cascella]

On Thu, Jun 4, 2026 at 6:50 PM Daniel P. Berrangé <berrange@redhat.com> 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
>
> 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 totally fine to remain the designated PoC for CVE assignments. To
mitigate the risk of a single point of failure, I'd suggest directing
all CVE requests to secalert@redhat.com with me on CC.

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

LGTM. For the series:
Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>

--
Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Thomas Huth]

On 04/06/2026 18.50, Daniel P. Berrangé wrote:
> It is no longer viable to handle the incredible volumes of
> AI assisted security disclosures via email, nor are extended
> embargos practical or useful.
> 
> Remove all information about the current security process and
> instruct reporters to use 'confidential' issues. In contrast
> to the old highly restrictive "need to know" approach, the
> new approach makes all security issues visible to all QEMU
> maintainers immediately.

Slightly off-topic question ... but: Should we require all maintainers to 
have a gitlab account now? Otherwise we might end up with confidential 
issues nobody is looking at since the related maintainer does not have a 
gitlab account and the other maintainers don't care?

...
> +## How to disclosure a potential issues
> +
> +**The QEMU project no longer accepts security issue disclosures via email.**
> +
> +New disclosures must follow the [report a bug](report-a-bug.html)
> +process to file a GitLab work item for each potential issue, ***marking
> +it as "*confidential*" prior to submission.***
> +
> +If unsure of the security implications of an issue, err on the side
> +of caution and mark it as "*confidential*" initially.
> +
> +## Handling of disclosures
> +
> +Disclosures made via "*confidential*" GitLab issues are visible to, and
> +may be handled by, any QEMU subsystem maintainer whom has a GitLab

I am not a native speaker, but my (likely wrong) gut feeling say it should 
be "who" instead of "whom" here?

> +account [associated with the Reporter role in the project](https://gitlab.com/qemu-project/qemu/-/project_members).
> +Triage may also be performed by one or more automated tools and/or
> +AI agents run by the project that have been granted access to the
> +issue tracker.
> +
> +The first task upon receiving a disclosure is to evaluate eligibility
> +to follow the security triage process.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[non-virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case),
> +will generally not be eligible for handling as a security flaw.
> +Such disclosures should be immediately switched to the public
> +bug report process by removing the "*confidential*" marker.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#virtualization-use-case),
> +will be handled under a lightweight security triage process which
> +emphasizes getting a fix merged to the latest development branch
> +as quickly as possible.
> +
> +Any disclosure which gets switched to the public bug report process
> +will be fixed at the discretion of the maintainer, if and when time
> +allows.
> +
> +In all cases reporters are encouraged to develop and propose patches
> +for issues themselves at time of disclosure, to speed resolution.
> +
> +**NOTE:** The QEMU project policy is that all security disclosures received
> +using GitLab "*confidential*" issues **will eventually be made public**. Any
> +information that the reporter considers to be be sensitive / private **must**
> +be scrubbed before disclosure.
> +
> +## Triage process
> +
> + * A maintainer will evaluate the circumstances of the issue
> +   to determine if it can be misused for malicious purposes.
> +
> + * If there is no potential for meaningful exploit, the disclosure
> +   should be switched to the public bug report process by removing
> +   the "*confidential*" marker.
> +
> + * If confirmed as a security flaw, a maintainer will request
> +   add the **"cve::required"** GitLab label to the GitLab work item,
> +   which indicates the need for a CNA to allocate a CVE.
> +
> + * The maintainer(s) will develop and/or review patch(es)
> +   for the issue privately, optionally attaching work in
> +   progress fixes to the GitLab issues. All patches must
> +   include the issue URL in the commit message(s).
> +
> + * When a CVE is allocated, it will be recorded as a comment on
> +   the GitLab issue, and the **"cve::requested"** label replaced by
> +   the **"cve::assigned"** label.
> +
> + * The maintainer(s) will update the commit message(s) to include
> +   the assigned CVE. If multiple commits are required to fix an
> +   issue the CVE must be included in the final commit in the
> +   series, and may optionally be included in all prior commits.
> +
> + * When the maintainer(s) are satisfied that the patch(es) are
> +   suitable to propose for merge, they must be submitted to
> +   the qemu-devel mailing list, and follow the normal process
> +   for merge henceforth.
> +
> + * At the time the proposed patches are sent to qemu-devel, the
> +   maintainers should remove the "*confidential*" marker from the
> +   GitLab issue.
> +
> + * When the patch is merged into the current development
> +   branch the issue must be closed. This should usually happen
> +   automatically if the git commits referenced the GitLab issue
> +   URL in [the normal format](https://docs.gitlab.com/user/project/issues/managing_issues/#default-closing-pattern).
> +
> +The QEMU project currently co-ordinates with Red Hat for CVE
> +assignment, in its role as the [CNA of last resort for OSS projects](
> +https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat).
> +
> +## Embargo policy
> +
> +The QEMU project policy is to limit the time that a disclosure has the
> +"*confidential*" marker applied strictly to the minimum required to develop
> +and publish a suitable patch and allocate a CVE.
> +
> +Given the widespread use of AI/LLM based agents for security auditing,
> +as well as ongoing use of traditional fuzzing and static analyis

s/analyis/analysis/

> +tools, the QEMU maintainers consider that any disclosure originating
> +from automated tools is highly likely to be independently re-discovered,
> +potentially many times over in a very short timeframe.
> +
> +Thus the QEMU maintainers will generally reject requests for arbitrary
> +embargos unless high severity, extenuating circumstances can be

s/embargos/embargoes/

> +demonstrated.
> +
> +If a patch for a confirmed security issue cannot be developed by a
> +maintainer in a reasonable time, the maintainers may choose to make
> +a disclosure public without having a patch available. This approach
> +should only be taken for issues judged to have low severity.

  Thomas

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> It is no longer viable to handle the incredible volumes of
> AI assisted security disclosures via email, nor are extended
> embargos practical or useful.
> 
> Remove all information about the current security process and
> instruct reporters to use 'confidential' issues. In contrast
> to the old highly restrictive "need to know" approach, the
> new approach makes all security issues visible to all QEMU
> maintainers immediately.
> 
> The focus is on making issues public as soon as possible with
> a viable patch. Co-ordinated disclosure will no longer be
> attempted and nor will requests to embargoes be accepted.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  contribute/report-a-bug.md     |   9 +-
>  contribute/security-process.md | 280 ++++++++++++++-------------------
>  2 files changed, 119 insertions(+), 170 deletions(-)
> 
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index fd3bc6b..b506f9f 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
>    requested pieces of information that are relevant to the
>    discovered bug.
>  
> +* Bugs which are suspected, or known, to have security implications
> +  **must** be marked as "*confidential*" prior to submitting the
> +  disclosure. Consult the [security process](../security-process)
> +  for further guidance on security issue handling.
> +

Do we want to do like linux does, and make AI found issues public,
on the assumption that bad guys can find them just as easily?



>  * Reproduce the problem with the latest upstream QEMU release.
>    Reports against older versions may not be acted upon with
>    with the same priority.
> @@ -37,10 +42,6 @@ on GitLab, taking into account the following guidance.
>    guidelines](../submit-a-patch/). QEMU does not use a merge
>    request workflow for contribution.
>  
> -* Do NOT report security issues (or other bugs, too) as "confidential"
> -  bugs in the bug tracker.  QEMU has a [security process](../security-process)
> -  for issues that should be reported in a non-public way instead.
> -
>  * If the problem is believed to lie in the KVM kernel module,
>    following the [KVM wiki bug report](https://www.linux-kvm.org/page/Bugs)
>    guidance to submit an issue to the kernel bug tracker.
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 5c708f5..a500b16 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md
> @@ -3,169 +3,117 @@ title: Security Process
>  permalink: /contribute/security-process/
>  ---
>  
> -Please report any suspected security issue in QEMU to the security mailing
> -list at:
> -
> -* [\<qemu-security@nongnu.org\>](https://lists.nongnu.org/mailman/listinfo/qemu-security)
> -
> -Note that not all areas of QEMU are considered to provide a security
> -boundary. Consult the guidance at the end of this page for further
> -information on how QEMU classifies issues as security vulnerabilities
> -vs regular bugs.
> -
> -## How to report an issue:
> -
> -* Please include as many details as possible in the issue report.
> -  Ex:
> -    - QEMU version, upstream commit/tag
> -    - Host & Guest architecture x86/Arm/PPC, 32/64 bit etc.
> -    - Affected code area/snippets
> -    - Stack traces, crash details
> -    - Malicious inputs/reproducer steps etc.
> -    - Any configurations/settings required to trigger the issue.
> -
> -* Please share the QEMU command line used to invoke a guest VM.
> -
> -* Please specify whom to acknowledge for reporting this issue.
> -
> -* If any automated tools (AI/LLM based, traditional static
> -  analysis, or fuzzers) were used to discover the issue, the
> -  reporter is required to declare this at the start of the
> -  security report. Users of such tools are required to perform
> -  triage of their output. Findings and reproducer scenarios
> -  output by automated tools must be validated prior to submitting
> -  an issue to the QEMU security team.
> -
> -## How we respond:
> -
> -* Process of handling security issues comprises following steps:
> -
> -  0) **Acknowledge:**
> -    - A non-automated response email is sent to the reporter(s) to acknowledge
> -      the reception of the report. (*60 day's counter starts here*)
> -
> -  1) **Triage:**
> -    - Examine the issue details and confirm whether the issue is genuine
> -    - Validate if it can be misused for malicious purposes
> -    - Determine its worst case impact and severity
> -      [Low/Moderate/Important/Critical]
> -
> -  2) **Response:**
> -    - Negotiate embargo timeline (if required, depending on severity)
> -    - Request a [CVE](https://cveform.mitre.org/) and open an upstream
> -      [bug](https://www.qemu.org/contribute/report-a-bug/)
> -    - Create an upstream fix patch annotated with
> -        - CVE-ID
> -        - Link to an upstream bugzilla
> -        - Reported-by, Tested-by etc. tags
> -    - Once the patch is merged, close the upstream bug with a link to the
> -      commit
> -        - Fixed in: <commit hash/link>
> -
> -* Above security lists are operated by select analysts, maintainers and/or
> -  representatives from downstream communities.
> -
> -* List members follow a **responsible disclosure** policy. Any non-public
> -  information you share about security issues, is kept confidential within
> -  members of the QEMU security team and a minimal supporting staff in their
> -  affiliated companies. Such information will not be disclosed to third party
> -  organisations/individuals without prior permission from the reporter(s).
> -
> -* We aim to process security issues within maximum of **60 days**. That is not
> -  to say that issues will remain private for 60 days, nope. After the triaging
> -  step above
> -    - If severity of the issue is sufficiently low, an upstream public bug
> -      will be created immediately.
> -    - If severity of the issue requires co-ordinated disclosure at a future
> -      date, then the embargo process below is followed, and upstream bug will
> -      be opened at the end of the embargo period.
> -
> -  This will allow upstream contributors to create, test and track fix patch(es).
> -
> -### Publication embargo
> -
> -* If a security issue is reported that is not already public and its severity
> -  requires coordinated disclosure, then an embargo date will be set and
> -  communicated to the reporter(s).
> -
> -* Embargo periods will be negotiated by mutual agreement between reporter(s),
> -  members of the security list and other relevant parties to the problem.
> -  The preferred embargo period is upto [2
> -  weeks](https://oss-security.openwall.org/wiki/mailing-lists/distros).
> -  However, longer embargoes may be negotiated if the severity of the issue
> -  requires it.
> -
> -* Members of the security list agree not to publicly disclose any details of
> -  an embargoed security issue until its embargo date expires.
> -
> -### CVE allocation
> -
> -Each security issue is assigned a [CVE](https://cveform.mitre.org/) number.
> -The CVE number is allocated by one of the vendor security engineers on the
> -security list.
> -
> -## When to contact the QEMU Security List
> -
> -You should contact the Security List if:
> -* You think there may be a security vulnerability in QEMU.
> -* You are unsure about how a known vulnerability affects QEMU.
> -* You can contact us in English. We are unable to respond in other languages.
> -
> -## When *not* to contact the QEMU Security List
> -* You have not yet performed human review of the output of an automated tool.
> -* You need assistance in a language other than English.
> -* You require technical assistance (for example, "how do I configure QEMU?").
> -* You need help upgrading QEMU due to security alerts.
> -* Your issue is not security related.
> -
> -## How impact and severity of a bug is decided
> -
> -**Security criterion:**
> -    -> [https://www.qemu.org/docs/master/system/security.html](https://www.qemu.org/docs/master/system/security.html)
> -
> -All security issues in QEMU are not equal. Based on the parts of the QEMU
> -sources wherein the bug is found, its impact and severity could vary.
> -
> -In particular, QEMU is used in many different scenarios; some of them assume
> -that the guest is trusted, some of them don't. General considerations to triage
> -QEMU issues and decide whether a configuration is security sensitive include:
> -
> -* Is there any feasible way for a malicious party to exploit this flaw and
> -  cause real damage? (e.g. from a guest or via downloadable images)
> -* Does the flaw require access to the management interface? Would the
> -  management interface be accessible in the scenario where the flaw could cause
> -  real damage?
> -* Is QEMU used in conjunction with a hypervisor (as opposed to TCG binary
> -  translation)?
> -* Is QEMU used to offer virtualised production services, as opposed to usage
> -  as a development platform?
> -
> -Whenever some or all of these questions have negative answers, what appears to
> -be a major security flaw might be considered of low severity because it could
> -only be exercised in use cases where QEMU and everything interacting with it is
> -trusted.
> -
> -For example, consider upstream commit [9201bb9 "sdhci.c: Limit the maximum
> -block size"](https://gitlab.com/qemu-project/qemu/-/commit/9201bb9), an of out of
> -bounds (OOB) memory access (ie. buffer overflow) issue that was found and fixed
> -in the SD Host Controller emulation (hw/sd/sdhci.c).
> -
> -On the surface, this bug appears to be a genuine security flaw, with potentially
> -severe implications. But digging further down, there are only two ways to use
> -SD Host Controller emulation, one is via 'sdhci-pci' interface and the other
> -is via 'generic-sdhci' interface.
> -
> -Of these two, the 'sdhci-pci' interface had actually been disabled by default
> -in the upstream QEMU releases (commit [1910913 "sdhci: Make device "sdhci-pci"
> -unavailable with -device"](https://gitlab.com/qemu-project/qemu/-/commit/1910913)
> -at the time the flaw was reported; therefore, guests could not possibly use
> -'sdhci-pci' for any purpose.
> -
> -The 'generic-sdhci' interface, instead, had only one user in 'Xilinx Zynq
> -Baseboard emulation' (hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable
> -systems on chip (SoC) device. While QEMU does emulate this device, in practice
> -it is used to facilitate cross-platform developmental efforts, i.e. QEMU is
> -used to write programs for the SoC device. In such developer environments, it
> -is generally assumed that the guest is trusted.
> -
> -And thus, this buffer overflow turned out to be a security non-issue.
> +## How to disclosure a potential issues
> +
> +**The QEMU project no longer accepts security issue disclosures via email.**
> +
> +New disclosures must follow the [report a bug](report-a-bug.html)
> +process to file a GitLab work item for each potential issue, ***marking
> +it as "*confidential*" prior to submission.***
> +
> +If unsure of the security implications of an issue, err on the side
> +of caution and mark it as "*confidential*" initially.
> +
> +## Handling of disclosures
> +
> +Disclosures made via "*confidential*" GitLab issues are visible to, and
> +may be handled by, any QEMU subsystem maintainer whom has a GitLab
> +account [associated with the Reporter role in the project](https://gitlab.com/qemu-project/qemu/-/project_members).
> +Triage may also be performed by one or more automated tools and/or
> +AI agents run by the project that have been granted access to the
> +issue tracker.
> +
> +The first task upon receiving a disclosure is to evaluate eligibility
> +to follow the security triage process.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[non-virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case),
> +will generally not be eligible for handling as a security flaw.
> +Such disclosures should be immediately switched to the public
> +bug report process by removing the "*confidential*" marker.
> +
> +* Disclosures affecting code / features evaluated to fall under the
> +[virtualization use case](
> +https://www.qemu.org/docs/master/system/security.html#virtualization-use-case),
> +will be handled under a lightweight security triage process which
> +emphasizes getting a fix merged to the latest development branch
> +as quickly as possible.
> +
> +Any disclosure which gets switched to the public bug report process
> +will be fixed at the discretion of the maintainer, if and when time
> +allows.
> +
> +In all cases reporters are encouraged to develop and propose patches
> +for issues themselves at time of disclosure, to speed resolution.
> +
> +**NOTE:** The QEMU project policy is that all security disclosures received
> +using GitLab "*confidential*" issues **will eventually be made public**. Any
> +information that the reporter considers to be be sensitive / private **must**
> +be scrubbed before disclosure.
> +
> +## Triage process
> +
> + * A maintainer will evaluate the circumstances of the issue
> +   to determine if it can be misused for malicious purposes.
> +
> + * If there is no potential for meaningful exploit, the disclosure
> +   should be switched to the public bug report process by removing
> +   the "*confidential*" marker.
> +
> + * If confirmed as a security flaw, a maintainer will request
> +   add the **"cve::required"** GitLab label to the GitLab work item,
> +   which indicates the need for a CNA to allocate a CVE.
> +
> + * The maintainer(s) will develop and/or review patch(es)
> +   for the issue privately, optionally attaching work in
> +   progress fixes to the GitLab issues. All patches must
> +   include the issue URL in the commit message(s).
> +
> + * When a CVE is allocated, it will be recorded as a comment on
> +   the GitLab issue, and the **"cve::requested"** label replaced by
> +   the **"cve::assigned"** label.
> +
> + * The maintainer(s) will update the commit message(s) to include
> +   the assigned CVE. If multiple commits are required to fix an
> +   issue the CVE must be included in the final commit in the
> +   series, and may optionally be included in all prior commits.
> +
> + * When the maintainer(s) are satisfied that the patch(es) are
> +   suitable to propose for merge, they must be submitted to
> +   the qemu-devel mailing list, and follow the normal process
> +   for merge henceforth.
> +
> + * At the time the proposed patches are sent to qemu-devel, the
> +   maintainers should remove the "*confidential*" marker from the
> +   GitLab issue.
> +
> + * When the patch is merged into the current development
> +   branch the issue must be closed. This should usually happen
> +   automatically if the git commits referenced the GitLab issue
> +   URL in [the normal format](https://docs.gitlab.com/user/project/issues/managing_issues/#default-closing-pattern).
> +
> +The QEMU project currently co-ordinates with Red Hat for CVE
> +assignment, in its role as the [CNA of last resort for OSS projects](
> +https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat).
> +
> +## Embargo policy
> +
> +The QEMU project policy is to limit the time that a disclosure has the
> +"*confidential*" marker applied strictly to the minimum required to develop
> +and publish a suitable patch and allocate a CVE.
> +
> +Given the widespread use of AI/LLM based agents for security auditing,
> +as well as ongoing use of traditional fuzzing and static analyis
> +tools, the QEMU maintainers consider that any disclosure originating
> +from automated tools is highly likely to be independently re-discovered,
> +potentially many times over in a very short timeframe.
> +
> +Thus the QEMU maintainers will generally reject requests for arbitrary
> +embargos unless high severity, extenuating circumstances can be
> +demonstrated.
> +
> +If a patch for a confirmed security issue cannot be developed by a
> +maintainer in a reasonable time, the maintainers may choose to make
> +a disclosure public without having a patch available. This approach
> +should only be taken for issues judged to have low severity.
> -- 
> 2.54.0

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Mon, Jun 08, 2026 at 02:39:06PM +0100, Peter Maydell wrote:
> On Thu, 4 Jun 2026 at 17:51, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > It is no longer viable to handle the incredible volumes of
> > AI assisted security disclosures via email, nor are extended
> > embargos practical or useful.
> >
> > Remove all information about the current security process and
> > instruct reporters to use 'confidential' issues. In contrast
> > to the old highly restrictive "need to know" approach, the
> > new approach makes all security issues visible to all QEMU
> > maintainers immediately.
> >
> > The focus is on making issues public as soon as possible with
> > a viable patch. Co-ordinated disclosure will no longer be
> > attempted and nor will requests to embargoes be accepted.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> 
> Since I'm not directly involved with the security process, I
> don't have a strong view here and I trust your judgement that
> this is going to work better. I have a couple of minor
> suggestions below.
> 
> > +## How to disclosure a potential issues
> 
> "How to disclose potential issues"
> 
> > +
> > +**The QEMU project no longer accepts security issue disclosures via email.**
> > +
> > +New disclosures must follow the [report a bug](report-a-bug.html)
> > +process to file a GitLab work item for each potential issue, ***marking
> > +it as "*confidential*" prior to submission.***
> > +
> > +If unsure of the security implications of an issue, err on the side
> > +of caution and mark it as "*confidential*" initially.
> 
> "err on the side of caution" doesn't seem to me to interact
> very well with "we get a ton of not very well filtered AI reports".
> I think we should probably emphasise here that we expect the
> submitter to read our description of the virtualization vs
> non-virtualization use cases and not report bugs that clearly
> don't fall under the virtualization case as confidential.


Sadly it seems that only maintainers of specific piece of code
really know if it's non-virtualization use case.

E.g. nvme emulation is non virtualization, I find out.
Wouldn't have guessed.

> At the moment the text below says that it's the people on the
> receiving end that do that as part of triage.
> 
> The old text started up-front with:
> 
> -Note that not all areas of QEMU are considered to provide a security
> -boundary. Consult the guidance [...]
> 
> "People who send us bad security reports" and "people who don't
> read the documentation about our security process and policy"
> probably has a strong overlap, but I think it's still worth
> making sure we have the emphasis pretty strongly on "you as
> the submitter are expected to not report things we're going to
> instantly triage out as not-security-bugs".
> 
> > +## Triage process
> > +
> > + * A maintainer will evaluate the circumstances of the issue
> > +   to determine if it can be misused for malicious purposes.
> > +
> > + * If there is no potential for meaningful exploit, the disclosure
> > +   should be switched to the public bug report process by removing
> > +   the "*confidential*" marker.
> > +
> > + * If confirmed as a security flaw, a maintainer will request
> 
> "request" seems a stray word here ?
> 
> > +   add the **"cve::required"** GitLab label to the GitLab work item,
> > +   which indicates the need for a CNA to allocate a CVE.
> 
> thanks
> -- PMM

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

[Michael S. Tsirkin]

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

Re: [qemu-web RFC 2/3] contribute: add automate tool disclosure to bug reporting

[Michael S. Tsirkin]

On Thu, Jun 04, 2026 at 05:50:47PM +0100, Daniel P. Berrangé wrote:
> A while back we added a requirement to declare the use of any
> automated tooling used in discover of security issues, and set
> a rule that the reporter must perform triage before submission
> rather than blindly reporting issues. This applies equally
> well to normal issue reporting, so copy it over from the
> security process guidance.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>


Acked-by: Michael S. Tsirkin <mst@redhat.com>

Maybe .gitlab/issue_templates/bug.md should be updated then?

> ---
>  contribute/report-a-bug.md | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index 6071837..fd3bc6b 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -20,6 +20,13 @@ on GitLab, taking into account the following guidance.
>    to the vendor's own bug tracker instead, or reproduced with
>    an upstream QEMU build prior to submission.
>  
> +* If any automated tools (AI/LLM based, traditional static
> +  analysis, or fuzzers) were used to discover the issue, the
> +  reporter is required to declare this at the start of the
> +  bug report. Users of such tools are required to perform
> +  triage of their output to validate all findings and reproducer
> +  scenarios prior to submitting a bug report.
> +
>  * Reproduce the problem directly with a QEMU command-line. Avoid
>    frontends and management stacks, to ensure that the bug is in
>    QEMU itself and not in a frontend and make it easier for
> -- 
> 2.54.0

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> > It is no longer viable to handle the incredible volumes of
> > AI assisted security disclosures via email, nor are extended
> > embargos practical or useful.
> > 
> > Remove all information about the current security process and
> > instruct reporters to use 'confidential' issues. In contrast
> > to the old highly restrictive "need to know" approach, the
> > new approach makes all security issues visible to all QEMU
> > maintainers immediately.
> > 
> > The focus is on making issues public as soon as possible with
> > a viable patch. Co-ordinated disclosure will no longer be
> > attempted and nor will requests to embargoes be accepted.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  contribute/report-a-bug.md     |   9 +-
> >  contribute/security-process.md | 280 ++++++++++++++-------------------
> >  2 files changed, 119 insertions(+), 170 deletions(-)
> > 
> > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> > index fd3bc6b..b506f9f 100644
> > --- a/contribute/report-a-bug.md
> > +++ b/contribute/report-a-bug.md
> > @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
> >    requested pieces of information that are relevant to the
> >    discovered bug.
> >  
> > +* Bugs which are suspected, or known, to have security implications
> > +  **must** be marked as "*confidential*" prior to submitting the
> > +  disclosure. Consult the [security process](../security-process)
> > +  for further guidance on security issue handling.
> > +
> 
> Do we want to do like linux does, and make AI found issues public,
> on the assumption that bad guys can find them just as easily?

I'm pretty sympathetic to the idea that AI discovered issues
are "effectively public", but IMHO that's not quite the same
as "actually public".

While people can re-discover things, that doesn't mean we should
do the job for them by publicising everything immediately.

To me, the main implications of the "effectively public" view
point are

 * Minimizing time-to-fix is the core priority
 * Process needs to be low cost minimal external dependencies

Delaying disclosure to suit arbitrary downstream vendor's or user's
update schedules is not helpful. The only delays to publication should
be to allow a maintainer to get a patch prepared, nothing beyond that.
"Low" severity bugs can be public immediately regardless of a patch.

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

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Wed, Jun 10, 2026 at 12:02:43PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> > > It is no longer viable to handle the incredible volumes of
> > > AI assisted security disclosures via email, nor are extended
> > > embargos practical or useful.
> > > 
> > > Remove all information about the current security process and
> > > instruct reporters to use 'confidential' issues. In contrast
> > > to the old highly restrictive "need to know" approach, the
> > > new approach makes all security issues visible to all QEMU
> > > maintainers immediately.
> > > 
> > > The focus is on making issues public as soon as possible with
> > > a viable patch. Co-ordinated disclosure will no longer be
> > > attempted and nor will requests to embargoes be accepted.
> > > 
> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > ---
> > >  contribute/report-a-bug.md     |   9 +-
> > >  contribute/security-process.md | 280 ++++++++++++++-------------------
> > >  2 files changed, 119 insertions(+), 170 deletions(-)
> > > 
> > > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> > > index fd3bc6b..b506f9f 100644
> > > --- a/contribute/report-a-bug.md
> > > +++ b/contribute/report-a-bug.md
> > > @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
> > >    requested pieces of information that are relevant to the
> > >    discovered bug.
> > >  
> > > +* Bugs which are suspected, or known, to have security implications
> > > +  **must** be marked as "*confidential*" prior to submitting the
> > > +  disclosure. Consult the [security process](../security-process)
> > > +  for further guidance on security issue handling.
> > > +
> > 
> > Do we want to do like linux does, and make AI found issues public,
> > on the assumption that bad guys can find them just as easily?
> 
> I'm pretty sympathetic to the idea that AI discovered issues
> are "effectively public", but IMHO that's not quite the same
> as "actually public".
> 
> While people can re-discover things, that doesn't mean we should
> do the job for them by publicising everything immediately.
> 
> To me, the main implications of the "effectively public" view
> point are
> 
>  * Minimizing time-to-fix is the core priority
>  * Process needs to be low cost minimal external dependencies
> 
> Delaying disclosure to suit arbitrary downstream vendor's or user's
> update schedules is not helpful. The only delays to publication should
> be to allow a maintainer to get a patch prepared, nothing beyond that.
> "Low" severity bugs can be public immediately regardless of a patch.
> 
> With regards,
> Daniel


Ok so you are saying the process will be: 
- patch posted on public list -> maintainer makes the bug public?

and if the issue is coming with a patch?


> -- 
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Daniel P. Berrangé]

On Wed, Jun 10, 2026 at 06:28:34AM -0400, Michael S. Tsirkin wrote:
> 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.

I'm on the fence about that. I was coming at this from the POV
that security issue disclosure and triage is effectively identical
to normal bug disclosure & triage. The only difference is that
a security issue is initially "confidential" until a maintainer
has sanity checked its severity. I don't think we need to prompt
for different types of information from the user, and even if we
did, it seems like we'll probably just get the  structured markdown
doc the LLM spits out that people have been emailing us.

Maybe it is sufficient to just link to the security.html page
from the existing issue template.


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

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

On Wed, Jun 10, 2026 at 07:06:38AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jun 10, 2026 at 12:02:43PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> > > > It is no longer viable to handle the incredible volumes of
> > > > AI assisted security disclosures via email, nor are extended
> > > > embargos practical or useful.
> > > > 
> > > > Remove all information about the current security process and
> > > > instruct reporters to use 'confidential' issues. In contrast
> > > > to the old highly restrictive "need to know" approach, the
> > > > new approach makes all security issues visible to all QEMU
> > > > maintainers immediately.
> > > > 
> > > > The focus is on making issues public as soon as possible with
> > > > a viable patch. Co-ordinated disclosure will no longer be
> > > > attempted and nor will requests to embargoes be accepted.
> > > > 
> > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > > ---
> > > >  contribute/report-a-bug.md     |   9 +-
> > > >  contribute/security-process.md | 280 ++++++++++++++-------------------
> > > >  2 files changed, 119 insertions(+), 170 deletions(-)
> > > > 
> > > > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> > > > index fd3bc6b..b506f9f 100644
> > > > --- a/contribute/report-a-bug.md
> > > > +++ b/contribute/report-a-bug.md
> > > > @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
> > > >    requested pieces of information that are relevant to the
> > > >    discovered bug.
> > > >  
> > > > +* Bugs which are suspected, or known, to have security implications
> > > > +  **must** be marked as "*confidential*" prior to submitting the
> > > > +  disclosure. Consult the [security process](../security-process)
> > > > +  for further guidance on security issue handling.
> > > > +
> > > 
> > > Do we want to do like linux does, and make AI found issues public,
> > > on the assumption that bad guys can find them just as easily?
> > 
> > I'm pretty sympathetic to the idea that AI discovered issues
> > are "effectively public", but IMHO that's not quite the same
> > as "actually public".
> > 
> > While people can re-discover things, that doesn't mean we should
> > do the job for them by publicising everything immediately.
> > 
> > To me, the main implications of the "effectively public" view
> > point are
> > 
> >  * Minimizing time-to-fix is the core priority
> >  * Process needs to be low cost minimal external dependencies
> > 
> > Delaying disclosure to suit arbitrary downstream vendor's or user's
> > update schedules is not helpful. The only delays to publication should
> > be to allow a maintainer to get a patch prepared, nothing beyond that.
> > "Low" severity bugs can be public immediately regardless of a patch.
> > 
> > With regards,
> > Daniel
> 
> 
> Ok so you are saying the process will be: 
> - patch posted on public list -> maintainer makes the bug public?

Yes, I even wrote that in this patch :-)

 + * At the time the proposed patches are sent to qemu-devel, the
 +   maintainers should remove the "*confidential*" marker from the
 +   GitLab issue.

> and if the issue is coming with a patch?

If the reporter provides a patch, the maintainer merely needs to
review it. If happy, either the reporter or maintainer can send
it to qemu-devel immediately.

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

Re: [qemu-web RFC 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Wed, Jun 10, 2026 at 12:10:04PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 10, 2026 at 07:06:38AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jun 10, 2026 at 12:02:43PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jun 10, 2026 at 06:18:39AM -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jun 04, 2026 at 05:50:48PM +0100, Daniel P. Berrangé wrote:
> > > > > It is no longer viable to handle the incredible volumes of
> > > > > AI assisted security disclosures via email, nor are extended
> > > > > embargos practical or useful.
> > > > > 
> > > > > Remove all information about the current security process and
> > > > > instruct reporters to use 'confidential' issues. In contrast
> > > > > to the old highly restrictive "need to know" approach, the
> > > > > new approach makes all security issues visible to all QEMU
> > > > > maintainers immediately.
> > > > > 
> > > > > The focus is on making issues public as soon as possible with
> > > > > a viable patch. Co-ordinated disclosure will no longer be
> > > > > attempted and nor will requests to embargoes be accepted.
> > > > > 
> > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > > > ---
> > > > >  contribute/report-a-bug.md     |   9 +-
> > > > >  contribute/security-process.md | 280 ++++++++++++++-------------------
> > > > >  2 files changed, 119 insertions(+), 170 deletions(-)
> > > > > 
> > > > > diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> > > > > index fd3bc6b..b506f9f 100644
> > > > > --- a/contribute/report-a-bug.md
> > > > > +++ b/contribute/report-a-bug.md
> > > > > @@ -11,6 +11,11 @@ on GitLab, taking into account the following guidance.
> > > > >    requested pieces of information that are relevant to the
> > > > >    discovered bug.
> > > > >  
> > > > > +* Bugs which are suspected, or known, to have security implications
> > > > > +  **must** be marked as "*confidential*" prior to submitting the
> > > > > +  disclosure. Consult the [security process](../security-process)
> > > > > +  for further guidance on security issue handling.
> > > > > +
> > > > 
> > > > Do we want to do like linux does, and make AI found issues public,
> > > > on the assumption that bad guys can find them just as easily?
> > > 
> > > I'm pretty sympathetic to the idea that AI discovered issues
> > > are "effectively public", but IMHO that's not quite the same
> > > as "actually public".
> > > 
> > > While people can re-discover things, that doesn't mean we should
> > > do the job for them by publicising everything immediately.
> > > 
> > > To me, the main implications of the "effectively public" view
> > > point are
> > > 
> > >  * Minimizing time-to-fix is the core priority
> > >  * Process needs to be low cost minimal external dependencies
> > > 
> > > Delaying disclosure to suit arbitrary downstream vendor's or user's
> > > update schedules is not helpful. The only delays to publication should
> > > be to allow a maintainer to get a patch prepared, nothing beyond that.
> > > "Low" severity bugs can be public immediately regardless of a patch.
> > > 
> > > With regards,
> > > Daniel
> > 
> > 
> > Ok so you are saying the process will be: 
> > - patch posted on public list -> maintainer makes the bug public?
> 
> Yes, I even wrote that in this patch :-)
> 
>  + * At the time the proposed patches are sent to qemu-devel, the
>  +   maintainers should remove the "*confidential*" marker from the
>  +   GitLab issue.
> 

Right, you did.

> > and if the issue is coming with a patch?
> 
> If the reporter provides a patch, the maintainer merely needs to
> review it. If happy, either the reporter or maintainer can send
> it to qemu-devel immediately.
> 
> With regards,
> Daniel

Presumably with a Fixes tag.