On Friday, February 19, 2021 1:30 PM, Josh Boyer jwboyer@redhat.com wrote:
On Fri, Feb 19, 2021 at 12:48 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Wednesday, February 17, 2021 9:01 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, Feb 17, 2021 at 8:09 PM Naoto Kobayashi naoto.kobayashi4c@gmail.com wrote:
Dear community, I would like to ask a following question:
- How are CVEs handled in CentOS Stream? The answer in faq page (https://centos.org/distro-faq) states that security issues will be updated in CentOS Stream after they are solved in the current RHEL release. However, CentOS Steam 8 solved CVE-2020-15437 (kernel) while RHEL 8 has not (as of February 17,2021). Does the order of security updates between RHEL and CentOS Stream depend on the situation?
There's a bit of nuance to this question in that policy states that CVEs should be fixed in RHEL before CentOS Stream. However, there are a couple of practical problems this introduces that we work around by shipping in CentOS Stream first. For example, we may do a rebase that contains a CVE fix. Everyone universally agrees we don't want Red Hat engineering CVE vulnerabilities back into CentOS Stream that may have been fixed by a rebase. In this scenario, a CVE fix may go out in Stream before a RHEL release. There are also some scenarios around lower and moderate CVEs where we run into practical issues maintaining a "RHEL" patchset and a "CentOS Stream" patchset. In that scenario a CVE might get fixed in CentOS Stream first.
Is that policy still what is best for Red Hat in the long term. Staf Walter wrote on the CentOS blog that: "Back in July, a RHEL (and CentOS) fix for the 'boot hole' vulnerabilities ended up being far worse than the CVE itself: it caused many systems not to boot." It seems to be implied even after Stream gets fully going that Red Hat will continue to induce CVE patch related regressions (such as "Boot Hole") on RHEL users first.
We indeed had mistakes with that particular CVE, and are working to address the causes of those mistakes. The implication that it will be a repeated pattern is presumptuous. However, the burden to improve is on us so we'll own that and put our efforts and focus into improvement.
Is there the assumption that Stream CD/CI testing contributors will also be at least running some RHEL instances in addition to Stream since RHEL has 16 "free" licenses?
They may. There is no assumption on our part that they will.
How long of a delay should we expect between the time CVE changes are applied to RHEL til the point they are available to Stream? For purposes of CD/CI it would be nice to have access to the regression as soon as possible to confirm new test code is able to confirm a regression.
There is no SLA guarantee for CVE fixes in Stream and therefore setting any kind of expectation around Stream CVE fixes at all would be disingenuous to the Stream community.
I am not trying to imply that the frequency of CVE fixes causing regressions should ever be high/likely.
I don't have a fire alarm at home to imply my house is likely to catch fire. It is there to provide a better policy handling the off chance it does happen.
It just seem like a driving factor for focusing on Stream and CD/CI was that it has happen. Shouldn't the policies be reflect that it had happen and to smooth the situation if it does.
Will there be a way to expedite a CVE fix attempt into Stream after reports of a regression from RHEL users?
Will there be a repo for known problematic security updates such as a CR-broken?
What would be the roll of Stream if "Boot Hole" could happen again? Why is Stef Walter bringing it up? Are we being asked to help prevent or reduce the impact of that should it occur?
Put another way, is Stream a true Upstream or a hybrid? Is it really the policy that Stream is strictly a downstream when it comes to CVEs? Or if something unexpect happens again, is the policy in place were we act as an Upstream for addressing it?