Which was expected since CentOS was a free (beer)rebuild of RHEL

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

Not true, because the current CO is not a rolling update.

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.

> Not true, because the current CO is not a rolling update.

I'm not sure where I claimed it was?

They're saying that Stream will be getting the normal package updates first as a kind of testbed, which is different than before.

So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.

Ahh okay, I can see how I didn't communicate myself clearly in initial message in the thread.

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.

I guess the question will be how fast CentOS Stream releases fixes compared to Debian Stable/Testing and Ubuntu LTS.

It will almost certainly be slower than Ubuntu just because of the extra layer of work mentioned above.

Canonical are also fairly actively involved in security fixes and among those brought in to the various security embargoes. They usually ship packages the same day embargoes drop.

If by "involved" you mean "take patches that someone else developed and shared on the distros predisclosure list", then they are.

Interesting, who else are involved in the embargoes? Anywhere I could read more about this?

It depends on where the vulnerability is. Everything is all ad-hoc, each piece of open source software decides how they want to handle it, attempting to juggle the chances of a leak. The fewer you tell, the more likely the secret is to be kept, and you want to keep these things secret until a patch is done.

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.

Embargos are coordinated on the "linux-distros" mailing list:

https://oss-security.openwall.org/wiki/mailing-lists/distros

How is "everything a little after" the same as "some things prior, other things after"?

Patches for those security issues are embargoed until specified dates. Red Hat simply cannot add them to CentOS stream before that date.

Fine, but that in no way prevents them from releasing them simultaneously.