About 'qemu-security' mailing list

About 'qemu-security' mailing list

[P J P]

   Hello all,

Recently while conversing with DanPB this point came up

    -> https://www.qemu.org/contribute/security-process/

* Currently QEMU security team is a handful of individual contacts which
   restricts community participation in dealing with these issues.

* The Onus also lies with the individuals to inform the community about QEMU
   security issues, as they come in.


Proposal: (to address above limitations)
=========

* We set up a new 'qemu-security' mailing list.

* QEMU security issues are reported to this new list only.

* Representatives from various communities subscribe to this list. (List maybe
   moderated in the beginning.)

* As QEMU issues come in, participants on the 'qemu-security' list shall
   discuss and decide about how to triage them further.

Please kindly let us know your views about it. I'd appreciate if you have any 
suggestions/inputs/comments about the same.


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

[Li Qiang]

P J P <ppandit@redhat.com> 于2020年9月11日周五 下午10:21写道：
>
>    Hello all,
>
> Recently while conversing with DanPB this point came up
>
>     -> https://www.qemu.org/contribute/security-process/
>
> * Currently QEMU security team is a handful of individual contacts which
>    restricts community participation in dealing with these issues.
>
> * The Onus also lies with the individuals to inform the community about QEMU
>    security issues, as they come in.
>
>
> Proposal: (to address above limitations)
> =========
>
> * We set up a new 'qemu-security' mailing list.
>
> * QEMU security issues are reported to this new list only.
>
> * Representatives from various communities subscribe to this list. (List maybe
>    moderated in the beginning.)
>
> * As QEMU issues come in, participants on the 'qemu-security' list shall
>    discuss and decide about how to triage them further.
>
> Please kindly let us know your views about it. I'd appreciate if you have any
> suggestions/inputs/comments about the same.

Hi Prasad,
Great idea.

Like other project, sometimes they have two mailing lists.
The first is 'security', this list should contains the core developers.
The second is 'predisclosure', the organization can participate this
lists and discuss the disclosure process.

But as for qemu, most of the security issues doesn't need an embargo date.
I think one 'qemu-security' is ok.  I think this mailing lists can
contain the currently individuals and the some qemu developer
and also some organizations who uses qemu.

Thanks,
Li Qiang


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

[Alexander Bulekov]

Hi Prasad,
A couple questions:
 * I'm guessing this will be a closed list with some application/vetting
   procedure for the participants? (Maybe this is what you mean by
   "moderated" ?)
 * How will the communication be encrypted?
 * Will secalert still be subscribed (for managing CVE ID assignments)?
 * Assuming PGP will be gone, will it be possible to make the "This bug
   is a security vulnerability" button work on Launchpad?
Thanks!
-Alex

On 200911 1950, P J P wrote:
>   Hello all,
> 
> Recently while conversing with DanPB this point came up
> 
>    -> https://www.qemu.org/contribute/security-process/
> 
> * Currently QEMU security team is a handful of individual contacts which
>   restricts community participation in dealing with these issues.
> 
> * The Onus also lies with the individuals to inform the community about QEMU
>   security issues, as they come in.
> 
> 
> Proposal: (to address above limitations)
> =========
> 
> * We set up a new 'qemu-security' mailing list.
> 
> * QEMU security issues are reported to this new list only.
> 
> * Representatives from various communities subscribe to this list. (List maybe
>   moderated in the beginning.)
> 
> * As QEMU issues come in, participants on the 'qemu-security' list shall
>   discuss and decide about how to triage them further.
> 
> Please kindly let us know your views about it. I'd appreciate if you have
> any suggestions/inputs/comments about the same.
> 
> 
> 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

[Alexander Bulekov]

And I forgot to mention that I think it is a great idea :) . Over the past
couple months, I reported a few dozen bugs on launchpad. Even though
many of them are memory-corruptions and might fall under the
"security-bug" label, they could be fixed faster simply because the
reports can reach the maintainer, without a manual triage process.
With more eyes available, it could be possible to report fuzzing bugs,
while sticking to the security process. It would be especially useful as
we are ramping up automated fuzzing on google's oss-fuzz and thinking
about how to handle those reports.
-Alex

On 200911 1140, Alexander Bulekov wrote:
> Hi Prasad,
> A couple questions:
>  * I'm guessing this will be a closed list with some application/vetting
>    procedure for the participants? (Maybe this is what you mean by
>    "moderated" ?)
>  * How will the communication be encrypted?
>  * Will secalert still be subscribed (for managing CVE ID assignments)?
>  * Assuming PGP will be gone, will it be possible to make the "This bug
>    is a security vulnerability" button work on Launchpad?
> Thanks!
> -Alex
> 
> On 200911 1950, P J P wrote:
> >   Hello all,
> > 
> > Recently while conversing with DanPB this point came up
> > 
> >    -> https://www.qemu.org/contribute/security-process/
> > 
> > * Currently QEMU security team is a handful of individual contacts which
> >   restricts community participation in dealing with these issues.
> > 
> > * The Onus also lies with the individuals to inform the community about QEMU
> >   security issues, as they come in.
> > 
> > 
> > Proposal: (to address above limitations)
> > =========
> > 
> > * We set up a new 'qemu-security' mailing list.
> > 
> > * QEMU security issues are reported to this new list only.
> > 
> > * Representatives from various communities subscribe to this list. (List maybe
> >   moderated in the beginning.)
> > 
> > * As QEMU issues come in, participants on the 'qemu-security' list shall
> >   discuss and decide about how to triage them further.
> > 
> > Please kindly let us know your views about it. I'd appreciate if you have
> > any suggestions/inputs/comments about the same.
> > 
> > 
> > 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

[P J P]

  Hello Alex,

+-- On Fri, 11 Sep 2020, Alexander Bulekov wrote --+
|  * I'm guessing this will be a closed list with some application/vetting
|    procedure for the participants? (Maybe this is what you mean by
|    "moderated" ?)

  Yes.

|  * Will secalert still be subscribed (for managing CVE ID assignments)?

  Yes.

|  * How will the communication be encrypted?
|  * Assuming PGP will be gone,

  Few contacts with PGP keys could be made available for encrypted 
communication.

| will it be possible to make the "This bug is a security vulnerability"
| button work on Launchpad?

  Not sure, will have to check about it.

Thank you. (Sorry, I missed to reply here earlier.)
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: About 'qemu-security' mailing list

[Daniel P. Berrangé]

On Fri, Sep 11, 2020 at 07:50:24PM +0530, P J P wrote:
>   Hello all,
> 
> Recently while conversing with DanPB this point came up
> 
>    -> https://www.qemu.org/contribute/security-process/
> 
> * Currently QEMU security team is a handful of individual contacts which
>   restricts community participation in dealing with these issues.
> 
> * The Onus also lies with the individuals to inform the community about QEMU
>   security issues, as they come in.
> 
> 
> Proposal: (to address above limitations)
> =========
> 
> * We set up a new 'qemu-security' mailing list.
> 
> * QEMU security issues are reported to this new list only.
> 
> * Representatives from various communities subscribe to this list. (List maybe
>   moderated in the beginning.)

For libvirt we have the list membership targetted as being nominated
security representatives of any downstream distributor of libvirt.
ie essentially the security people from various OS vendors. Other
members can be considered on a case by case basis if they want to
make their case.

FWIW, we have the libvirt-security list moderated at all times, and
manually approve mails from non-members in order to prevent it being
a spam trap. Manual moderation is not too much of a burden assuming
the rate of CVEs isn't huge !

> * As QEMU issues come in, participants on the 'qemu-security' list shall
>   discuss and decide about how to triage them further.

For libvirt-security, members are required to respect the project's
declared embargo policy. This sets as a 2 week maximum by default,
anything beyond 2 weeks has to be explicitly requested as appropriate
and not have objection from members of the list.  QEMU doesn't set any
explicit default embargo period right now just saying it is via mutual
agreement:

  https://www.qemu.org/contribute/security-process/

this might want to be clarified to set a default expectation, because
with a list of members you won't want to wait for everyone to explicitly
approve a date. You want people to know what to expect as a default
upfront, and only have the discussions in cases which need more time.

I'm not saying QEMU has to be 2 weeks - perhaps just look at a sample
of the past year's CVEs in QEMU and use them as a guide for a reasonable
default period to handle or publish the issues.

> Please kindly let us know your views about it. I'd appreciate if you have
> any suggestions/inputs/comments about the same.

I'm in favour of this, since this is what we have done for libvirt
upstream security response handling, and it has been a clear improvement
on our previous process involving CC'ing individual developers.

It makes the security response process more of a level playing field for
all downstreams QEMU distributors.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: About 'qemu-security' mailing list

[Peter Maydell]

On Fri, 11 Sep 2020 at 15:22, P J P <ppandit@redhat.com> wrote:
> Proposal: (to address above limitations)
> =========
>
> * We set up a new 'qemu-security' mailing list.
>
> * QEMU security issues are reported to this new list only.
>
> * Representatives from various communities subscribe to this list. (List maybe
>    moderated in the beginning.)
>
> * As QEMU issues come in, participants on the 'qemu-security' list shall
>    discuss and decide about how to triage them further.

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 ?

My question is, who decides who's on the qemu-security list?
Is this just "it's the same handful of contacts, but they
have a mailing list for convenience" ? It sounds like you
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" ?

thanks
-- PMM

Re: About 'qemu-security' mailing list

[Philippe Mathieu-Daudé]

On 9/11/20 5:51 PM, Peter Maydell wrote:
> On Fri, 11 Sep 2020 at 15:22, P J P <ppandit@redhat.com> wrote:
>> Proposal: (to address above limitations)
>> =========
>>
>> * We set up a new 'qemu-security' mailing list.
>>
>> * QEMU security issues are reported to this new list only.
>>
>> * Representatives from various communities subscribe to this list. (List maybe
>>    moderated in the beginning.)
>>
>> * As QEMU issues come in, participants on the 'qemu-security' list shall
>>    discuss and decide about how to triage them further.
> 
> 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 ?

I don't think so, as I took care to encrypt a bug report and
received the reply unencrypted =) Not sure this is the default
although, as this was my unique experience following the security
process.

Re: About 'qemu-security' mailing list

[Stefan Hajnoczi]

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

On Mon, Sep 14, 2020 at 09:38:07AM +0200, Philippe Mathieu-Daudé wrote:
> I don't think so, as I took care to encrypt a bug report and
> received the reply unencrypted =) Not sure this is the default
> although, as this was my unique experience following the security
> process.

Hopefully a one-time mistake. Confidentiality is necessary for the
disclosure of security bugs, otherwise users are put at risk.

Stefan

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

Re: About 'qemu-security' mailing list

[Daniel P. Berrangé]

On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote:
> On Fri, 11 Sep 2020 at 15:22, P J P <ppandit@redhat.com> wrote:
> > Proposal: (to address above limitations)
> > =========
> >
> > * We set up a new 'qemu-security' mailing list.
> >
> > * QEMU security issues are reported to this new list only.
> >
> > * Representatives from various communities subscribe to this list. (List maybe
> >    moderated in the beginning.)
> >
> > * As QEMU issues come in, participants on the 'qemu-security' list shall
> >    discuss and decide about how to triage them further.
> 
> 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 ?
> 
> My question is, who decides who's on the qemu-security list?
> Is this just "it's the same handful of contacts, but they
> have a mailing list for convenience" ? It sounds like you
> 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, that is a reasonable description. 

Do we think the current QEMU security process is working well for the
community as a whole in terms of our downstream consumers learning about
security flaws in an appropriate timeframe and manner ?  

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: About 'qemu-security' mailing list

[Peter Maydell]

On Mon, 14 Sep 2020 at 09:55, Daniel P. Berrangé <berrange@redhat.com> wrote:
> Do we think the current QEMU security process is working well for the
> community as a whole in terms of our downstream consumers learning about
> security flaws in an appropriate timeframe and manner ?

That sounds like a question we should be asking our distro contacts,
not guessing at amongst ourselves :-)

Personally, my view is that our current security process is
absolutely useless for anybody who isn't either (a) a distro
(b) using their distro's packaged QEMU (c) big enough to
effectively be acting as their own distro by tracking CVE
announcements and applying patches by hand -- because we don't
produce timely new upstream releases with security fixes.
So unless we want to change that, I think the key question
is "does this process work for the distros?", and I'm happy
if we make adjustments to fix whatever their problems with it
might be.

thanks
-- PMM

Re: About 'qemu-security' mailing list

[Stefan Hajnoczi]

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

On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote:
> It sounds like you
> 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?

Is the goal to include new people who have recently asked to participate?

Is the goal to use an easier workflow than manually sending encrypted
email to a handful of people?

etc

Stefan

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

Re: About 'qemu-security' mailing list

[P J P]

  Hello,

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


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

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

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


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

[Stefan Hajnoczi]

[-- 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 --]

Re: About 'qemu-security' mailing list

[Peter Maydell]

On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> 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).

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

thanks
-- PMM

Re: About 'qemu-security' mailing list

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 01:33:38PM +0100, Peter Maydell wrote:
> On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > 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).
> 
> 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).

Using a bug tracker has the notable advantage over direct email CC's
that if the security triage team needs to pull in a  domain specific
expert, that newly added person can still see the full history of
discussion on the bug.

With individual email CC's, the previous discussions are essentially
a information blackhole until the security triage team is good enough
to forward the full discussion history (this essentially never happens
in IME). Mailing list also has that easy archive access benefit.


Is it possible to setup people to be able to view launchpad private
bugs, without also making them full admins for the QEMU launchpad
project ?

Does launchpad still send clear text email notifications to the
permitted admins for private bugs ? I recall I used to get clear
text emails for private bugs in the past for non-QEMU projects.
This reduces the security benefits of launchpad compared to
email, though it is still a clear win in terms of triage process
most likely.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: About 'qemu-security' mailing list

[Thomas Huth]

On 16/09/2020 15.06, Daniel P. Berrangé wrote:
> On Wed, Sep 16, 2020 at 01:33:38PM +0100, Peter Maydell wrote:
>> On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>> 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).
>>
>> 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).

I've somehow managed to subscribe myself to our private LP bugs, so I
get notified if there is a new one.

> Using a bug tracker has the notable advantage over direct email CC's
> that if the security triage team needs to pull in a  domain specific
> expert, that newly added person can still see the full history of
> discussion on the bug.
> 
> With individual email CC's, the previous discussions are essentially
> a information blackhole until the security triage team is good enough
> to forward the full discussion history (this essentially never happens
> in IME). Mailing list also has that easy archive access benefit.
> 
> Is it possible to setup people to be able to view launchpad private
> bugs, without also making them full admins for the QEMU launchpad
> project ?

Honestly, I'd rather like use to move to the gitlab bug tracker instead
of extending our use of the launchpad tracker. LP is IMHO a really ugly
bug tracking tool.

> Does launchpad still send clear text email notifications to the
> permitted admins for private bugs ? I recall I used to get clear
> text emails for private bugs in the past for non-QEMU projects.

IIRC, yes, the email notifications for the private bugs are still send
without encryption.

 Thomas

Re: About 'qemu-security' mailing list

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 03:25:45PM +0200, Thomas Huth wrote:
> On 16/09/2020 15.06, Daniel P. Berrangé wrote:
> > Using a bug tracker has the notable advantage over direct email CC's
> > that if the security triage team needs to pull in a  domain specific
> > expert, that newly added person can still see the full history of
> > discussion on the bug.
> > 
> > With individual email CC's, the previous discussions are essentially
> > a information blackhole until the security triage team is good enough
> > to forward the full discussion history (this essentially never happens
> > in IME). Mailing list also has that easy archive access benefit.
> > 
> > Is it possible to setup people to be able to view launchpad private
> > bugs, without also making them full admins for the QEMU launchpad
> > project ?
> 
> Honestly, I'd rather like use to move to the gitlab bug tracker instead
> of extending our use of the launchpad tracker. LP is IMHO a really ugly
> bug tracking tool.

I assume you mean here moving to use GitLab for *all* bug tracking,
not merely security bug tracking ? I don't think it would be sane
to split our process across different bug trackers.

I have no love for LP, so wouldn't disagree with a move to GitLab,
especially if we're intending to expand its usage for other parts
of QEMU project infrastructure. If we ever use it as the canonical
git repo host, then I'd say using its bug tracker too is pretty
much a no-brainer.

> > Does launchpad still send clear text email notifications to the
> > permitted admins for private bugs ? I recall I used to get clear
> > text emails for private bugs in the past for non-QEMU projects.
> 
> IIRC, yes, the email notifications for the private bugs are still send
> without encryption.



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

Re: About 'qemu-security' mailing list

[P J P]

+-- On Fri, 18 Sep 2020, P J P wrote --+
| +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+
| | 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.
...
|  
| | 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.


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

Re: About 'qemu-security' mailing list

[Darren Kenny]

Hi Prasad,

Just my 2c as someone working on a downstream distro with Qemu...

On Friday, 2020-09-18 at 12:32:23 +0530, P J P wrote:
>   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.
>

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

>
> | 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 believe there was some resistance in the Linux kernel security space
of having things like a pre-announce message of a security issue that
has come in but is not fixed yet...

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

There are some existing mechanisms for announcing security issues once
found, e.g. oss-security:

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

A lot of distros have people on this list already monitoring it and many
OSS projects do send announcements of CVEs and security issues to this,
once resolved and an embargo period has expired - including Qemu, as I'm
sure that you know, given I've seen postings from you (Prasad) there.

Why would this not be enough for that?

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

These are all very important points - and the need for an embargo period
can be vital where Qemu/KVM is being widely deployed in a company.

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

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.

But I don't really know the internal workings of Gitlab, maybe there is
a way to do it.

Thanks,

Darren.

Re: About 'qemu-security' mailing list

[P J P]

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

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


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

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


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

| There are some existing mechanisms for announcing security issues once 
| found, e.g. oss-security:
| 
| - https://oss-security.openwall.org/wiki/mailing-lists/oss-security
| 
| A lot of distros have people on this list already monitoring it and many OSS 
| projects do send announcements of CVEs and security issues to this, once 
| resolved and an embargo period has expired - including Qemu, as I'm sure 
| that you know, given I've seen postings from you (Prasad) there.
| 
| Why would this not be enough for that?

* Yes, that is a fine, working means of public announcements. We currently use 
  the same.


| > * 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.
| 
| These are all very important points - and the need for an embargo period
| can be vital where Qemu/KVM is being widely deployed in a company.
... 
| | * Between LaunchPad and GitLab, I think GitLab is preferable.

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


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?


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

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

Re: About 'qemu-security' mailing list

[Konrad Rzeszutek Wilk]

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

.. I found out yesterday that most of the emails around the world are
using TLS which does remove the interception part. The attack is then
to get on say Prasad's box .. and if you do that it really does not
matter if you use encryption or not.

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

The problem with Keybase was how to review patches. Now if they had a
encrypted mailing list as part of their Git repos that would be awesome.
(Trying to find a "Feature request" but not having much luck :-()

Re: About 'qemu-security' mailing list

[P J P]

+-- On Thu, 1 Oct 2020, Darren Kenny wrote --+
| 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.

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

  Encrypted list, open to receive non-encrypted reports seems okay. Will have 
to check how to set it up and its workflow.
 
| 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?

  That has not come up for QEMU issues yet. Maybe we could consider it in 
future if required.

+-- On Thu, 1 Oct 2020, Konrad Rzeszutek Wilk wrote --+
| The problem with Keybase was how to review patches. Now if they had a 
| encrypted mailing list as part of their Git repos that would be awesome. 
| (Trying to find a "Feature request" but not having much luck :-()

 True. Email + PGP/GPG has been around for so many years, yet there is no 
seamless combination of the two. :(

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

[P J P]

  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

Re: About 'qemu-security' mailing list

[P J P]

+-- On Fri, 16 Oct 2020, P J P wrote --+
| * 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?

Ping..! (just checking; probably folks are buys with KVMForum I guess)
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

Re: About 'qemu-security' mailing list

[P J P]

+-- On Tue, 20 Oct 2020, P J P wrote --+
| +-- On Fri, 16 Oct 2020, P J P wrote --+
| | * 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?
|

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

Re: About 'qemu-security' mailing list

[Stefan Hajnoczi]

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

On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote:

I have CCed everyone from the Security Process wiki page so they can
participate in discussing changes to the process.

> * 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?

Writing/maintaining automation tools will take time so I suggest going
with confidential GitLab Issues instead:
https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html

If you would like to test GitLab Issues, please post your username and
you will be given the "Reporter" role so you can view confidential
issues.

I have created a confidential issue here (you'll get 404 if you don't
have permissions to view it):
https://gitlab.com/qemu-project/qemu/-/issues/2

The intention is to migrate QEMU's bug tracker from Launchpad to GitLab
so this will unify reporting regular bugs and security bugs. It also
uses encryption all the time instead of relying on users explicitly
encrypting emails.

Stefan

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

Re: About 'qemu-security' mailing list

[Stefan Hajnoczi]

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

On Tue, Nov 17, 2020 at 02:46:12PM +0000, Stefan Hajnoczi wrote:
> On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote:
> 
> I have CCed everyone from the Security Process wiki page so they can
> participate in discussing changes to the process.
> 
> > * 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?
> 
> Writing/maintaining automation tools will take time so I suggest going
> with confidential GitLab Issues instead:
> https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html
> 
> If you would like to test GitLab Issues, please post your username and
> you will be given the "Reporter" role so you can view confidential
> issues.
> 
> I have created a confidential issue here (you'll get 404 if you don't
> have permissions to view it):
> https://gitlab.com/qemu-project/qemu/-/issues/2
> 
> The intention is to migrate QEMU's bug tracker from Launchpad to GitLab
> so this will unify reporting regular bugs and security bugs. It also
> uses encryption all the time instead of relying on users explicitly
> encrypting emails.

Dan and I tried out confidential issues and unfortunately it is
currently too limited for our workflow.

It is not possible to add non-members to a confidential issue. Members
need at least the 'Reporter' role to view confidential issues, and then
they can view all of them (!).

This means there is no way of working on a need-to-know basis. We would
have to give anyone who ever needs to comment on an issue access to all
other issues :(.

Dan found this open feature request from 2 years ago:
https://gitlab.com/gitlab-org/gitlab/-/issues/20252

For now I think we should stick to email. I'm still concerned about the
prospect of writing custom mailing list software and hosting it
somewhere. Can we run an encrypted mailing list without developing the
software ourselves?

Stefan

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

Re: About 'qemu-security' mailing list

[Daniel P. Berrangé]

On Tue, Nov 17, 2020 at 04:19:42PM +0000, Stefan Hajnoczi wrote:
> On Tue, Nov 17, 2020 at 02:46:12PM +0000, Stefan Hajnoczi wrote:
> > On Fri, Oct 16, 2020 at 07:47:01PM +0530, P J P wrote:
> > 
> > I have CCed everyone from the Security Process wiki page so they can
> > participate in discussing changes to the process.
> > 
> > > * 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?
> > 
> > Writing/maintaining automation tools will take time so I suggest going
> > with confidential GitLab Issues instead:
> > https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html
> > 
> > If you would like to test GitLab Issues, please post your username and
> > you will be given the "Reporter" role so you can view confidential
> > issues.
> > 
> > I have created a confidential issue here (you'll get 404 if you don't
> > have permissions to view it):
> > https://gitlab.com/qemu-project/qemu/-/issues/2
> > 
> > The intention is to migrate QEMU's bug tracker from Launchpad to GitLab
> > so this will unify reporting regular bugs and security bugs. It also
> > uses encryption all the time instead of relying on users explicitly
> > encrypting emails.
> 
> Dan and I tried out confidential issues and unfortunately it is
> currently too limited for our workflow.
> 
> It is not possible to add non-members to a confidential issue. Members
> need at least the 'Reporter' role to view confidential issues, and then
> they can view all of them (!).
> 
> This means there is no way of working on a need-to-know basis. We would
> have to give anyone who ever needs to comment on an issue access to all
> other issues :(.
> 
> Dan found this open feature request from 2 years ago:
> https://gitlab.com/gitlab-org/gitlab/-/issues/20252
> 
> For now I think we should stick to email. I'm still concerned about the
> prospect of writing custom mailing list software and hosting it
> somewhere. Can we run an encrypted mailing list without developing the
> software ourselves?

We certainly should NOT get into the business of writing or hosting
custom solutions ourselves IMHO. Even if someone volunteers to do the
work upfront, that'll inevitably turn into abandonware a few years
hence when the interested party moves onto other things.

I still question whether we genuinely need encrypted mailing lists in
the first place.

Our of all the security reports QEMU has received how many reporters
actually used GPG to encrypt their reporters, and how often did the
security team actually keep using GPG when triaging and resolving it
thereafter.

Out of countless security issues I've dealt with across many software
projects for 10 years, there have been less than 5 occassions where
encryption was used with email by a bug reporter notifying me, and out
of those only 1 of them actually justified the use of GPG.

For projects that did use confidential issues, they still all emailed
notifications in clear text behind the scenes regardless.

Is it not sufficient to just use a regular mailing list by default,
and continue publish security team pgp email addrs + keys for the
few cases where pgp might be desired.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: About 'qemu-security' mailing list

[P J P]

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

  Hello Dan, Stefan,

+-- On Tue, 17 Nov 2020, Daniel P. Berrangé wrote --+
| On Tue, Nov 17, 2020 at 04:19:42PM +0000, Stefan Hajnoczi wrote:
| > Dan and I tried out confidential issues and unfortunately it is
| > currently too limited for our workflow.
| > 
| > It is not possible to add non-members to a confidential issue. Members
| > need at least the 'Reporter' role to view confidential issues, and then
| > they can view all of them (!).
| > 
| > This means there is no way of working on a need-to-know basis. We would
| > have to give anyone who ever needs to comment on an issue access to all
| > other issues :(.
| > 
| > Dan found this open feature request from 2 years ago:
| > https://gitlab.com/gitlab-org/gitlab/-/issues/20252
| > 
| > For now I think we should stick to email.

  I think email is best and easiest for all.

| > I'm still concerned about the prospect of writing custom mailing list 
| > software and hosting it somewhere. Can we run an encrypted mailing list 
| > without developing the software ourselves?
| 
| We certainly should NOT get into the business of writing or hosting
| custom solutions ourselves IMHO. Even if someone volunteers to do the
| work upfront, that'll inevitably turn into abandonware a few years
| hence when the interested party moves onto other things.

* I don't know of any list provider which supports encryption.

* For custom software, there is this 'schleuder' project

   -> https://0xacab.org/schleuder/schleuder
   -> https://schleuder.org/schleuder/docs/concept.html
      A gpg-enabled mailing list manager with resending-capabilities.  

* I have not used it or played with it.


| I still question whether we genuinely need encrypted mailing lists in
| the first place.
| 
| Our of all the security reports QEMU has received how many reporters
| actually used GPG to encrypt their reporters, and how often did the
| security team actually keep using GPG when triaging and resolving it
| thereafter.
| 
| Out of countless security issues I've dealt with across many software
| projects for 10 years, there have been less than 5 occassions where
| encryption was used with email by a bug reporter notifying me, and out
| of those only 1 of them actually justified the use of GPG.
| 
| For projects that did use confidential issues, they still all emailed
| notifications in clear text behind the scenes regardless.
|
| Is it not sufficient to just use a regular mailing list by default,
| and continue publish security team pgp email addrs + keys for the
| few cases where pgp might be desired.

* True, need & usage of encryption is debatable and difficult.

* Above points and possible solution of keeping the current handful PGP keys 
  available did come up earlier

  -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05213.html


* At this point I think, let's get started with a regular list for now. We can 
  still continue to explore encryption support options.


@Stefanha: do we need to file a request ticket to create 'qemu-security' list?


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