On Thu, Feb 25, 2021 at 10:44 AM Johnny Hughes <johnny@centos.org> wrote:
> 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.
Or: the version in Stream never got updated and is out-of-date due to
a compatibility issue with another Stream tested component, and the
security issue is great enough to release it in RHEL without ever
making it to Stream. Unless there is a guarantee of some sort that
Stream will *always* get new releases with or ahead of the production
RHEL, there are very likely to be missed updates in Stream. I've run
such split distributions for various development environments, such a
consistency is a promise likely to be broken on occasion, especially
since CentOS Stream does not have a support contract that would
prevent it.
Eh, we tried hard not to make CentOS Stream a separate thing. For most people most of the time, they'll be working directly in stream and scripts and automation will pull it into RHEL. This helps us avoid having the engineers work in two separate places and the out-of-date issue. I'm not saying it will never happen, but it should be rare outside of the aforementioned CVE or NDA concerns.
> 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
Or: packages in Stream have dependencies incompatible with the update,
especially if thoe packages have never been released in RHEL. Anything
module based such as python modules, or software with version specific
library dependenices, are vulnerable to this problem. And
modularity..... modularity makes the resolution of such upgrade
dependencies more dangerous. I particularly expect trouble with third
party repos, such as EPEL.
Please, don't leave out possibilities when assessing risks. I've
painful experiences of subtly incompatible upgrades compatible only
with older, locked down, stable systems.
> 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).
Or other packages will also need to be updated. It's part of the
problem with "you can't change just one thing".
> If instead they already have rebased the package (#2 above .. Stream is
> slightly ahead of RHEL).
I hope you understand my skepticism that stream will be stable enough
for anything resembling production work, and the lingering suspicion
that stream is *deliberately* destabilizing to discourage peopole from
using CentOS for production work.
There is no goal implied or explicit to deliberately destabilize CentOS Stream.
-Mike
> 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 :)
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel@centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel