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é <[email protected]>
---
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é <[email protected]>
+
+## Handling of disclosures
[...]
