[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About 'qemu-security' mailing list
From: |
P J P |
Subject: |
Re: About 'qemu-security' mailing list |
Date: |
Fri, 18 Sep 2020 12:32:23 +0530 (IST) |
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
- Re: About 'qemu-security' mailing list, (continued)
- Re: About 'qemu-security' mailing list, Daniel P . Berrangé, 2020/09/14
- Re: About 'qemu-security' mailing list, Stefan Hajnoczi, 2020/09/14
- Re: About 'qemu-security' mailing list, P J P, 2020/09/15
- Re: About 'qemu-security' mailing list, Stefan Hajnoczi, 2020/09/16
- Re: About 'qemu-security' mailing list, Peter Maydell, 2020/09/16
- Re: About 'qemu-security' mailing list, Daniel P . Berrangé, 2020/09/16
- Re: About 'qemu-security' mailing list, Thomas Huth, 2020/09/16
- Re: About 'qemu-security' mailing list, Daniel P . Berrangé, 2020/09/16
- Re: About 'qemu-security' mailing list,
P J P <=
- Re: About 'qemu-security' mailing list, P J P, 2020/09/30
- Re: About 'qemu-security' mailing list, Darren Kenny, 2020/09/30