From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Mauro Matteo Cascella" <mcascell@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Thomas Huth" <thuth@redhat.com>
Subject: Re: RFC: GitLab issues for security disclosures
Date: Thu, 21 May 2026 12:21:01 +0100 [thread overview]
Message-ID: <ag7qndP7ifyiX-BT@redhat.com> (raw)
In-Reply-To: <agxzKzzDOJm1EU_v@redhat.com>
On Tue, May 19, 2026 at 03:26:51PM +0100, Daniel P. Berrangé wrote:
> This needs an issue tracker to cope with & email is not an issue tracker.
> We faked an issue tracker with a shared spreadsheet to prevent us drowning
> these past few months, but this is still not sustainable & probably won't
> ever be.
snip
> We have some options IMHO
>
> 1. Move all security disclosure to GitLab confidential issues
> no disclosures via email
>
> 2. Move AI/fuzzer assisted disclosures to GitLab confidential
> issues, keep human discovered issues on qemu-security list
>
> 3. Move AI/fuzzer assisted disclosures to GitLab public
> issues, keep human discovered issues on qemu-security list
snip
> Some downsides/implications
>
> * Every disclosure in a confidential issue will be visible to every
> maintainer who has joined the qemu-project repo on GitLab. IOW
> that is treating every maintainer as equally trusted.
>
> We do have qemu-security though we could be mailed if someone
> considered their disclosure to be severely impactful but the triage
> team can't make that decision.
>
> * We must NOT grant membership to qemu-project at a Reporter level
> for anyone whom is not an active maintainer. They must be limited
> to the "Guest" role at most.
I did a query
$ glab api --paginate /projects/11167699/members/all | jq '.[].name' | sort > members.txt
$ IFS="
" ; for line in $(cat members.txt | sed -e 's/"//g' ) ; do echo -n "$line: " ; grep $line MAINTAINERS | wc -l ; done | grep ': 0'
Of the results without a match as a maintainer I see
* Qemu Janitor
* stsquad-gitlab-api-access
Bot accounts
* dgibson
* Hanna Czenczek
* MST
False negatives - just name mismatches between gitlab account
and MAINTAINERS files
* Eduardo Habkost
* Juan Quintela
Former maintainers, no longer active in QEMU AFAIK
* Peter Krempa
* Peter Krempa (work)
Libvirt maintainer, added to enable to move bugs between projects
* Anthony Roberts
* Bastian Koppelmann
* Emilio Cota
* Jim MacArthur
* Joaquin de Andres
* Paul Zimmerman
At least 1 code commit, but not maintainers
* Eldon
Provided us some CI hardware for a period of time
* Aihua Liang
* Lars D
Unclear
The former maintainers can probably be removed at this point, given
the length of time that's passed.
If we want to use "Confidential" issues in any way, the question is
whether the rest of the non-maintainers / non-bot accounts should
retain "Reporter" role or be moved to "Guest" role ?
Some contributors may be active enough that they're effectively
maintainers, even if not listed in MAINTAINERS.
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 :|
prev parent reply other threads:[~2026-05-21 11:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 14:26 RFC: GitLab issues for security disclosures Daniel P. Berrangé
2026-05-19 15:18 ` Michael S. Tsirkin
2026-05-19 16:11 ` Daniel P. Berrangé
2026-05-19 16:19 ` Michael S. Tsirkin
2026-05-20 10:25 ` Mauro Matteo Cascella
2026-05-20 15:01 ` Pierrick Bouvier
2026-05-20 15:09 ` Daniel P. Berrangé
2026-05-20 17:33 ` Pierrick Bouvier
2026-05-20 17:39 ` Daniel P. Berrangé
2026-05-20 18:28 ` Warner Losh
2026-05-20 23:14 ` Michael S. Tsirkin
2026-05-21 9:06 ` Daniel P. Berrangé
2026-05-21 12:45 ` Mauro Matteo Cascella
2026-05-21 13:06 ` Daniel P. Berrangé
2026-05-21 13:17 ` Mauro Matteo Cascella
2026-05-21 11:09 ` Alex Bennée
2026-05-21 11:21 ` Daniel P. Berrangé [this message]
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=ag7qndP7ifyiX-BT@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=mcascell@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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.