qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About 'qemu-security' mailing list


From: Stefan Hajnoczi
Subject: Re: About 'qemu-security' mailing list
Date: Tue, 17 Nov 2020 16:19:42 +0000

On Tue, Nov 17, 2020 at 02:46:12PM +0000, Stefan Hajnoczi wrote:
> On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote:
> 
> I have CCed everyone from the Security Process wiki page so they can
> participate in discussing changes to the process.
> 
> > * So ie. we need to:
> > 
> >   1. Create/setup a regular non-encrypted 'qemu-security' list.
> > 
> >   2. Invite representatives from user/downstream communities to subscribe 
> > to 
> >      it.
> > 
> >   3. Collect & store their PGP public keys. Also create a key for the list.
> > 
> >   4. Write 'encrypt & email' automation tool(s) to provide encryption 
> > support.
> > 
> >   5. Document and publish above details and list workflow on a page.
> > 
> > 
> > ...wdyt?
> 
> Writing/maintaining automation tools will take time so I suggest going
> with confidential GitLab Issues instead:
> https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html
> 
> If you would like to test GitLab Issues, please post your username and
> you will be given the "Reporter" role so you can view confidential
> issues.
> 
> I have created a confidential issue here (you'll get 404 if you don't
> have permissions to view it):
> https://gitlab.com/qemu-project/qemu/-/issues/2
> 
> The intention is to migrate QEMU's bug tracker from Launchpad to GitLab
> so this will unify reporting regular bugs and security bugs. It also
> uses encryption all the time instead of relying on users explicitly
> encrypting emails.

Dan and I tried out confidential issues and unfortunately it is
currently too limited for our workflow.

It is not possible to add non-members to a confidential issue. Members
need at least the 'Reporter' role to view confidential issues, and then
they can view all of them (!).

This means there is no way of working on a need-to-know basis. We would
have to give anyone who ever needs to comment on an issue access to all
other issues :(.

Dan found this open feature request from 2 years ago:
https://gitlab.com/gitlab-org/gitlab/-/issues/20252

For now I think we should stick to email. I'm still concerned about the
prospect of writing custom mailing list software and hosting it
somewhere. Can we run an encrypted mailing list without developing the
software ourselves?

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]