+-- On Fri, 18 Sep 2020, P J P wrote --+ | +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+ | | Do downstream maintainers want to know about potential security bug reports | | that have not been triaged yet? | | | | Maybe there should there be a pre-announce list for bugs that have been | | triaged? That saves downstream from being spammed with confidential info | | that they probably can't use. | | * I was thinking about that, an '-announce' list could be better. Because | issue reports may come with reproducers (code/scripts/packet dump). And | sharing such reproducers with wide-rs recipients seems risky, not right. | | * Such reproducers shall stay in the list archives forever. It may have some | legal IP related concerns. I'm not sure. ... | | | Anyway, it's unclear to me what the motivation for creating a list and | | changing the process is. Please share your goals and reasoning in more | | detail. | | * Primary motivation is to address the concern that current process limits | community participation. | | * Representatives from downstream QEMU user communities shall be notified | about security issues as and when they come in. | | * 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. | | | | I think it's worth investigating whether GitLab Issues can be configured in | | a secure-enough way for security bug reporting. That way HTTPS is used and | | only GitLab stores the confidential information (this isn't end-to-end | | encryption but seems better than unencrypted SMTP and plaintext emails | | copied across machines). | | +-- On Wed, 16 Sep 2020, Peter Maydell wrote --+ | | Given that we currently use launchpad for bugs we should also look at | | whether launchpad's "private security" bug classification would be useful | | for us (currently such bug reports effectively go to /dev/null but this can | | be fixed). | | | * Bug trackers would entail that reporters must have an account there. They | may create account also, but if/when they become inactive, they'll continue | to receive emails or have access to security bugs. | | A mailing list works more on invite-only basis that way. | | * Bug trackers may also face the current limitation of community participants | not knowing about the issues as and when they come in. | | * So bug trackers need a way to send an email to a -announce/-security list, | sans the reproducer code/scripts/packet dump etc. information. | | * Between LaunchPad and GitLab, I think GitLab is preferable.
Ping...!? -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
