Re: About 'qemu-security' mailing list

[P J P]

  Hello all,

+-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+
| I'm surprised the lack of encryption doesn't bother you. The security bug 
| reporting process should be confidential to prevent disclosure of 0-days.

* I think it'll work only if all issue reports are encrypted. Under current 
  process, we've our GPG keys published, yet majority of the issue reports are 
  unencrypted. CVEs are of more interest/incentive.

* Encrypted email workflow is also not as seamless as unencrypted.


| Triaging and fixing are different things. Where is the bottleneck, triaging 
| or fixing?

* Issue triaging/analysis is lesser time; Patches may take longer, so fixing.

* But having mailing-list isn't going to affect/address either.


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


| I don't think a broadcast model works well for assigning responsibility. If 
| maintainers constantly receive security-related emails (most of which don't 
| affect them), they will ignore them. This is what happens with broadcast CI 
| and fuzzing results.
| 
| Instead someone should assign security bug reports to relevant maintainers.
| 
| Another option is to let reporters directly contact the maintainers (e.g. 
| QEMU's MAINTAINERS file), but this is hard to get right and if a maintainer 
| is on vacation the report may go unnoticed.

* True, agree.

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



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