AlmaLinux Discovers Working with Red Hat (and CentOS Stream) Isn’t Easy
After Red Hat’s decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to “attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place.”
Red Hat told Ars Technica they are “eager to collaborate” on their CentOS Stream distro, “even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem.”
But Red Hat still managed to ruffled some feathers, reports ZDNet:
AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.
Still, it’s better by far to fix it than let it linger and see it eventually used to crash a server. That’s what I and others felt anyway. But, then, a senior Red Hat software engineer replied, “Thanks for the contribution. At this time, we don’t plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback.”
That went over like a lead balloon.
The GitLab conversation proceeded:
AlmaLinux: “Is customer demand really necessary to fix CVEs?”
Red Hat: “We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so.”
AlmaLinux: “I can even understand that, but why reject the fix when the work is already done and just has to be merged?”
At this point, Mike McGrath, Red Hat’s VP of Core Platforms, AKA RHEL, stepped in. He explained, “We should probably create a ‘what to expect when you’re submitting’ doc. Getting the code written is only the first step in what Red Hat does with it. We’d have to make sure there aren’t regressions, QA, etc. … So thank you for the contribution, it looks like the Fedora side of it is going well, so it’ll end up in RHEL at some point.”
Things went downhill rapidly from there…
On Reddit, McGrath said, “I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled.”
Finally, though the Red Hat Product Security team rated the CVE as “‘Important,’ the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant “we can now accept bug fixes outside of Red Hat’s release cycle.”
This Thursday AlmaLinux also reiterated that they’re “fully committed to delivering the best possible experience for the community, no matter where or what you run.” And in an apparent move to beef up compatibility testing, they announced they’d be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that “simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.”)
Read more of this story at Slashdot.
After Red Hat’s decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to “attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place.”
Red Hat told Ars Technica they are “eager to collaborate” on their CentOS Stream distro, “even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem.”
But Red Hat still managed to ruffled some feathers, reports ZDNet:
AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.
Still, it’s better by far to fix it than let it linger and see it eventually used to crash a server. That’s what I and others felt anyway. But, then, a senior Red Hat software engineer replied, “Thanks for the contribution. At this time, we don’t plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback.”
That went over like a lead balloon.
The GitLab conversation proceeded:
AlmaLinux: “Is customer demand really necessary to fix CVEs?”
Red Hat: “We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so.”
AlmaLinux: “I can even understand that, but why reject the fix when the work is already done and just has to be merged?”
At this point, Mike McGrath, Red Hat’s VP of Core Platforms, AKA RHEL, stepped in. He explained, “We should probably create a ‘what to expect when you’re submitting’ doc. Getting the code written is only the first step in what Red Hat does with it. We’d have to make sure there aren’t regressions, QA, etc. … So thank you for the contribution, it looks like the Fedora side of it is going well, so it’ll end up in RHEL at some point.”
Things went downhill rapidly from there…
On Reddit, McGrath said, “I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled.”
Finally, though the Red Hat Product Security team rated the CVE as “‘Important,’ the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant “we can now accept bug fixes outside of Red Hat’s release cycle.”
This Thursday AlmaLinux also reiterated that they’re “fully committed to delivering the best possible experience for the community, no matter where or what you run.” And in an apparent move to beef up compatibility testing, they announced they’d be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that “simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.”)
Read more of this story at Slashdot.