On Fri, Feb 19, 2021 at 12:48 PM redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote: > > On Wednesday, February 17, 2021 9:01 PM, Mike McGrath <mmcgrath at redhat.com> wrote: > > > On Wed, Feb 17, 2021 at 8:09 PM Naoto Kobayashi <naoto.kobayashi4c at 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. josh