Re: About 'qemu-security' mailing list

[Darren Kenny]

On Thursday, 2020-10-01 at 16:05:58 +0530, P J P wrote:
>   Hello Darren,
>
> +-- On Wed, 30 Sep 2020, Darren Kenny wrote --+
> | While that is true, some aliases have managed to do something here by 
> having 
> | a single key for the alias, and behind the scenes that re-encrypts the 
> | e-mail for each member of that alias (trying to avoid the 'list' term a 
> | little here)
> | 
> | An example of this is the 'distro's list, e.g.: 
> | - https://oss-security.openwall.org/wiki/mailing-lists/distros
>
> * Yes, true. But it accepts non-encrypted reports too IIUC.

I believe so.

I wonder, in the case of non-encrypted reports, it would be better to
suggest that in that case, it would only be an initial contact, no
significant details.

After that some discussion could be done on reproducers, etc on a more
secure list.

>
> * I'm not sure how is the 'behind the scenes re-encryption' workflow for 
>   non-member reporters.
>  
>   - Ex. say 2-3 non-member reporter(s) send an encrypted report with their 
>     public keys.
>

AFAIK the original message needs to be encrypted with a specific key,
which is on the website above - so all reporters would be using that.

>   - A list member triaging such issue, would have to select their individual 
>     keys for each reply.

Maybe, honestly not had to deal with it personally.

>
>
> | If you're looking to announce before a security issue is fixed, it may just 
> | be better to keep it to the qemu-security members, which should try to 
> | include at least 1, if not more, members from interested distros.
>
> * No, I didn't mean an '-announce' list for non-security members. I was more 
>   wondering about how to handle reproducers and other artefacts sent to the
>   list.

The storage of reproducers would indeed be good to have in something
like Gitlab - but that'd require someone to extract it and store it, but
under what naming would be another issue... But really that's behind the
scenes.

>
> * Proposed 'qemu-security' list is meant to have representatives from 
>   downstream QEMU user communities.

Excellent, that would be good.

>
>
> | I know from past kernel security issues, it is still important to a distro 
> | to be able to reproduce any issues if a PoC is provided.
>
> * Yes, that's true. It should be okay in that case to keep the reproducers 
> and 
>   such artefacts on the list then.
>  
>

...

>
> | I would agree that Gitlab may be better here, if it would work - Gitlab
> | can certainly be configured to restrict access to specific projects, but
> | I'm not sure how that would play into logging an issue if you can't even
> | see the project in question as a non-member of the security team.
>
> * True. Reporters may need to open/create GitLab account to report issues.

Hmm, it's here that I think it becomes difficult for everyone to log an
issue, even with an account, you may not be able to log an issue on a
project that is otherwise secured.

>
> To summarise:
> =============
>   - Bugzilla or GitLab issues would entail reporters create an account there 
>     to report issues.
>
>   - On a moderated 'qemu-security' list, even a non-member shall be able to 
>     report issues via email.
>
>   - Many voices have said 'Yes' for a moderated 'qemu-security' list.
>
>   - Whether to have an encrypted list or otherwise, is an open question.
>  
>     + Encrypted list(ex. -distros) is possible. But it accepts non-encrypted 
>       mails too IIUC.
>
>     + Mandatory encryption would entail reporters create/share their keys.  
>       It may become tricky, if reporters are non-members.
>
>   - It should be okay to keep reproducers etc. artefacts on the list..?
>     List archives shall not be publicly accessible.
>
>
> Maybe we could start with a moderated list and improvise as we go forward?

I really think that encryption of the details of a vulnerability is
important, if somehow it gets intercepted - which is not that difficult
with e-mail - then there is the potential for a malicious party to
exploit it before a fix is available to distros, and deployed.

Something that has happened since the Intel Spectre/Meltdown
vulnerabilities were initially brought to light is more communication
between security teams in various orgs. To do this those discussions
have started being done on Keybase, which provides secure chats as well
as secured Git repos.

Has anything like that being considered as the point for subsequent
discussions on issues post the initial disclosure?

Thanks,

Darren.