Re: About 'qemu-security' mailing list

[Daniel P . Berrangé]

On Tue, Nov 17, 2020 at 04:19:42PM +0000, Stefan Hajnoczi wrote:
> 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?

We certainly should NOT get into the business of writing or hosting
custom solutions ourselves IMHO. Even if someone volunteers to do the
work upfront, that'll inevitably turn into abandonware a few years
hence when the interested party moves onto other things.

I still question whether we genuinely need encrypted mailing lists in
the first place.

Our of all the security reports QEMU has received how many reporters
actually used GPG to encrypt their reporters, and how often did the
security team actually keep using GPG when triaging and resolving it
thereafter.

Out of countless security issues I've dealt with across many software
projects for 10 years, there have been less than 5 occassions where
encryption was used with email by a bug reporter notifying me, and out
of those only 1 of them actually justified the use of GPG.

For projects that did use confidential issues, they still all emailed
notifications in clear text behind the scenes regardless.

Is it not sufficient to just use a regular mailing list by default,
and continue publish security team pgp email addrs + keys for the
few cases where pgp might be desired.

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