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> wrote: > >> On Saturday, February 20, 2021 5:30 PM, Mike McGrath <mmcgrath at redhat.com> wrote: >> >>> On Sat, Feb 20, 2021 at 5:20 PM redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote: >>> >>>> On Friday, February 19, 2021 5:47 PM, Josh Boyer <jwboyer at redhat.com> wrote: >>>> >>>>> On Fri, Feb 19, 2021 at 5:47 PM redbaronbrowser >>>>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210221/e654c9c5/attachment-0005.html>