[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 1/1] security-process: update process information

From: Darren Kenny
Subject: Re: [RFC 1/1] security-process: update process information
Date: Wed, 25 Nov 2020 14:44:42 +0000

On Wednesday, 2020-11-25 at 18:18:56 +0530, P J P wrote:
>   Hello Darren, all
> +-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
> | I always understood triage to be the initial steps in assessing a bug:
> | 
> | - determining if it is a security bug, in this case
> | - then deciding on the severity of it
> |
> | I would not expect triage to include seeing it through to the point
> | where there is a fix as in the steps above and as such that definition
> | of triage should probably have a shorter time frame.
> * Yes, initial triage is to determine if a given issue is a security one and 
>   its impact if so.

Sounds good.

> * After above step, an upstream bug (or GitLab issue) shall be filed if the
>   issue can be made public readily and does not need an embargo period.


> * Following step about creating a patch is needed considering the influx of 
>   these issues. If such a patch is not proposed at this time, we risk having 
>   numerous CVE bugs open and unfixed without a patch.
> * Sometimes proposed patches take long time to get merged upstream. Hence the 
>   60 days time frame.

Absolutely understand that.

> * It does not mean issue report will remain private for 60 days, nope.

OK, it is not the embargo period then, got it.

> | But, if it is a security bug - then that is when the next steps would be
> | taken, to (not necessarily in this order):
> | 
> | - negotiate an embargo (should the predefined 60 days be insufficient)
> |
> |   - don't know if you need to mention that this would include downstream
> |     in this too, since they will be the ones most likely to need the
> |     time to distribute a fix
> * Embargo period is negotiated for important/critical issues. Such embargo 
>   period is generally not more than 2 weeks.

I always thought that the purpose of an embargo period was to enable
downstream to have patches available and ready for distribution, and
preferably distributed already if its something a malicious guest could
use. In that case 2 weeks seems like a pretty short time-frame for all
of that to be completed, especially if it is something that could be
exploitable as soon as the patch lands and is thus visible in upstream

But I guess the negotiation would iron that out at the time, so it's
probably OK to default to 2 weeks.

> * Yes, embargo process includes notifying various downstream communities 
> about 
>   the issue, its fix(es) and co-ordinating disclosure.


> | - request a CVE
> | - create a fix for upstream
> |   - distros can work on bringing that back into downstream as needed,
> |     within the embargo period
> | 
> | I do feel that it is worth separating the 2 phases of triage and beyond,
> | but of course that is only my thoughts on it, I'm sure others will have
> | theirs.
> * Yes, I appreciate it, thanks so much for sharing.
> * This patch is to get the qemu-security list up and running. I'll refine the 
>   process further with above/more details as we start using it. Hope that's 
>   okay.

OK, since it was an RFC I didn't think it was the actual patch yet, just
looking for comments ;-)

I'm alright if it gets ironed out more after...



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]