From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: Security disclosure bulk import to GitLab issues
Date: Fri, 3 Jul 2026 16:19:36 +0100 [thread overview]
Message-ID: <akfTCB3V9311I-w-@redhat.com> (raw)
We recently changed to use the GitLab issue tracker for security
disclosures:
https://www.qemu.org/contribute/security-process/
We have a fairly large number of issues reported to the old
qemu-security mailing list that were either excluded from security
handling due to being under the non-virtualization use case, or
were still awaiting triage in a large backlog.
https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
We made the decision to bulk import every security disclosure
received since March 1st 2026, to GitLab to minimize the chance
that we loose a record of anything.
Everything imported is tagged with the "Imported ➤ Security List"
label.
There are the following rough groupings of imported issues
* Security flaws. These are tagged with the Kind::Security label.
If they have a CVE they will have CVE::Assigned label too.
If they have a fix merged it is recorded in a comment and
the bug has "confidentiality" flag removed
If the fix is still outstanding the issue remains
confidential to project maintainers only.
* Non-security flaws. These are tagged with the Kind::Bug label
which reflects that we have classified them as a non-virt use
case. They have the "confidentiality" flag removed
* Non-triaged disclosures. These will have the 'confidentiality'
flag stil present, restricting visibility to QEMU project
maintainers registered on GitLab. Processing should follow
the security process documented in the first link above.
For any open bugs I will be assigning maintainers if they have a
known gitlab acount which is a member of the QEMU project.
Many of the non-security flaws have previously been forwarded on
to maintainers, and while some may have been fixed since then,
many remain unresolved. Unfortunately we have no record of the
status for non-security flaws, so had to leave the bugs open even
though this is incorrect in some cases.
If a flaw is known to be resolved any maintainer may close the
obsolete bug report. If easily identified, mention any relevant
git commit hash with the fix.
Similarly if an imported disclosure is a duplicate of an existing
issue feel free to close either one of them.
To those whom have notifications enabled for "all issue changes"
on the QEMU project, my apologies for the fact that you just received
about 400 email notifications from GitLab. They all came from a bot
account
security-import (@group_3038080_bot_b37c3b86468ce5250e34f461b13b595a)
Since the import is complete this bot is now disabled and will not send
any further spam.
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 :|
reply other threads:[~2026-07-03 15:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akfTCB3V9311I-w-@redhat.com \
--to=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.