On Thu, Feb 25, 2021 at 10:50 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote: > On Thu, Feb 25, 2021 at 10:44 AM Johnny Hughes <johnny at 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 at centos.org > > https://lists.centos.org/mailman/listinfo/centos-devel > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210225/199a2bb5/attachment-0004.html>