[CentOS-devel] re CVE errata in CentOS Stream

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.html>