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

[P J P]

  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.

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

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


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

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


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