Re: About 'qemu-security' mailing list

[P J P]

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