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