On 2/25/21 10:49 AM, Nico Kadel-Garcia 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. > >> 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. I could care less what you use .. but your FUD is silly. Stream is critical to the development of RHEL. Breaking it on purpose would be ridiculous. Use what you want , but take your conspiracy theories to a prepper list. And yes .. 3rd party repos will need to build some things for Stream .. or their things will be broken. That will be required. If they want to do it or not do it has nothing to do with how we are doing Stream. If you want to use Stream , use it .. if you don't then don't. But I will not have the Project be accused of purposely destabilizing things.