Just to recap the latest in the #Redhat RHEL vs downstreams not offering them any value drama:

Redhat publically states that downstream rebuilders offer them no value, and the RHEL community should all be working in the Centos-stream sandbox, because that's where the community is, because it has community right there in the name, and that's where the code fixes can land, and community is only about lines of code in the repo.

@almalinux goes "alright, no value in us being a 1:1 rebuild of RHEL, then we're cutting our own path while being based on Centos-stream, staying ABI compatible with RHEL, but we'll fix our own bugs when we find them"

Alma Linux then finds a CVE in the iperf3 server impacting everyone in the Enterprise Linux 9 ecosystem, so they release the fix for AlmaLinux, and then immediately open pull requests for Fedora and Centos-stream to land the fix upstream. Which would seem to be exactly what Redhat was asking for this whole time.

Redhat's response to the centos-stream pull request? "There is no current customer demand for this fix in RHEL, so we're not interested in this fix"

The astute will notice that the pull request is feeding into centos-stream, and not RHEL. But they're making merge decisions here based on immediate customer demand in RHEL.

So maybe this whole "Centos-stream is the community distro" line was bullshit and it really is just the beta testing ground for RHEL, just like all of us kind of thought it was while getting shouted down by the centos-stream advocates this whole time.

So Redhat is still doing great.

https://gitlab.com/redhat/centos-stream/rpms/iperf3/-/merge_requests/5

Fixes CVE-2023-38403 - Resolves: rhbz#2223729 (!5) · Merge requests · Red Hat / centos-stream / rpms / iperf3 · GitLab

Summary of Changes Fixes CVE-2023-38403 Approved Development Ticket

GitLab

Is Redhat obligated to accept this pull request just because it's coming from a downstream contributor? No.

Does it always make sense to pull a minor fix into RHEL and risk the possibility of side effects? No.

Should Redhat engineers be pulling in fixes which they fully know won't be pulled into RHEL? Eh.

Does Redhat declining the very first notable contribution to Centos-stream after going scorched earth telling people to contribute to cento-stream have a bad look to it?

Yeah, this is the problem.

@kwf Firstly, @jonathanspw did a great job with this merge request. It's well-structured, solves a problem, etc.

But... The CVE in question isn't even classified by NIST yet: https://nvd.nist.gov/vuln/detail/CVE-2023-38403

Red Hat also hasn't made a page about it yet for their own assessment: https://access.redhat.com/security/cve/cve-2023-38403

The merge request wasn't closed. Nobody has said anything about totally rejecting it. The maintainer was doing his job and probably has no idea what's going on.

Human interactions are a big messy world.

NVD - CVE-2023-38403

@kwf On the third point, it's also no. Things are only merged into CentOS Stream if they are planned for the next minor version of the corresponding RHEL major version. Merging things that aren't intended for RHEL would be against what we've described CS as. It's not a sandbox to throw out new features/fixes to see if they work. It's the staging area for QA-tested, RHEL-compatible updates that are approved for the next minor version.
@carlwgeorge honestly, calling it "OpenRHEL" would have been so much less confusing than centos-stream.
@kwf @carlwgeorge Well, no. Because RedHats Premium Product (tm) OpenShift is also not the upstream project.
@ttk @carlwgeorge and Centos was a 10 year support distro. No name is perfect. 🤷
@kwf @carlwgeorge yeah, i only wanted to emphasise that the "open" prefix in redhat context is already burnt somehow

Interesting.

@jwildeboer what's the reason behind this? Care to explain?

@kwf @almalinux This is really just adding support to my "redhat is legacy that should be given no support effort" stance.

@kwf @almalinux

Maybe they want to reject the patch because the bug is being actively exploited?

Asking for a friend.

@SpaceLifeForm @almalinux that's kind of an odd thing to say
@kwf @SpaceLifeForm @almalinux Remember "That vulnerability is completely hypothetical?"
@kwf @almalinux wow, why isn't Redhat happy with a good PR being submitted to help every distro based on it? It's a shame.

@kwf @almalinux And this is why a hard fork from SUSE and AlmaLinux diverging to be ABI are a great thing.

AlmaLinux can submit patches, but if IBM doesn't want them, fine. Let their customers ask why AlmaLinux is getting patches and bug fixes faster than RHEL.

I'm hoping with this direction change, AlmaLinux can start shipping some updated packages by default. Like it's asinine that RHEL ships PHP 7.2 (!!!) in 8.8 but Ubuntu 22.04 ships PHP 8.1. There's a difference between shipping stable software and shipping ancient history.

@travis @kwf @almalinux RHEL customers asking for this because Alma has it would be a great outcome. The maintainer specifically mentioned customer feedback/demand. But really it's probably going to depend more on the severity rating it ends up with (it doesn't have one yet).

@travis @kwf @almalinux RHEL 8 has PHP 7.2 as default, but also has optional 7.3, 7.4, and 8.0. It doesn't make sense to compare the default PHP version of a distro released in 2019 with the default PHP version of a distro released in 2022. RHEL 9, which was released in 2022, has PHP 8.0 as the default, with optional 8.1.

Alma could ship additional optional PHP versions, but changing the default PHP version would break the ABI compatibility they're aiming for.

@kwf this on the back of PowerDNS finding RHEL had a broken back port they declined to patch as well https://github.com/PowerDNS/pdns/commit/3dabf2d4a1a478fb00a232259e8043f075eb4d03
Work around Red Hat 8 pooping the bed in OpenSSL's headers · PowerDNS/pdns@3dabf2d

The openssl/kdf.h header on EL8 is invalid because someone backported a work-in-progress feature to an older OpenSSL branch and did not bother to backport the fixes that were added later. Red Hat ...

GitHub
@ragectl @kwf Yup, I've also had to deal with Red Hat shopping broken patches and then having to work around it when my bugs were flat out ignored.
@kwf @almalinux Your "not interested in this fix" comment is leaving out the "at this time" and "keep it open for evaluation" parts that were actually said. At least you didn't crop those parts out like the person who posted this on Reddit did. The CVE isn't even rated yet, so let's see how that turns out before rushing to judgement. Not every CVE gets fixed in RHEL. The severity rating and customer demand will influence this being merged.

@kwf @almalinux
Merge decisions for CentOS Stream contributions are made by Red Hat. CentOS Stream is still more of a community-oriented distro than CentOS Linux. Both of these things are true.

I can't help but feel the "shouted down by the centos-stream advocates" is directed at me. If I've ever made you feel "shouted down", I truly apologize. I'm a believer in the strategic direction of the CentOS project. The execution is a work in progress.

@carlwgeorge @almalinux you're certainly the most vocal if still the most constructive advocate for CS. I just disagree with you that community primarily translates into patch submission.

Many of the other advocates have been less genuine

@kwf @almalinux I never said that community primarily translates into patch submissions. What I have said is that not being able to accept patches that change the OS is a critical flaw for a project that claims to be community oriented.

CentOS fixed this by moving upstream of RHEL.

Alma has now fixed this by dropping 1:1 and allowing some divergence from RHEL, while staying downstream of RHEL.

Both approaches are valid and should be celebrated.

@carlwgeorge @kwf @almalinux For what it's worth, the CVE rating was completed last night and this morning the merge requests are being processed.

For CentOS Stream 8, the MR has been accepted as-is. For CentOS Stream 9, the maintainer has asked for feedback from the contributor on next steps.

@kwf @almalinux god the corporate bs in this image is so high
@kwf @almalinux @controlc Uh-oh — iperf3, you say? I need to, uh, check something. 😅