On 2/20/21 6:00 PM, redbaronbrowser via CentOS-devel wrote: > On Saturday, February 20, 2021 5:57 PM, Mike McGrath > <mmcgrath at redhat.com> wrote: > >> On Sat, Feb 20, 2021 at 5:35 PM redbaronbrowser >> <redbaronbrowser at protonmail.com >> <mailto:redbaronbrowser at protonmail.com>> wrote: >> >> On Saturday, February 20, 2021 5:30 PM, Mike McGrath >> <mmcgrath at redhat.com <mailto:mmcgrath at redhat.com>> wrote: >> >>> On Sat, Feb 20, 2021 at 5:20 PM redbaronbrowser via CentOS-devel >>> <centos-devel at centos.org <mailto:centos-devel at centos.org>> wrote: >>> >>> On Friday, February 19, 2021 5:47 PM, Josh Boyer >>> <jwboyer at redhat.com <mailto:jwboyer at redhat.com>> wrote: >>> >>> > On Fri, Feb 19, 2021 at 5:47 PM redbaronbrowser >>> > redbaronbrowser at protonmail.com >>> <mailto:redbaronbrowser at protonmail.com> wrote: >>> > >>> > > 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. >>> > >>> > If you mean "get access to the fixed code" or "get access >>> to a fixed >>> > build", in a situation like the post-Boot Hole scenario >>> there is no >>> > pre-approval necessary. We will do our best to resolve the >>> issue in >>> > Stream as quickly as possible. >>> >>> You keep coming back to the Fix for the Broken-Fix. I >>> believe you when you say Red Hat has always been working as >>> quickly as possible to Fix any Broken-Fixes. However, once >>> they have the fix the lifecycle of the bug is over. Stream >>> isn't interesting from the perspective of completed bug >>> lifecycles. The interesting aspect to closing the openness >>> gap is the mid-lifecycle of the bug. >>> >>> I am trying to focus on how quickly will Stream users be able >>> to contribute to the fixing of a Broken-Fix. >>> >>> I am sorry if I am parsing too much into Mike's response, but >>> it read to me like it is possible for the code to a >>> Broken-Fix to, by policy, be withheld to only the "entitled" >>> RHEL subscribers to access. >>> >>> >>> You were. >>> >>> >>> I'm asking to what degree Red Hat expects to be able to take >>> advantage us while an active Bugzilla entry exist because a >>> CVE "fix" had unintended side-effects. Can we get quick >>> transparency into accessing broken packages and code even if >>> that broken build is a CVE "fix" related? >>> >>> Or is the policy that we will sit on the sidelines for Red >>> Hat by itself to fix broken security patches much like CentOS >>> has always operated before Stream? >>> >>> >>> The policy is CVEs go out via RHEL first, just like it was with >>> CentOS. When you see behavior that is counter to that policy, >>> the policy was broken (this is a Red Hat policy, not a CentOS >>> Stream policy). >> >> I wasn't claiming it was a Stream policy. And I'm not asking for >> CVEs to be released for CentOS first. I was just trying to >> determine, what is the expected latency between the time it is >> determine a CVE "fix" for RHEL causes broken behavior and how soon >> Stream users can contribute to fixing it. >> >> >> I don't think we've done this long enough to know what the lag will >> be. I can tell you there isn't some sort of management sleep() >> injected into the process. It will be up to the individual >> engineering teams and their development workflow. I don't expect >> we'll be opening CVE development to CentOS Stream. > > Thank you for your quick response. > > To be clear, I wasn't expecting a CVE response team to be part of > Stream. I was expecting regression response to be part of Stream of > which CVE fixes is one potential source of regressions. I want to be > able to work on CI/CD testing and regression fixes regardless of the > source instead of only 80% of them. > Basically .. when a CVE is released in RHEL, there are two possibilities. 1) The current package in RHEL and Stream are the same. 2) The current package in RHEL is slightly older than the one in Stream. If it is #1 .. after the package is released in RHEL .. if the new package is now newer than stream .. then 1 of 2 things will happen A) That package will be put into stream too since it will also be in the next point release of RHEL. or B) If a rebase of that package is going to happen in the next point release .. they may pull in that rebased package and fic the CVE (the way they will do it in the next point release). If instead they already have rebased the package (#2 above .. Stream is slightly ahead of RHEL). In this case, they will do B) above .. roll the cve fix into the rebased package. ==== So .. how fast will they do B) ? They will do it as fast as they can .. because .. they will be using whatever is in the build root to build other things and if they don't roll in the fixes in B), then anything they build against the older B) could have issues. No one wants to build a package in Stream that has a security issue (or other bug) that they will then need to rebuild again, it means more work for them. Therefore, it is in the best intrest of the engineers to get the stuff into Stream as soon as they can. That is why you can believe it will likely happen .. it is the thing that is the less amount of work for the engineers doing the work. It is also the best overall situation. When those lineup .. things are good :)