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. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210220/3a46b26c/attachment-0005.html>