About 'qemu-security' list subscription process

About 'qemu-security' list subscription process

[P J P]

   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

Re: About 'qemu-security' list subscription process

[Daniel P. Berrangé]

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 :|

Re: About 'qemu-security' list subscription process

[P J P]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

+-- On Fri, 15 Jan 2021, Daniel P. Berrangé wrote --+
| 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.

* True, sounds reasonable. I'll probably start a thread on the -sec list for 
  pending requests.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D