Re: About 'qemu-security' mailing list

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3502 bytes --]

On Tue, Sep 15, 2020 at 04:18:47PM +0530, P J P wrote:
> +-- On Fri, 11 Sep 2020, Peter Maydell wrote --+
> | Way way back, the idea of a qemu-security list was proposed, and it was 
> | decided against because there wasn't a clear way that people could send 
> | encrypted mail to the security team if it was just a mailing list. So that's 
> | why we have the "handful of individual contacts" approach. Is that still 
> | something people care about ?
> 
> * So far issue reports have mostly been unencrypted.
> 
> * All issue reports may not need encryption.
> 
> * If someone still wants to send an encrypted report, few contacts with their 
>   GPG keys could be made available, as is available now.

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'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 Mon, 14 Sep 2020, Stefan Hajnoczi wrote --+
> | On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote:
> | > want it to be a larger grouping than that and maybe also want to use it as 
> | > a mechanism for informing downstream distros etc about QEMU security 
> | > issues, which is to say you're proposing an overhaul and change to our 
> | > security process, not merely "we'd like to create a mailing list" ?
> | 
> | Yes, please discuss the reasons for wanting a mailing list:
> | 
> | Is the goal to involve more people in triaging CVEs in a timely manner?
> 
>   This will be welcome for fix patches.

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

> | Is the goal to include new people who have recently asked to participate?
> 
>   We've not received such request yet.
> 
> | Is the goal to use an easier workflow than manually sending encrypted
> | email to a handful of people?
> 
> * Current proposal is more for enabling communities and downstream distros to 
>   know about the issues as and when they are reported. Ie. heads-up mechanism.
> 
>   Just to note, we've not received any request for such notifications.

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.

> * If maintainers are on this list, that could help with the triage and fix 
>   patches.

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.

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.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]