* About 'qemu-security' list subscription process
@ 2021-01-14 14:03 P J P
2021-01-15 18:10 ` Daniel P. Berrangé
0 siblings, 1 reply; 3+ messages in thread
From: P J P @ 2021-01-14 14:03 UTC (permalink / raw)
To: qemu-devel; +Cc: Michael Tsirkin, Daniel Berrange
Hello,
* We have received quite a few subscription requests for the 'qemu-security'
list in the last few weeks. Majority of them are rejected because we could
not identify the user from merely their email-id.
* I have requested them to send a subscription request email with a 'Self
Introduction' to the list.
* However, some of the subscribers are familiar from the
qemu-devel/oss-security mailing lists. And some are corporate emails like
<secalert@rh.c>
* One of the request is pending (3+) votes/acks for OR against member
subscription.
How do we handle these requests?
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: About 'qemu-security' list subscription process
2021-01-14 14:03 About 'qemu-security' list subscription process P J P
@ 2021-01-15 18:10 ` Daniel P. Berrangé
2021-01-22 13:13 ` P J P
0 siblings, 1 reply; 3+ messages in thread
From: Daniel P. Berrangé @ 2021-01-15 18:10 UTC (permalink / raw)
To: P J P; +Cc: Michael Tsirkin, qemu-devel
On Thu, Jan 14, 2021 at 07:33:32PM +0530, P J P wrote:
> Hello,
>
> * We have received quite a few subscription requests for the 'qemu-security'
> list in the last few weeks. Majority of them are rejected because we could
> not identify the user from merely their email-id.
>
> * I have requested them to send a subscription request email with a 'Self
> Introduction' to the list.
>
> * However, some of the subscribers are familiar from the
> qemu-devel/oss-security mailing lists. And some are corporate emails like
> <secalert@rh.c>
>
> * One of the request is pending (3+) votes/acks for OR against member
> subscription.
>
> How do we handle these requests?
I believe we want to keep the membership of qemu-security reasonably
small. Primarily people who can commit to helping with the initial
triage to identify which specific subsystem maintainers to pull in.
In addition major consumers of QEMU with whom we need to coordinate
choice of disclosure date for embargoed images.
There is obviously a danger to the project if we mistakenly allow
membership from someone who is not acting in interests in the QEMU
project, so I think the bar needs to be reasonably high. IOW ideally
there should be some web of trust whereby some existing member(s)
knows the person/entity who is requesting acces. Other cases would
have to be evaluated case-by-case basis.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-01-22 13:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-14 14:03 About 'qemu-security' list subscription process P J P
2021-01-15 18:10 ` Daniel P. Berrangé
2021-01-22 13:13 ` P J P
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).