On Thu, Feb 25, 2021 at 10:50 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
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.
The current package in RHEL and Stream are the same.
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