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

[qemu-web PATCH v2 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

With the move to use of the issue tracker, my intention is to
use a script to bulk import all disclosures received by
qemu-security@nongnu.org since March 1st 2026.  The imported
issues will reflect the current triage / resolution state of
each disclosure. IOW, completed issues will be immediately
marked closed upon import, non-virt use cases issues will be
marked public, and outstanding virt use case issues will
remain confidential.

The issue description will *NOT* be re-formatted according to
the QEMU bug template. Most disclosures have been provided
via email in markdown format, so this will be imported 'as is'
as the full description with no editting.

The "reporter" in these cases will be a throwaway "bot" account
but the orignal reporter's name, email, date and message-id will
be recorded.

Daniel P. Berrangé (3):
  contribute: reformat/restructure bug report guidance
  contribute: add automated tool disclosure to bug reporting
  contribute: switch security process to gitlab confidential issues

 contribute/report-a-bug.md     |  63 ++++---
 contribute/security-process.md | 309 +++++++++++++++------------------
 2 files changed, 184 insertions(+), 188 deletions(-)

-- 
2.54.0

[qemu-web PATCH v2 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.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
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 PATCH v2 2/3] contribute: add automated 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 discovery 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.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
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 PATCH v2 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 | 309 +++++++++++++++------------------
 2 files changed, 148 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..c091fa1 100644
--- a/contribute/security-process.md
+++ b/contribute/security-process.md
@@ -3,169 +3,146 @@ 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 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 issue (work item) for each potential issue,
+***marking it as "*confidential*" prior to submission.***
+
+Some important notes when disclosing potential security issues:
+
+* The QEMU project cannot provide an SLA for response to security
+  disclosures, or any bug reports in general. Issues will be
+  responded to at the discretion of maintainers, subject to their
+  available time.
+
+* Attachments added to GitLab *confidential* issues are not themselves
+  confidential. If someone knows the randomly generated URL for the
+  attachment, they can view the content. Thus be careful where attachment
+  URLs are shared, while the issue remains confidential.
+
+* All disclosures will eventually be made public. Thus the content
+  or attachments for any issue must not contain data that the reporter
+  considers to be sensitive / private.
+
+* Not all areas of QEMU are considered to provide a security
+  boundary. Consult the [security guide](https://www.qemu.org/docs/master/system/security.html)
+  for details on how QEMU classifies features.
+
+* If an issue affects a feature within the QEMU security boundary,
+  but the reporter is unsure of the security implications, err on
+  the side of caution and mark it as "*confidential*" initially.
+
+* All important information must be disclosed in the issue description,
+  minimizing use of attachments to what is strictly needed. There is
+  a strong preference for individual files to be attached directly.
+  Avoid the use of archives (zip, tar, 7z, etc) to bundle files where
+  practical.
+
+## Handling of disclosures
+
+Disclosures made via "*confidential*" GitLab issues are visible to, and
+may be handled by, any QEMU subsystem maintainer with 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 for maintainers 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.
+
+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 and adding the **"Kind::Bug"** and
+   **"Workflow::Triaged"** labels.
+
+ * If confirmed as a security flaw, a maintainer will add the
+   **"Kind::Security"**, **"Workflow::Confirmed"** and
+   **"CVE::Required"** labels.. The latter 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). The
+   **"Workflow::In Progress"** label should be assigned when
+   a maintainer starts working on a fix.
+
+ * When a CVE is allocated, it must be recorded as a comment on
+   the GitLab issue, and the **"CVE::Required"** label replaced by
+   the **"CVE::Assigned"** label.
+
+ * The maintainer(s) will update the commit message(s) to include
+   the assigned CVE and issue URL. 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. The **"Workflow::Patch Available"**
+   label should be assigned at this stage.
+
+ * 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 **"Closed::Fixed"** label can be assigned.
+
+The QEMU project currently co-ordinates with Red Hat Product
+Security 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 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
+embargoes 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 PATCH v2 1/3] contribute: reformat/restructure bug report guidance

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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.
>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [qemu-web PATCH v2 2/3] contribute: add automated tool disclosure to bug reporting

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> A while back we added a requirement to declare the use of any
> automated tooling used in discovery 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.
>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Philippe Mathieu-Daudé]

On 18/6/26 15:20, Daniel P. Berrangé 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.
> 
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   contribute/report-a-bug.md | 55 +++++++++++++++++++++++---------------
>   1 file changed, 33 insertions(+), 22 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

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

[Philippe Mathieu-Daudé]

On 18/6/26 15:20, 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 | 309 +++++++++++++++------------------
>   2 files changed, 148 insertions(+), 170 deletions(-)


> +**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 issue (work item) for each potential issue,
> +***marking it as "*confidential*" prior to submission.***
> +
> +Some important notes when disclosing potential security issues:
> +
> +* The QEMU project cannot provide an SLA for response to security
> +  disclosures, or any bug reports in general. Issues will be
> +  responded to at the discretion of maintainers, subject to their
> +  available time.
> +
> +* Attachments added to GitLab *confidential* issues are not themselves
> +  confidential. If someone knows the randomly generated URL for the
> +  attachment, they can view the content. Thus be careful where attachment
> +  URLs are shared, while the issue remains confidential.
> +
> +* All disclosures will eventually be made public. Thus the content
> +  or attachments for any issue must not contain data that the reporter
> +  considers to be sensitive / private.
> +
> +* Not all areas of QEMU are considered to provide a security
> +  boundary. Consult the [security guide](https://www.qemu.org/docs/master/system/security.html)
> +  for details on how QEMU classifies features.
> +
> +* If an issue affects a feature within the QEMU security boundary,
> +  but the reporter is unsure of the security implications, err on
> +  the side of caution and mark it as "*confidential*" initially.
> +
> +* All important information must be disclosed in the issue description,
> +  minimizing use of attachments to what is strictly needed. There is
> +  a strong preference for individual files to be attached directly.
> +  Avoid the use of archives (zip, tar, 7z, etc) to bundle files where
> +  practical.

Except this bullet point, everything LGTM. Here I'd enforce reporters to
attach a reproducer (in command line form, with image attached, pointing
to requiered public images to trigger the issue).

If not provided, personally as a maintainer I'd like -- or let scripts 
-- the ability to discard the *confidential* tag to issue with no
reproducer attached, as I don't want to waste time guessing / poking
around, possibly realizing the issue is not reachable.

Otherwise,
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

> +
> +## Handling of disclosures

[...]

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

[Daniel P. Berrangé]

On Thu, Jun 18, 2026 at 04:07:44PM +0200, Philippe Mathieu-Daudé wrote:
> On 18/6/26 15:20, 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 | 309 +++++++++++++++------------------
> >   2 files changed, 148 insertions(+), 170 deletions(-)
> 
> 
> > +**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 issue (work item) for each potential issue,
> > +***marking it as "*confidential*" prior to submission.***
> > +
> > +Some important notes when disclosing potential security issues:
> > +
> > +* The QEMU project cannot provide an SLA for response to security
> > +  disclosures, or any bug reports in general. Issues will be
> > +  responded to at the discretion of maintainers, subject to their
> > +  available time.
> > +
> > +* Attachments added to GitLab *confidential* issues are not themselves
> > +  confidential. If someone knows the randomly generated URL for the
> > +  attachment, they can view the content. Thus be careful where attachment
> > +  URLs are shared, while the issue remains confidential.
> > +
> > +* All disclosures will eventually be made public. Thus the content
> > +  or attachments for any issue must not contain data that the reporter
> > +  considers to be sensitive / private.
> > +
> > +* Not all areas of QEMU are considered to provide a security
> > +  boundary. Consult the [security guide](https://www.qemu.org/docs/master/system/security.html)
> > +  for details on how QEMU classifies features.
> > +
> > +* If an issue affects a feature within the QEMU security boundary,
> > +  but the reporter is unsure of the security implications, err on
> > +  the side of caution and mark it as "*confidential*" initially.
> > +
> > +* All important information must be disclosed in the issue description,
> > +  minimizing use of attachments to what is strictly needed. There is
> > +  a strong preference for individual files to be attached directly.
> > +  Avoid the use of archives (zip, tar, 7z, etc) to bundle files where
> > +  practical.
> 
> Except this bullet point, everything LGTM. Here I'd enforce reporters to
> attach a reproducer (in command line form, with image attached, pointing
> to requiered public images to trigger the issue).

FWIW, I don't think we're going to have a significant problem of
insufficient info with current disclosure practices.

We've not required this historically but none the less most of the AI
assisted disclosures have contained more than enough information to
easily reproduce the issues. Either clearly describing the steps in
the issue description, or shell/python scripts or qtests to exercise
it.

Out of ~300 disclosures this year, only a couple have needed a disk
image to demonstrate and those were stll trivial.

Also note that elsewhere in the file I also explicitly note that
the reporter must personally acknowledge that they reproduced the
problem, so they should be validating the instructions the AI
spat out.

> If not provided, personally as a maintainer I'd like -- or let scripts --
> the ability to discard the *confidential* tag to issue with no
> reproducer attached, as I don't want to waste time guessing / poking
> around, possibly realizing the issue is not reachable.

I very much doubt this is going to be a significant problem for any
confidential issues we get.

The doc is biased towards prompt disclosure though, with the maintainer
having the discretion to decide when to do that now.  Even if it is a
valid security issue a maintainer can decide it should be made public
without waiting for a patch if low severity.

We don't want issues to remain confidential for more than $SMALL number
of days.


> Otherwise,
> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Philippe Mathieu-Daudé]

On 18/6/26 16:20, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 04:07:44PM +0200, Philippe Mathieu-Daudé wrote:
>> On 18/6/26 15:20, 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 | 309 +++++++++++++++------------------
>>>    2 files changed, 148 insertions(+), 170 deletions(-)
>>
>>
>>> +**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 issue (work item) for each potential issue,
>>> +***marking it as "*confidential*" prior to submission.***
>>> +
>>> +Some important notes when disclosing potential security issues:
>>> +
>>> +* The QEMU project cannot provide an SLA for response to security
>>> +  disclosures, or any bug reports in general. Issues will be
>>> +  responded to at the discretion of maintainers, subject to their
>>> +  available time.
>>> +
>>> +* Attachments added to GitLab *confidential* issues are not themselves
>>> +  confidential. If someone knows the randomly generated URL for the
>>> +  attachment, they can view the content. Thus be careful where attachment
>>> +  URLs are shared, while the issue remains confidential.
>>> +
>>> +* All disclosures will eventually be made public. Thus the content
>>> +  or attachments for any issue must not contain data that the reporter
>>> +  considers to be sensitive / private.
>>> +
>>> +* Not all areas of QEMU are considered to provide a security
>>> +  boundary. Consult the [security guide](https://www.qemu.org/docs/master/system/security.html)
>>> +  for details on how QEMU classifies features.
>>> +
>>> +* If an issue affects a feature within the QEMU security boundary,
>>> +  but the reporter is unsure of the security implications, err on
>>> +  the side of caution and mark it as "*confidential*" initially.
>>> +
>>> +* All important information must be disclosed in the issue description,
>>> +  minimizing use of attachments to what is strictly needed. There is
>>> +  a strong preference for individual files to be attached directly.
>>> +  Avoid the use of archives (zip, tar, 7z, etc) to bundle files where
>>> +  practical.
>>
>> Except this bullet point, everything LGTM. Here I'd enforce reporters to
>> attach a reproducer (in command line form, with image attached, pointing
>> to requiered public images to trigger the issue).
> 
> FWIW, I don't think we're going to have a significant problem of
> insufficient info with current disclosure practices.
> 
> We've not required this historically but none the less most of the AI
> assisted disclosures have contained more than enough information to
> easily reproduce the issues. Either clearly describing the steps in
> the issue description, or shell/python scripts or qtests to exercise
> it.
> 
> Out of ~300 disclosures this year, only a couple have needed a disk
> image to demonstrate and those were stll trivial.
> 
> Also note that elsewhere in the file I also explicitly note that
> the reporter must personally acknowledge that they reproduced the
> problem, so they should be validating the instructions the AI
> spat out.

OK.

> 
>> If not provided, personally as a maintainer I'd like -- or let scripts --
>> the ability to discard the *confidential* tag to issue with no
>> reproducer attached, as I don't want to waste time guessing / poking
>> around, possibly realizing the issue is not reachable.
> 
> I very much doubt this is going to be a significant problem for any
> confidential issues we get.
> 
> The doc is biased towards prompt disclosure though, with the maintainer
> having the discretion to decide when to do that now.  Even if it is a
> valid security issue a maintainer can decide it should be made public
> without waiting for a patch if low severity.

Fine then, thanks.

> 
> We don't want issues to remain confidential for more than $SMALL number
> of days.
> 
> 
>> Otherwise,
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
> 
> With regards,
> Daniel

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

[Michael S. Tsirkin]

On Thu, Jun 18, 2026 at 02:20:58PM +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>

Thanks for taking on this. One question:


> ---
>  contribute/report-a-bug.md     |   9 +-
>  contribute/security-process.md | 309 +++++++++++++++------------------
>  2 files changed, 148 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.


There's a problem here in that confidential marking is later
erased. I feel would is benefitial to tag the security bugs
in some way that does not go away so easily. Any idea?


> @@ -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..c091fa1 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md
> @@ -3,169 +3,146 @@ 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 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 issue (work item) for each potential issue,
> +***marking it as "*confidential*" prior to submission.***
> +
> +Some important notes when disclosing potential security issues:
> +
> +* The QEMU project cannot provide an SLA for response to security
> +  disclosures, or any bug reports in general. Issues will be
> +  responded to at the discretion of maintainers, subject to their
> +  available time.
> +
> +* Attachments added to GitLab *confidential* issues are not themselves
> +  confidential. If someone knows the randomly generated URL for the
> +  attachment, they can view the content. Thus be careful where attachment
> +  URLs are shared, while the issue remains confidential.
> +
> +* All disclosures will eventually be made public. Thus the content
> +  or attachments for any issue must not contain data that the reporter
> +  considers to be sensitive / private.
> +
> +* Not all areas of QEMU are considered to provide a security
> +  boundary. Consult the [security guide](https://www.qemu.org/docs/master/system/security.html)
> +  for details on how QEMU classifies features.
> +
> +* If an issue affects a feature within the QEMU security boundary,
> +  but the reporter is unsure of the security implications, err on
> +  the side of caution and mark it as "*confidential*" initially.
> +
> +* All important information must be disclosed in the issue description,
> +  minimizing use of attachments to what is strictly needed. There is
> +  a strong preference for individual files to be attached directly.
> +  Avoid the use of archives (zip, tar, 7z, etc) to bundle files where
> +  practical.
> +
> +## Handling of disclosures
> +
> +Disclosures made via "*confidential*" GitLab issues are visible to, and
> +may be handled by, any QEMU subsystem maintainer with 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 for maintainers 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.
> +
> +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 and adding the **"Kind::Bug"** and
> +   **"Workflow::Triaged"** labels.
> +
> + * If confirmed as a security flaw, a maintainer will add the
> +   **"Kind::Security"**, **"Workflow::Confirmed"** and
> +   **"CVE::Required"** labels.. The latter 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). The
> +   **"Workflow::In Progress"** label should be assigned when
> +   a maintainer starts working on a fix.
> +
> + * When a CVE is allocated, it must be recorded as a comment on
> +   the GitLab issue, and the **"CVE::Required"** label replaced by
> +   the **"CVE::Assigned"** label.
> +
> + * The maintainer(s) will update the commit message(s) to include
> +   the assigned CVE and issue URL. 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. The **"Workflow::Patch Available"**
> +   label should be assigned at this stage.
> +
> + * 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 **"Closed::Fixed"** label can be assigned.
> +
> +The QEMU project currently co-ordinates with Red Hat Product
> +Security 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 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
> +embargoes 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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Mauro Matteo Cascella]

On Thu, Jun 18, 2026 at 3:21 PM 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>

Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>

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

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

[Daniel P. Berrangé]

On Thu, Jun 18, 2026 at 10:42:15AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2026 at 02:20:58PM +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>
> 
> Thanks for taking on this. One question:
> 
> 
> > ---
> >  contribute/report-a-bug.md     |   9 +-
> >  contribute/security-process.md | 309 +++++++++++++++------------------
> >  2 files changed, 148 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.
> 
> 
> There's a problem here in that confidential marking is later
> erased. I feel would is benefitial to tag the security bugs
> in some way that does not go away so easily. Any idea?

Yes, see this paragraph....

> > + * If confirmed as a security flaw, a maintainer will add the
> > +   **"Kind::Security"**, **"Workflow::Confirmed"** and
> > +   **"CVE::Required"** labels.. The latter indicates the need
> > +   for a CNA to allocate a CVE.


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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

> + * The maintainer(s) will develop and/or review patch(es)
> +   for the issue privately, optionally attaching work in
> +   progress fixes to the GitLab issues.

attaching how? how do i ask reported to test the fix?
was easy in the email flow.

> All patches must
> +   include the issue URL in the commit message(s).

you mean the commit message of the patches I presume?
there's no commit at that point.


> The
> +   **"Workflow::In Progress"** label should be assigned when
> +   a maintainer starts working on a fix.

That's a bit heavy, and what is "working" anyway.
It's an issue tracker not a planning app.
Don't try to make it one.


> + * When a CVE is allocated, it must be recorded as a comment on
> +   the GitLab issue, and the **"CVE::Required"** label replaced by
> +   the **"CVE::Assigned"** label.

Recorded as a comment how exactly, in what format?

> + * The maintainer(s) will update the commit message(s)

what does it mean to "update the commit message"?

> to include
> +   the assigned CVE and issue URL. 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.

And here, included in what format?

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

[Michael S. Tsirkin]

On Thu, Jun 18, 2026 at 04:06:19PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 10:42:15AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 18, 2026 at 02:20:58PM +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>
> > 
> > Thanks for taking on this. One question:
> > 
> > 
> > > ---
> > >  contribute/report-a-bug.md     |   9 +-
> > >  contribute/security-process.md | 309 +++++++++++++++------------------
> > >  2 files changed, 148 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.
> > 
> > 
> > There's a problem here in that confidential marking is later
> > erased. I feel would is benefitial to tag the security bugs
> > in some way that does not go away so easily. Any idea?
> 
> Yes, see this paragraph....
> 
> > > + * If confirmed as a security flaw, a maintainer will add the
> > > +   **"Kind::Security"**, **"Workflow::Confirmed"** and
> > > +   **"CVE::Required"** labels.. The latter indicates the need
> > > +   for a CNA to allocate a CVE.

indeed, thanks

> 
> 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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > + * The maintainer(s) will develop and/or review patch(es)
> > +   for the issue privately, optionally attaching work in
> > +   progress fixes to the GitLab issues.
> 
> attaching how? how do i ask reported to test the fix?
> was easy in the email flow.

You can add arbitrary attachments in gitlab issue comments.

> > All patches must
> > +   include the issue URL in the commit message(s).
> 
> you mean the commit message of the patches I presume?
> there's no commit at that point.

Well I presume the maintainer will have a local git tree
with a work-in-progress commit.

> > The
> > +   **"Workflow::In Progress"** label should be assigned when
> > +   a maintainer starts working on a fix.
> 
> That's a bit heavy, and what is "working" anyway.
> It's an issue tracker not a planning app.
> Don't try to make it one.

Various "Workflow::" labels are already present in our gitlab
instance. We don't use them consistently - this text is just
a pointer that the're there.



> 
> 
> > + * When a CVE is allocated, it must be recorded as a comment on
> > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > +   the **"CVE::Assigned"** label.
> 
> Recorded as a comment how exactly, in what format?

In plain text.

> 
> > + * The maintainer(s) will update the commit message(s)
> 
> what does it mean to "update the commit message"?

The commit message for the patch the maintainer has in their
tree.


> > to include
> > +   the assigned CVE and issue URL. 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.
> 
> And here, included in what format?

The CVE just needs to exist somewhere/anywhere in the commit message.
It is common to put it in the first line, or with tags before SoB
but it doesn't really matter as long as we have a record of it in
the 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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

thanks! sorry probably just me being dense but some things
here I don't get. might be worth clarifying:

On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > + * The maintainer(s) will develop and/or review patch(es)
> > > +   for the issue privately, optionally attaching work in
> > > +   progress fixes to the GitLab issues.
> > 
> > attaching how? how do i ask reported to test the fix?
> > was easy in the email flow.
> 
> You can add arbitrary attachments in gitlab issue comments.
> 
> > > All patches must
> > > +   include the issue URL in the commit message(s).
> > 
> > you mean the commit message of the patches I presume?
> > there's no commit at that point.
> 
> Well I presume the maintainer will have a local git tree
> with a work-in-progress commit.

sorry I don't get it.

what does it have to do with patches then?


who cares about my local tree?

and why is this mentioned twice?










> > > The
> > > +   **"Workflow::In Progress"** label should be assigned when
> > > +   a maintainer starts working on a fix.
> > 
> > That's a bit heavy, and what is "working" anyway.
> > It's an issue tracker not a planning app.
> > Don't try to make it one.
> 
> Various "Workflow::" labels are already present in our gitlab
> instance. We don't use them consistently - this text is just
> a pointer that the're there.
> 

maybe "can be assigned" then?

> 
> > 
> > 
> > > + * When a CVE is allocated, it must be recorded as a comment on
> > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > +   the **"CVE::Assigned"** label.
> > 
> > Recorded as a comment how exactly, in what format?
> 
> In plain text.

yes but in what format? 

> > 
> > > + * The maintainer(s) will update the commit message(s)
> > 
> > what does it mean to "update the commit message"?
> 
> The commit message for the patch the maintainer has in their
> tree.

then you mean "before sending a pull request"?

> 
> > > to include
> > > +   the assigned CVE and issue URL. 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.
> > 
> > And here, included in what format?
> 
> The CVE just needs to exist somewhere/anywhere in the commit message.
> It is common to put it in the first line, or with tags before SoB
> but it doesn't really matter as long as we have a record of it in
> the patch.
> 
> With regards,
> Daniel

Will be really annoying if any tools try to consume this e.g.
to decide what to backport.

I suggest deciding on something for these free text fields,
how important is it to be able to write ❤️❤️❤️CVE-1234💰🔥🎯 really?

> -- 
> |: 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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

On Thu, Jun 18, 2026 at 12:23:46PM -0400, Michael S. Tsirkin wrote:
> thanks! sorry probably just me being dense but some things
> here I don't get. might be worth clarifying:
> 
> On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > > + * The maintainer(s) will develop and/or review patch(es)
> > > > +   for the issue privately, optionally attaching work in
> > > > +   progress fixes to the GitLab issues.
> > > 
> > > attaching how? how do i ask reported to test the fix?
> > > was easy in the email flow.
> > 
> > You can add arbitrary attachments in gitlab issue comments.
> > 
> > > > All patches must
> > > > +   include the issue URL in the commit message(s).
> > > 
> > > you mean the commit message of the patches I presume?
> > > there's no commit at that point.
> > 
> > Well I presume the maintainer will have a local git tree
> > with a work-in-progress commit.
> 
> sorry I don't get it.
> 
> what does it have to do with patches then?
> 
> 
> who cares about my local tree?

If you fix a gitlab issue, the commit must contain the issue URL.
That's normal practice we've followed forever and would now apply
to security fixes too.

> 
> and why is this mentioned twice?

Mentioning twice is a mistake


> > > > The
> > > > +   **"Workflow::In Progress"** label should be assigned when
> > > > +   a maintainer starts working on a fix.
> > > 
> > > That's a bit heavy, and what is "working" anyway.
> > > It's an issue tracker not a planning app.
> > > Don't try to make it one.
> > 
> > Various "Workflow::" labels are already present in our gitlab
> > instance. We don't use them consistently - this text is just
> > a pointer that the're there.
> > 
> 
> maybe "can be assigned" then?

Ok.

> 
> > 
> > > 
> > > 
> > > > + * When a CVE is allocated, it must be recorded as a comment on
> > > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > > +   the **"CVE::Assigned"** label.
> > > 
> > > Recorded as a comment how exactly, in what format?
> > 
> > In plain text.
> 
> yes but in what format?

Literally just  "CVE-2026-1234" anywhere in the commit message as we've
been donig for years.

> > > > + * The maintainer(s) will update the commit message(s)
> > > 
> > > what does it mean to "update the commit message"?
> > 
> > The commit message for the patch the maintainer has in their
> > tree.
> 
> then you mean "before sending a pull request"?

Sure if you want it to be that specific.

> > > > to include
> > > > +   the assigned CVE and issue URL. 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.
> > > 
> > > And here, included in what format?
> > 
> > The CVE just needs to exist somewhere/anywhere in the commit message.
> > It is common to put it in the first line, or with tags before SoB
> > but it doesn't really matter as long as we have a record of it in
> > the patch.
> 
> Will be really annoying if any tools try to consume this e.g.
> to decide what to backport.
> I suggest deciding on something for these free text fields,
> how important is it to be able to write ❤️❤️❤️CVE-1234💰🔥🎯 really?

I don't think we need to document every single little detail
here, just carry on with what we've already been doing for
commits.

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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Thu, Jun 18, 2026 at 05:33:54PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 12:23:46PM -0400, Michael S. Tsirkin wrote:
> > thanks! sorry probably just me being dense but some things
> > here I don't get. might be worth clarifying:
> > 
> > On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > > > + * The maintainer(s) will develop and/or review patch(es)
> > > > > +   for the issue privately, optionally attaching work in
> > > > > +   progress fixes to the GitLab issues.
> > > > 
> > > > attaching how? how do i ask reported to test the fix?
> > > > was easy in the email flow.
> > > 
> > > You can add arbitrary attachments in gitlab issue comments.
> > > 
> > > > > All patches must
> > > > > +   include the issue URL in the commit message(s).
> > > > 
> > > > you mean the commit message of the patches I presume?
> > > > there's no commit at that point.
> > > 
> > > Well I presume the maintainer will have a local git tree
> > > with a work-in-progress commit.
> > 
> > sorry I don't get it.
> > 
> > what does it have to do with patches then?
> > 
> > 
> > who cares about my local tree?
> 
> If you fix a gitlab issue, the commit must contain the issue URL.
> That's normal practice we've followed forever and would now apply
> to security fixes too.

Ah. You want a Fixes: tag maybe? Let's say so pls then.

> > 
> > and why is this mentioned twice?
> 
> Mentioning twice is a mistake
> 
> 
> > > > > The
> > > > > +   **"Workflow::In Progress"** label should be assigned when
> > > > > +   a maintainer starts working on a fix.
> > > > 
> > > > That's a bit heavy, and what is "working" anyway.
> > > > It's an issue tracker not a planning app.
> > > > Don't try to make it one.
> > > 
> > > Various "Workflow::" labels are already present in our gitlab
> > > instance. We don't use them consistently - this text is just
> > > a pointer that the're there.
> > > 
> > 
> > maybe "can be assigned" then?
> 
> Ok.
> 
> > 
> > > 
> > > > 
> > > > 
> > > > > + * When a CVE is allocated, it must be recorded as a comment on
> > > > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > > > +   the **"CVE::Assigned"** label.
> > > > 
> > > > Recorded as a comment how exactly, in what format?
> > > 
> > > In plain text.
> > 
> > yes but in what format?
> 
> Literally just  "CVE-2026-1234" anywhere in the commit message as we've
> been donig for years.

I suspect what we've been doing for years no longer scales or
we'd keep doing what we've been doing?


We desperately need something that is consumable by tooling,
and I just do not see how is a tool going to figure out
"this seems to be unrelated CVE-123" is irrelevant.

Unless we'll feed it to some LLM and hope it's right.

> 
> > > > > + * The maintainer(s) will update the commit message(s)
> > > > 
> > > > what does it mean to "update the commit message"?
> > > 
> > > The commit message for the patch the maintainer has in their
> > > tree.
> > 
> > then you mean "before sending a pull request"?
> 
> Sure if you want it to be that specific.
> 
> > > > > to include
> > > > > +   the assigned CVE and issue URL. 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.
> > > > 
> > > > And here, included in what format?
> > > 
> > > The CVE just needs to exist somewhere/anywhere in the commit message.
> > > It is common to put it in the first line, or with tags before SoB
> > > but it doesn't really matter as long as we have a record of it in
> > > the patch.
> > 
> > Will be really annoying if any tools try to consume this e.g.
> > to decide what to backport.
> > I suggest deciding on something for these free text fields,
> > how important is it to be able to write ❤️❤️❤️CVE-1234💰🔥🎯 really?
> 
> I don't think we need to document every single little detail
> here, just carry on with what we've already been doing for
> commits.
>
> With regards,
> Daniel

If commits are linked to CVEs through issues that's fine. Need to
make that link robust then.

> -- 
> |: 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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Daniel P. Berrangé]

On Thu, Jun 18, 2026 at 12:39:31PM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 18, 2026 at 05:33:54PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 18, 2026 at 12:23:46PM -0400, Michael S. Tsirkin wrote:
> > > thanks! sorry probably just me being dense but some things
> > > here I don't get. might be worth clarifying:
> > > 
> > > On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> > > > On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > > > > + * The maintainer(s) will develop and/or review patch(es)
> > > > > > +   for the issue privately, optionally attaching work in
> > > > > > +   progress fixes to the GitLab issues.
> > > > > 
> > > > > attaching how? how do i ask reported to test the fix?
> > > > > was easy in the email flow.
> > > > 
> > > > You can add arbitrary attachments in gitlab issue comments.
> > > > 
> > > > > > All patches must
> > > > > > +   include the issue URL in the commit message(s).
> > > > > 
> > > > > you mean the commit message of the patches I presume?
> > > > > there's no commit at that point.
> > > > 
> > > > Well I presume the maintainer will have a local git tree
> > > > with a work-in-progress commit.
> > > 
> > > sorry I don't get it.
> > > 
> > > what does it have to do with patches then?
> > > 
> > > 
> > > who cares about my local tree?
> > 
> > If you fix a gitlab issue, the commit must contain the issue URL.
> > That's normal practice we've followed forever and would now apply
> > to security fixes too.
> 
> Ah. You want a Fixes: tag maybe? Let's say so pls then.
> 
> > > 
> > > and why is this mentioned twice?
> > 
> > Mentioning twice is a mistake
> > 
> > 
> > > > > > The
> > > > > > +   **"Workflow::In Progress"** label should be assigned when
> > > > > > +   a maintainer starts working on a fix.
> > > > > 
> > > > > That's a bit heavy, and what is "working" anyway.
> > > > > It's an issue tracker not a planning app.
> > > > > Don't try to make it one.
> > > > 
> > > > Various "Workflow::" labels are already present in our gitlab
> > > > instance. We don't use them consistently - this text is just
> > > > a pointer that the're there.
> > > > 
> > > 
> > > maybe "can be assigned" then?
> > 
> > Ok.
> > 
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > + * When a CVE is allocated, it must be recorded as a comment on
> > > > > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > > > > +   the **"CVE::Assigned"** label.
> > > > > 
> > > > > Recorded as a comment how exactly, in what format?
> > > > 
> > > > In plain text.
> > > 
> > > yes but in what format?
> > 
> > Literally just  "CVE-2026-1234" anywhere in the commit message as we've
> > been donig for years.
> 
> I suspect what we've been doing for years no longer scales or
> we'd keep doing what we've been doing?
> 
> 
> We desperately need something that is consumable by tooling,
> and I just do not see how is a tool going to figure out
> "this seems to be unrelated CVE-123" is irrelevant.

It depends who you mean by "we" here ? From an upstream POV I don't
think we care. We ship fixes in master. While it would be nice to
have stable releases with all security fixes backported, we have
never promised/offered that and with the volume we see, I don't
think we should try to add such a promise either.

IOW, consuming CVE fixes is largely a downstream problem. I'd
recommend they start from the gitlab issues with Kind::Security
and CVE::Assigned tags present, but beyon that its upto them.


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 PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

[Michael S. Tsirkin]

On Thu, Jun 18, 2026 at 05:55:36PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 12:39:31PM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 18, 2026 at 05:33:54PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Jun 18, 2026 at 12:23:46PM -0400, Michael S. Tsirkin wrote:
> > > > thanks! sorry probably just me being dense but some things
> > > > here I don't get. might be worth clarifying:
> > > > 
> > > > On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> > > > > On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > > > > > + * The maintainer(s) will develop and/or review patch(es)
> > > > > > > +   for the issue privately, optionally attaching work in
> > > > > > > +   progress fixes to the GitLab issues.
> > > > > > 
> > > > > > attaching how? how do i ask reported to test the fix?
> > > > > > was easy in the email flow.
> > > > > 
> > > > > You can add arbitrary attachments in gitlab issue comments.
> > > > > 
> > > > > > > All patches must
> > > > > > > +   include the issue URL in the commit message(s).
> > > > > > 
> > > > > > you mean the commit message of the patches I presume?
> > > > > > there's no commit at that point.
> > > > > 
> > > > > Well I presume the maintainer will have a local git tree
> > > > > with a work-in-progress commit.
> > > > 
> > > > sorry I don't get it.
> > > > 
> > > > what does it have to do with patches then?
> > > > 
> > > > 
> > > > who cares about my local tree?
> > > 
> > > If you fix a gitlab issue, the commit must contain the issue URL.
> > > That's normal practice we've followed forever and would now apply
> > > to security fixes too.
> > 
> > Ah. You want a Fixes: tag maybe? Let's say so pls then.
> > 
> > > > 
> > > > and why is this mentioned twice?
> > > 
> > > Mentioning twice is a mistake
> > > 
> > > 
> > > > > > > The
> > > > > > > +   **"Workflow::In Progress"** label should be assigned when
> > > > > > > +   a maintainer starts working on a fix.
> > > > > > 
> > > > > > That's a bit heavy, and what is "working" anyway.
> > > > > > It's an issue tracker not a planning app.
> > > > > > Don't try to make it one.
> > > > > 
> > > > > Various "Workflow::" labels are already present in our gitlab
> > > > > instance. We don't use them consistently - this text is just
> > > > > a pointer that the're there.
> > > > > 
> > > > 
> > > > maybe "can be assigned" then?
> > > 
> > > Ok.
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > + * When a CVE is allocated, it must be recorded as a comment on
> > > > > > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > > > > > +   the **"CVE::Assigned"** label.
> > > > > > 
> > > > > > Recorded as a comment how exactly, in what format?
> > > > > 
> > > > > In plain text.
> > > > 
> > > > yes but in what format?
> > > 
> > > Literally just  "CVE-2026-1234" anywhere in the commit message as we've
> > > been donig for years.
> > 
> > I suspect what we've been doing for years no longer scales or
> > we'd keep doing what we've been doing?
> > 
> > 
> > We desperately need something that is consumable by tooling,
> > and I just do not see how is a tool going to figure out
> > "this seems to be unrelated CVE-123" is irrelevant.
> 
> It depends who you mean by "we" here ? From an upstream POV I don't
> think we care. We ship fixes in master.

Why do we bother with CVE numbers at all then?

> While it would be nice to
> have stable releases with all security fixes backported, we have
> never promised/offered that and with the volume we see, I don't
> think we should try to add such a promise either.
>
> IOW, consuming CVE fixes is largely a downstream problem. I'd
> recommend they start from the gitlab issues with Kind::Security
> and CVE::Assigned tags present, but beyon that its upto them.

Let's say they do it, how do they know the CVE number?

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