PR#231: Critical or High CVE change for incompatible upgrades - epel

epel

#231 Critical or High CVE change for incompatible upgrades

Merged 2 years ago by tdawson. Opened 2 years ago by tdawson.

tdawson/epel high-cve into main

remove discussion point

Troy Dawson • 2 years ago

a40f16b

critical only

Troy Dawson • 2 years ago

73edf86

Initial draft of revision

Troy Dawson • 2 years ago

c54c614

modules/ROOT/pages/epel-policy-incompatible-upgrades.adoc

file modified

+5 -6

		`@@ -24,18 +24,18 @@`
		`(if applicable). Also reference a bug in`
		`xref:index.adoc#communicating_with_epel[Bugzilla] against the`
		`package.`
		`- . Discussion takes place on epel-devel for a minimum period of 1 week`
		`- (need some way to short-circuit this for critical security updates -`
		`- i.e. remote root).`
		`+ . In the case of a critical CVE the maintainer MAY build the package`
		`+ and submit it to bodhi for testing. 'Auto-request stable?' MUST NOT be checked.`
		`+ . Discussion takes place on epel-devel for a minimum period of 1 week.`
		`. Item is added to agenda for discussion at weekly EPEL meeting.`
		`. If a majority of those present at the EPEL meeting concur, the`
		`- incompatible upgrade can be built.`
		`+ incompatible upgrade can be built, if it has not been already.`
		`. At the same time that the update is submitted to bodhi for testing,`
		`the maintainer is responsible for sending e-mail to epel-announce`
		`announcing the incompatible upgrade and specific actions that users must`
		`take in order to continue using the software.`
		`. Package MUST remain in testing for at least 1 week, regardless of`
		`- received karma. In bodhi, 'Auto-request stable?' MUST NOT be checked.`
		`+ received karma. In bodhi, 'Auto-request stable?' MUST NOT be checked.`
		`. When pushing the package to stable, the maintainer MUST send another`
		`e-mail to epel-announce.`

		`@@ -49,7 +49,6 @@`
		`[[discussion_points]]`
		`== Discussion points`

		`- . How to short-circuit process for critical security updates`
		`. Approval process - majority of those present seems to be lax, but`
		`being there's no body such as FESCo in "charge" of EPEL (yes, I realize`
		`that FESCo has oversight, but oversight != make day-to-day decisions`

tdawson commented 2 years ago

In the case of critical and/or high severity CVE's, we may want the incompatible upgrades in testing sooner than a week.

kevin commented 2 years ago

Looks fine to me.

carlwgeorge commented on line 8 of modules/ROOT/pages/epel-policy-incompatible-upgrades.adoc 2 years ago

While security fixes are almost always the reason the committee grants approval for an incompatible update, we could in theory grant approval for other reasons. Instead of saying "If CVE is critical or high severity", how about "In the case of a critical or high severity CVE,"?

carlwgeorge commented 2 years ago

I agree with this adjustment for CVEs that are rated as critical.

I do not think it's justified for CVEs that are only rated as high. The EPEL 7 Will It CVE page currently shows 50 CVE bugs with a high rating. The EPEL 8 Will It CVE page currently shows 29 CVE bugs with a high severity. And this is after a concentrated effort by the CPE EPEL team to close out dozens of CVEs over the last year or so. Many of these CVEs are multiple years old. Waiting a week for the discussion and committee vote is simply not a big deal in the scope of the decade lifecycle of RHEL and thus EPEL. RHEL doesn't even fix all CVEs rated important (roughly the equivalent to NVD's high rating in Red Hat's classification system).

In the case of a rejected incompatible update, if the maintainer has already submitted the change to the epel-testing repo, they will likely need to introduce an epoch in order to undo the update for users who have already applied it. I think we should minimize the likelihood of this situation by limiting this practice to critical rated CVEs only.

tdawson commented 2 years ago

After discussion in the EPEL Steering Committee meeting it was decided to do just critical. I'll get an update to this pull request in a bit.

1 new commit added