All of lore.kernel.org
 help / color / mirror / Atom feed
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 :|



      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.