Re: About 'qemu-security' mailing list

[P J P]

  Hello Darren,

+-- On Wed, 30 Sep 2020, Darren Kenny wrote --+
| While that is true, some aliases have managed to do something here by having 
| a single key for the alias, and behind the scenes that re-encrypts the 
| e-mail for each member of that alias (trying to avoid the 'list' term a 
| little here)
| 
| An example of this is the 'distro's list, e.g.: 
| - https://oss-security.openwall.org/wiki/mailing-lists/distros

* Yes, true. But it accepts non-encrypted reports too IIUC.

* I'm not sure how is the 'behind the scenes re-encryption' workflow for 
  non-member reporters.
 
  - Ex. say 2-3 non-member reporter(s) send an encrypted report with their 
    public keys.

  - A list member triaging such issue, would have to select their individual 
    keys for each reply.


| If you're looking to announce before a security issue is fixed, it may just 
| be better to keep it to the qemu-security members, which should try to 
| include at least 1, if not more, members from interested distros.

* No, I didn't mean an '-announce' list for non-security members. I was more 
  wondering about how to handle reproducers and other artefacts sent to the
  list.

* Proposed 'qemu-security' list is meant to have representatives from 
  downstream QEMU user communities.


| I know from past kernel security issues, it is still important to a distro 
| to be able to reproduce any issues if a PoC is provided.

* Yes, that's true. It should be okay in that case to keep the reproducers and 
  such artefacts on the list then.
 

| There are some existing mechanisms for announcing security issues once 
| found, e.g. oss-security:
| 
| - https://oss-security.openwall.org/wiki/mailing-lists/oss-security
| 
| A lot of distros have people on this list already monitoring it and many OSS 
| projects do send announcements of CVEs and security issues to this, once 
| resolved and an embargo period has expired - including Qemu, as I'm sure 
| that you know, given I've seen postings from you (Prasad) there.
| 
| Why would this not be enough for that?

* Yes, that is a fine, working means of public announcements. We currently use 
  the same.


| > * These representatives then decide if an issue can be readily disclosed 
and 
| >   discussed on the public 'qemu-devel' list OR needs to go through an 
embargo 
| >   process.
| 
| These are all very important points - and the need for an embargo period
| can be vital where Qemu/KVM is being widely deployed in a company.
... 
| | * Between LaunchPad and GitLab, I think GitLab is preferable.

| I would agree that Gitlab may be better here, if it would work - Gitlab
| can certainly be configured to restrict access to specific projects, but
| I'm not sure how that would play into logging an issue if you can't even
| see the project in question as a non-member of the security team.

* True. Reporters may need to open/create GitLab account to report issues.


To summarise:
=============
  - Bugzilla or GitLab issues would entail reporters create an account there 
    to report issues.

  - On a moderated 'qemu-security' list, even a non-member shall be able to 
    report issues via email.

  - Many voices have said 'Yes' for a moderated 'qemu-security' list.

  - Whether to have an encrypted list or otherwise, is an open question.
 
    + Encrypted list(ex. -distros) is possible. But it accepts non-encrypted 
      mails too IIUC.

    + Mandatory encryption would entail reporters create/share their keys.  
      It may become tricky, if reporters are non-members.

  - It should be okay to keep reproducers etc. artefacts on the list..?
    List archives shall not be publicly accessible.


Maybe we could start with a moderated list and improvise as we go forward?


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