They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
RHEL security fixes for version X.Y may or may not fix security issues for version Z.A on CO, if the are not in sync.
I'm not sure where I claimed it was?
So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
https://oss-security.openwall.org/wiki/mailing-lists/distros
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.