Hello Dan, Stefan,
+-- On Tue, 17 Nov 2020, Daniel P. Berrangé wrote --+
| On Tue, Nov 17, 2020 at 04:19:42PM +, 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
On Tue, Nov 17, 2020 at 04:19:42PM +, Stefan Hajnoczi wrote:
> On Tue, Nov 17, 2020 at 02:46:12PM +, 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
On Tue, Nov 17, 2020 at 02:46:12PM +, 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.
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
+-- 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.
+-- 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
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.
+-- 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
. 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
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
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
|
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
+-- 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
| |
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
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
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
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 wrote:
>>> I think it's worth investigating whether GitLab Issues can be configured
>>> in a secure-enough way for security bug
On Wed, Sep 16, 2020 at 01:33:38PM +0100, Peter Maydell wrote:
> On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi 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
On Wed, 16 Sep 2020 at 12:10, Stefan Hajnoczi 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
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
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
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
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
On Mon, 14 Sep 2020 at 09:55, Daniel P. Berrangé 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
On Fri, Sep 11, 2020 at 04:51:49PM +0100, Peter Maydell wrote:
> On Fri, 11 Sep 2020 at 15:22, P J P 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.
> >
> >
On 9/11/20 5:51 PM, Peter Maydell wrote:
> On Fri, 11 Sep 2020 at 15:22, P J P 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
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
On Fri, 11 Sep 2020 at 15:22, P J P 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
>
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
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
P J P 于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
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
32 matches
Mail list logo
