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

[Darren Kenny]

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.

OK

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

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.

OK.

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

Thanks,

Darren.

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