PR#167: Vulnerability Management policy - epel

epel

#167 Vulnerability Management policy

Opened 2 years ago by salimma. Modified 2 years ago

salimma/epel security into main

Michel Alexandre Salim • 2 years ago

ab8c14d

modules/ROOT/nav.adoc

file modified

		`@@ -7,6 +7,7 @@`
		`** xref:epel-policy-incompatible-upgrades.adoc[Incompatible Upgrades]`
		`** xref:epel-policy-scl.adoc[Software Collections (SCL)]`
		`** xref:epel-policy-missing-sub-packages.adoc[Missing RHEL Sub-Packages]`
		`+ ** xref:epel-policy-vuln-mgmt.adoc[Vulnerability Management]`
		`* xref:epel-help.adoc[Helping EPEL]`
		`** xref:epel-qa.adoc[EPEL QA]`
		`** xref:epel-packaging.adoc[Packaging]`

modules/ROOT/pages/epel-policy-vuln-mgmt.adoc

file added

+53

		`@@ -0,0 +1,53 @@`
		`+ include::partial$attributes.adoc[]`
		`+ = EPEL Vulnerability Management Policy`
		`+ :toc:`
		`+`
		`+ [[epel_vuln_mgmt_policy]]`
		`+`
		`+ This document describes the policy for security updates to packages in the EPEL`
		`+ package collection. For general EPEL package guidelines, refer to the`
		`+ xref:epel-policy.adoc[EPEL Guidelines and Policy] page.`
		`+`
		`+ [[cve_review]]`
		`+ == Regular reviews`
		`+ Open CVEs of severity high and above are reviewed by the EPEL`
		`+ Steering Committee on a monthly basis.`
		`+`
		`+ [[triaging_cves]]`
		`+ == Triaging CVEs`
		`+`
		`+ CVEs might not be actionable, for various reasons. This section provides some`
		`+ guidelines for what to do in some of these scenarios.`
		`+`
		`+ * Waiting on upstream`
		+ either set the bug to `ASSIGNED`, or `CLOSE` the bug as `DEFERRED`
		`+ * Tracking bug covers multiple CVEs, and only some are fixed`
		`+ * if you think the remaining CVEs will be addressed soon, push a security`
		`+ update without closing the bug`
		+ * if the ETA for the remaining CVEs is unclear, `CLOSE` as `DEFERRED`
		`+`
		`+`
		`+ [[stalled_cves]]`
		`+ == Stalled CVEs`
		`+`
		`+ There are times that an EPEL package maintainer is not responding to a CVE bug. During the regular CVE reviews, the EPEL Steering Committee has the following options, ordered by intrusiveness:`
		`+`
		`+ * if the CVE is actually addressed in the latest update, note the fixed version`
		`+ and close the bug`
		`+ * if the package should not be in EPEL - see`
tdawson commented 2 years ago What does this mean "should not be in EPEL"? If a package shouldn't be in EPEL, that has nothing to do with CVE checking.
		`+ xref:epel-policy.adoc#policy_for_conflicting_packages[Policy for Confligting`
carlwgeorge commented 2 years ago s/Confligting/Conflicting/
		+ Packages] - retire it and close the bugs (either with `provenpackager` access
		+ or by `NEEDINFO`-ing the bug assignee)
		+ * if the bug seems critical enough, and is actionable, use `provenpackager`
		`+ access to put up an update. The EPEL Packagers SIG or any Steering Committe`
carlwgeorge commented 2 years ago These bullet points seem to be using a mix of sentence fragments and complete sentences. We should stick with doing it one way or the other, with the appropriate capitalization and punctuation.
		`+ member could also follow the`
		`+ xref:epel-policy.adoc#stalled_epel_requests[Stalled EPEL Requests] policy to`
		`+ get access to the package`
		+ * if the bug is critical bug not actionable, same as the above but retire the package - but provide heads up to the maintainer first using `NEEDINFO`
sobek commented 2 years ago I would change (I am not a native English speaker, hence might be wrong): - "critical bug not" to "critical, but not" (or "critical and not") - "above but retire" to "above, but retire" (or "above and retire")
		`+`
		`+ [[related_policies]]`
		`+ == Related Policies`
		`+`
		`+ * xref:epel-policy-updates[EPEL Updates Policy]`
		`+ Note that the policy for xref:epel-policy-updates#stable_releases[stable releases] already allows short-circuiting the notice period for incompatible upgrades, for security issues`
		`+ * xref:epel-policy-incompatible-upgrades[Incompatible upgrades policy]`

modules/ROOT/pages/epel-policy.adoc

file modified

		`@@ -197,6 +197,8 @@`
		`you must, the new version that provides only the fix. Try and avoid`
		`pushing other changes with a security update.`

		`+ See also xref:epel-poilcy-vuln-mgmt.adoc[vulnerability management policy].`
		`+`
		`[[add_more_examples_as_they_show_up]]`
		`== Add more examples as they show up`

salimma commented 2 years ago

Vulnerability Management policy, as part of the discussions around https://pagure.io/epel/issue/159

Signed-off-by: Michel Alexandre Salim salimma@fedoraproject.org

tdawson commented on line 38 of modules/ROOT/pages/epel-policy-vuln-mgmt.adoc 2 years ago

What does this mean "should not be in EPEL"?
If a package shouldn't be in EPEL, that has nothing to do with CVE checking.

salimma commented 2 years ago

What does this mean "should not be in EPEL"?
If a package shouldn't be in EPEL, that has nothing to do with CVE checking.

true, but this actually happened - libvncserver had lots of CVEs, and we only found out and retire it as part of looking at CVEs

sobek commented on line 47 of modules/ROOT/pages/epel-policy-vuln-mgmt.adoc 2 years ago

I would change (I am not a native English speaker, hence might be wrong):
- "critical bug not" to "critical, but not" (or "critical and not")
- "above but retire" to "above, but retire" (or "above and retire")

carlwgeorge commented on line 39 of modules/ROOT/pages/epel-policy-vuln-mgmt.adoc 2 years ago

s/Confligting/Conflicting/

carlwgeorge commented on line 43 of modules/ROOT/pages/epel-policy-vuln-mgmt.adoc 2 years ago

These bullet points seem to be using a mix of sentence fragments and complete sentences. We should stick with doing it one way or the other, with the appropriate capitalization and punctuation.