Re: About 'qemu-security' mailing list

[P J P <ppandit@redhat.com>]

  Hello Darren, all

+-- On Thu, 1 Oct 2020, Darren Kenny wrote --+
| On Thursday, 2020-10-01 at 16:05:58 +0530, P J P wrote:
| > - 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.

  "Ideally, encrypt all of your messages to their (possibly multiple) 
   recipients. This means that you need not only the list's public key, but 
   also keys for the reporter and for anyone else CC'ed. You may exercise your 
   best effort to obtain such keys (from keyservers, by asking in the thread in 
   plaintext without quoting any sensitive content, etc.), or failing that you 
   may fallback to plaintext, in which case you should refrain from quoting 
   (and adding) non-essential sensitive content. For example, if you merely 
   want the reporter to agree to or specify a public disclosure date, then you 
   may send a plaintext message back to them with this request and nothing else 
   (most importantly, do not quote their original report)."

  -> https://oss-security.openwall.org/wiki/mailing-lists/distros

* Found above text for encrypted email workflow to communicate with non-member
  reporters.


+-- On Thu, 1 Oct 2020, P J P wrote --+
| Encrypted list, open to receive non-encrypted reports seems okay. Will have 
| to check how to set it up and its workflow.

* I reached out to '@solardiz' to check if the back end scripts/tools which 
  power automatic encryption on '-distros' list are available as open source 
  tools.

  Unfortunately not.

* As his suggestions/inputs for a list, he said:

  >On Friday, 9 October, 2020, 12:15:37 am IST, Solar Designer wrote:
  >
  > my biggest concern is that issues discussed there or reproducers for them 
  > might stay unpublished for very long, and would be a lucrative target.
  > I think a more important than encryption property of the distros list is 
  > that we impose a maximum embargo time, and have requirements on 
  > publication of exploits too if those were provided.
  >

* So ie. we need to:

  1. Create/setup a regular non-encrypted 'qemu-security' list.

  2. Invite representatives from user/downstream communities to subscribe to 
     it.

  3. Collect & store their PGP public keys. Also create a key for the list.

  4. Write 'encrypt & email' automation tool(s) to provide encryption support.

  5. Document and publish above details and list workflow on a page.


...wdyt?


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