On Friday, February 19, 2021 5:47 PM, Josh Boyer <jwboyer@redhat.com> wrote:

> On Fri, Feb 19, 2021 at 5:47 PM redbaronbrowser
> redbaronbrowser@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.

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?