On Friday, February 19, 2021 2:26 PM, Josh Boyer <jwboyer at redhat.com> wrote: > On Fri, Feb 19, 2021 at 2:45 PM redbaronbrowser > redbaronbrowser at protonmail.com wrote: > > > > > On Wednesday, February 17, 2021 9:01 PM, Mike McGrath mmcgrath at redhat.com wrote: > > > > > > > > > There's a bit of nuance to this question in that policy states that CVEs should be fixed in RHEL before CentOS Stream. > I'm not sure what policies you're referring to. Can you point to > where they are documented? I suspect you mean the various blogs and > answers on the list, which are good discussions but I don't want to > assume that those are policies, nor do I want to assume that is what > you are referring to. I trimmed the coversation down to the policy I'm refering to. > Also, Stream and CI/CD are indeed important and related. However, > that doesn't mean there is a single universal approach to everything. I am not implying there is a single universal approach to everything. What I am asking is if exceptions to the policy Mike McGrath stated has already been established so the Stream community can get access to help quickly? Or would a RHEL user indicating a CVE fix cause a regression require seeking management approval before releasing the information to Stream? > > Will there be a way to expedite a CVE fix attempt into Stream after reports of a regression from RHEL users? > > Can you help me understand why an answer to that question matters > given that we are not providing an SLA on CVE fixes in Stream? I > understand that leaves things ambiguous, but even if the answer to > your question was "yes" it doesn't change anything in a manner that > matters from a Stream contributors perspective. I was not expecting an SLA on CVE fixes. If a CVE fix works as intended then I expect the policy MG stated to be the policy followed. I am not trying to object to that. A service-level agreement is between Red Hat and RHEL customers. There is no service agreement with Stream users so I never expected a SLA. Instead I was thinking more along the lines of an ULA (Upstream Level Agreement) that if a CVE "fix" is confirmed to be a CVE "breakage" similar to "Boot Hole," that management approval is already in place for the RHEL team to move access to that regression code to Stream users to be able to review. The SLA policy applying only to RHEL would continue to do so. But it sounds like as it stands now if a CVE "fix" causes unexpected problems, even after the problems are confirmed it may be weeks until management approves the Upstream getting access to help work on the issue. All I'm asking for a ULA which may only apply to 0.01% of updates so that management approval already pre-exists to release it to Upstream in a number of hours instead of weeks. > I am trying to be very clear here to avoid the mistake we made, > inadvertent or not, with the CentOS Linux lifecycle change. There is > no SLA on CVE fixes in Stream. Ok > > Will there be a repo for known problematic security updates such as a CR-broken? > > Not to my knowledge. > > > 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? > > Stef can speak for himself as to why it was mentioned. It is perhaps > a confusing issue to raise in the context of Stream, because that > particular CVE was under embargo anyway. There is no call to action > nor opportunity for the Stream community to deal with embargoed CVEs > in Stream itself. That is the nature of embargoes. I think you mean the development of the "Boot Hole" patch took place during an embargo, right? Once "Boot Hole" was released and actually impacted RHEL customers, wasn't the embargo period already over? I'm not asking for anything ahead of RHEL customers getting it. All I am asking for is pre-approval from management to get access as an Upstream once a problem with RHEL is confirmed. > > 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? > > With the nuance of CVEs in play, it's a hybrid. Mike already > explained that nuance above. In terms of closing the openness gap, that seems more than just a nuance. Of the CentOS 7 errata announced, 20% has been security updates. The existing information in the Stream FAQ and CentOS blog imply we are becoming the 100% Upstream. Instead the reality seems closer to being 80% Upstream and 20% Downstream.