BrianFagioli shares a report from BetaNews: In a recent security announcement, Red Hat's Information Risk and Security and Product Security teams have identified a critical vulnerability in the latest versions of the 'xz' compression tools and libraries. The affected versions, 5.6.0 and 5.6.1, contain malicious code that could potentially allow unauthorized access to systems. Fedora Linux 40 users and those using Fedora Rawhide, the development distribution for future Fedora builds, are at risk.

The vulnerability, designated CVE-2024-3094, impacts users who have updated to the compromised versions of the xz libraries. Red Hat urges all Fedora Rawhide users to immediately cease using the distribution for both work and personal activities until the issue is resolved. Plans are underway to revert Fedora Rawhide to the safer xz-5.4.x version, after which it will be safe to redeploy Fedora Rawhide instances. Although Fedora Linux 40 builds have not been confirmed to be compromised, Red Hat advises users to downgrade to a 5.4 build as a precautionary measure. An update reverting xz to 5.4.x has been released and is being distributed to Fedora Linux 40 users through the normal update system. Users can expedite the update by following instructions provided by Red Hat. Further reader submissions: xz/liblzma Backdoored, Facilitating ssh Compromise;
Malicious Code Discovered in Popular XZ Utils.

An anonymous reader shares a report: Mutterings of alarm are emerging from the cloisters of Red Hat after the world's largest management consultancy was hired to help the IBM subsidiary focus engineers on their highest-value work. Red Hat confirmed the partnership with McKinsey & Company to The Reg, sharing this extract from an email from CTO Chris Wright to the Global Engineering Team:

"Hey everyone -- as I mentioned during the recent Q1 All Hands, my goal is to have Global Engineering recognized as the world's greatest open-source software engineering organization. This team is already doing amazing work, and we have several initiatives in progress to help us achieve the goal I've set. One of those is a partnership with McKinsey. The objective of this project is to help us understand and incorporate learnings on working models, development practices, and tooling from across the software industry.

"We've heard your feedback in person, during All Hands, and through RHAS [the annual Red Hat Associate Survey]. This project will help us to identify and remove mundane tasks that drain your energy so that you can focus on the most engaging and highest value work â" to make your job better. The work with McKinsey is one piece of the overall plan to help us become the world's greatest open-source software engineering organization"

Linus Torvalds had "some robust exchanges" on the Linux kernel mailing list with a contributor from Google. The subject was inodes, notes the Register, "which as Red Hat puts it are each 'a unique identifier for a specific piece of metadata on a given filesystem.'" Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using tar to archive files. Torvalds countered that inodes have had their day. "Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed." But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers...

In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.

"We're not living in the 1970s, and filesystems have changed."

"This is a proposed Change for Fedora Linux..." emphasizes its page on the Fedora project Wiki. "As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee."

But Phoronix reports that "One of the latest change proposals filed for Fedora 40 is to unify their /usr/bin and /usr/sbin locations." The change proposal explains:

"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH."

Fedora years ago merged /bin and /usr/bin and as the last step they want to unify /usr/bin and /usr/sbin.
The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."


- We have /sbin/ip while Debian has /bin/ip

- We have /bin/chmem and /bin/isosize, but Debian has /sbin/chmem and /sbin/isosize

- We also have /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, while Debian has those in under /bin, etc.

- Fedora becomes more compatible with Arch, which did the merge a few years ago.


The proposal on the Fedora project Wiki offers this summary: The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator. While this seems attractive in theory, in practice it's very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries...

Since generally all user sessions and services have both directories in $PATH, this split actually isn't used for anything. Its main effect is confusion when people need to use the absolute path and guess the directory wrong. Other distributions put some binaries in the other directory, so the absolute path is often not portable. Also, it is very easy for a user to end up with /sbin before /bin in $PATH, and for an administrator to end up with /bin before /sbin in $PATH, causing confusion. If this feature is dropped, the system became a little bit simpler, which is useful especially for new users, who are not aware of the history of the split.

"Red Hat is going to do away with the X.Org server and support Wayland and XWayland for apps that currently (or only) run on X11," writes Slashdot reader motang. Red Hat's Carlos Soriano Sanchez confirmed on the Red Hat blog: "The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we're on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025.

With this, we've decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won't immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning to a Wayland ecosystem. It's important to note that "Xorg Server" and "X11" are not synonymous, X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
[...]
This decision will allow us to focus our efforts starting from RHEL 10 solely on a modern stack and ecosystem. This means we will be able to tackle problems such as HDR, increased security, setups with mixed low and high density displays or very high density displays, better GPU/Display hot-plugging, better gestures and scrolling, and so on. We are confident that Wayland will provide a solid platform and we're excited to work with the community and all of our partners and customers on building the future for Linux."

In Raleigh, North Carolina — the home of Red Hat — local newspaper the News & Observer takes an in-depth look at the "announcement that split the open source software community." (Alternate URL here.) [M]any saw Red Hat's decision to essentially paywall Red Hat Enterprise Linux, or RHEL, as sacrilegious... Red Hat employees were also conflicted about the new policy, [Red Hat Vice President Mike] McGrath acknowledged. "I think a lot of even internal associates didn't fully understand what we had announced and why," he said...

At issue, he wrote, were emerging competitors who copied Red Hat Enterprise Linux, down to even the code's mistakes, and then offered these Red Hat-replicas to customers for free. These weren't community members adding value, he contended, but undercutting rivals. And in a year when Red Hat laid off 4% of its total workforce, McGrath said, the company could not justify allowing this to continue. "I feel that while this was a difficult decision between community and business, we're still on the right side of it," he told the News & Observer. Not everyone agrees...

McGrath offered little consolation to customers who were relying on one-for-one versions of RHEL. They could stay with the downstream distributions, find another provider, or pay for Red Hat. "I think (people) were just so used to the way things work," he said. "There's a vocal group of people that probably need Red Hat's level of support, but simply don't want to pay for it. And I don't really have... there's not much we can tell them."

Since its RHEL decision, Red Hat has secured several prominent partnerships. In September, the cloud-based software company Salesforce moved 200,000 of its systems from the free CentOS Linux to Red Hat Enterprise Linux. The same month, Red Hat announced RHEL would begin to support Oracle's cloud infrastructure. Oracle was one of the few major companies this summer to publicly criticize Red Hat for essentially paywalling its most popular code. On Oct. 24, Red Hat notched another win when the data security firm Cohesity said it would also ditch CentOS Linux for RHEL.
The article delves into the history of Red Hat — and of Linux — before culminating with this quote from McGrath. "I think long gone are the times of that sort of romantic view of hobbyists working in their spare time to build open source. I think there's still room for that — we still have that — but quite a lot of open source is now built from people that are paid full time."

Red Hat likes to point out that 90% of Fortune 500 companies use its services, according to the article. But it also quotes Jonathan Wright, infrastructure team lead at the nonprofit AlmaLinux, as saying that Red Hat played "fast and loose" with the GPL. The newspaper then adds that "For many open source believers, such a threat to its hallowed text isn't forgivable."

Long-time Slashdot reader williamyf writes: In the ongoing battle between Red Hat and other "Enterprise Linux -- RHEL compatible" distros, today the OpenELA (Open Enterprise Linux Association), a body Consisting of CIQ (stewards of Rocky Linux), Oracle and Suse, released source code for a generic "Enterprise Linux Distro" (Sources available for RHEL 8 and RHEL 9). A Steering committee for the foundation was also formed.

War between Red Hat and what they call "clones" (mostly Oracle; CentOS, Rocky, Alma and others seem to be collateral damage) has been raging on for years. First, in 2011, Red Hat changed the way they distributed kernel patches. Then, in 2014, Red Hat absorbed CentOS. In 2019 Red Hat transformed CentOS to CentOS stream, and shortened support Timetables for CentOS 8, all out of the blue. Then, in 2023, RedHat severely restricted source code access to non-customers.

What will be RedHat's reaction to this development? My bet is that they will stop to release source code of distro modules under BSD, MIT, APACHE and MPL Licenses for RHEL and in certain Windows for CentOS Stream. What is your bet? Let us know in the comments.

An anonymous reader shares a report: When Mike McGrath, Red Hat's Red Hat Core Platforms vice president, announced that Red Hat was putting new restrictions on who could access Red Hat Enterprise Linux (RHEL)'s code, other Linux companies that depended on RHEL's code for their own distro releases were, in a word, unhappy. Three of them, CIQ, Oracle, and SUSE, came together to form the Open Enterprise Linux Association (OpenELA). Their united goal was to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code." Now, the first OpenELA code release is available.

As Thomas Di Giacomo, SUSE's chief technology and product officer, said in a statement, "We're pleased to deliver on our promise of making source code available and to continue our work together to provide choice to our customers while we ensure that Enterprise Linux source code remains freely accessible to the public." Why are they doing this? Gregory Kurtzer, CIQ's CEO, and Rocky Linux's founder, explained: "Organizations worldwide standardized on CentOS because it was freely available, followed the Enterprise Linux standard, and was well supported. After CentOS was discontinued, it left not only a gaping hole in the ecosystem but also clearly showed how the community needs to come together and do better. OpenELA is exactly that -- the community's answer to ensuring a collaborative and stable future for all professional IT departments and enterprise use cases."

AlmaLinux is creating a Red Hat Enterprise Linux (RHEL) without any Red Hat code. Instead, AlmaLinux OS will aim to be Application Binary Interface (ABI) compatible and use the CentOS Stream source code that Red Hat continues to offer. Additional code is pulled from Red Hat Universal Base Images, and upstream Linux code. Benny Vasquez, chairperson of the AlmaLinux OF Foundation, explained how all this works at the open-source community convention All Things Open. ZDNet's Steven Vaughan-Nichols reports: The hardest part is Red Hat's Linux kernel updates because, added Vasquez, "you can't get those kernel updates without violating Red Hat's licensing agreements." Therefore, she continued, "What we do is we pull the security patches from various other sources, and, if nothing else, we can find them when Oracle releases them." Vasquez did note one blessing from this change in production: "AlmaLinux, no longer bound to Red Hat's releases, has been able to release upstream security fixes faster than Red Hat. "For example, the AMD microcode exploits were patched before Red Hat because they took a little bit of extra time to get out the door. We then pulled in, tested, and out the door about a week ahead of them." The overall goal remains to maintain RHEL compatibility. "Any breaking changes between RHEL and AlmaLinux, any application that stops working, is a bug and must be fixed."

That's not to say AlmaLinux will be simply an excellent RHEL clone going forward. It plans to add features of its own. For instance, Red Hat users who want programs not bundled in RHEL often turn to Extra Packages for Enterprise Linux (EPEL). These typically are programs included in Fedora Linux. Besides supporting EPEL software, AlmaLinux has its own extra software package -- called Synergy -- which holds programs that the AlmaLinux community wants but are not available in either EPEL or RHEL. If one such program is subsequently added to EPEL or RHEL, AlmaLinux drops it from Synergy to prevent confusion and duplication of effort.

This has not been an easy road for AlmaLinux. Even a 1% code difference is a lot to write and maintain. For example, when AlmaLinux tried to patch CentOS Stream code to fix a problem, Red Hat was downright grumpy about AlmaLinux's attempt to fix a security hole. Vasquez acknowledged it was tough sledding at first, but noted: "The good news is that they have been improving the process, and things will look a little bit smoother." AlmaLinux, she noted, is also not so much worried as aware that Red Hat may throw a monkey wrench into their efforts. Vasquez added: "Internally, we're working on stopgap things we'd need to do to anticipate Red Hat changing everything terribly." She doesn't think Red Hat will do it, but "we want to be as prepared as possible."

Thursday ZDNet reported... As security holes go, CVE-2023-4911, aka "Looney Tunables," isn't horrid. It has a Common Vulnerability Scoring System score of 7.8, which is ranked as important, not critical.

On the other hand, this GNU C Library's (glibc) dynamic loader vulnerability is a buffer overflow, which is always big trouble, and it's in pretty much all Linux distributions, so it's more than bad enough. After all, its discoverers, the Qualys Threat Research Unit, were able to exploit "this vulnerability (a local privilege escalation that grants full root privileges) on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13." Other distributions are almost certainly vulnerable to attack. The one major exception is the highly secure Alpine Linux. Thanks to this vulnerability, it's trivial to take over most Linux systems as a root user. As the researchers noted, this exploitation method "works against almost all of the SUID-root programs that are installed by default on Linux...."

The good news is that Red Hat, Ubuntu, Debian, and Gentoo have all released their own updates. In addition, the upstream glibc code has been patched with the fix. If you can't patch it, Red Hat has a script that should work on most Linux systems to mitigate the problem by setting your system to terminate any setuid program invoked with GLIBC_TUNABLES in the environment.

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."

The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.

Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."

This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.

In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

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.")

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.

Long-time Slashdot reader Amiga Trombone shares a report from Phoronix: With Red Hat now restricting access to the RHEL source repositories, AlmaLinux and other downstreams that have long provided "community" rebuilds of Red Hat Enterprise Linux with 1:1 compatibility to upstream RHEL have been left sorting out what to do. Benny Vasquez, Chair of the Board for the AlmaLinux OS Foundation, wrote in a blog post yesterday: After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL in response to our community's needs, to the extent it is possible to do, and such that software that runs on RHEL will run the same on AlmaLinux.

For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of "bug-for-bug compatibility" with Red Hat, and that means that we can now accept bug fixes outside of Red Hat's release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream."

Steven Vaughan-Nichols writes via ZDNet: I'd been waiting for Oracle to throw its hat into the ring for the Red Hat Enterprise Linux (RHEL) Linux source-code fight. I knew it was only a matter of time. On July 10, Oracle's Edward Screven, chief corporate architect, and Wim Coekaerts, head of Oracle Linux development, declared: "IBM's actions are not in your best interest. By killing CentOS as a RHEL alternative and attacking AlmaLinux and Rocky Linux, IBM is eliminating one way your customers save money and make a larger share of their wallet available to you."

In fact, Oracle now presents itself as an open-source Linux champion: "Oracle has always made Oracle Linux binaries and source freely available to all. We do not have subscription agreements that interfere with a subscriber's rights to redistribute Oracle Linux. On the other hand, IBM subscription agreements specify that you're in breach if you use those subscription services to exercise your GPLv2 rights." As of June 21, IBM no longer publicly releases RHEL source code -- in short, the gloves are off, and the fight's on. But this is also just the latest move in a fight that's older than many of you. [...]

Mike McGrath, Red Hat's vice president of core platforms, explained why Red Hat would no longer be releasing RHEL's code, but only CentOS Stream's code, because "thousands of [Red Hat] people spend their time writing code to enable new features, fixing bugs, integrating different packages and then supporting that work for a long time ... We have to pay the people to do that work." That sentiment is certainly true. But I also feel that Oracle takes the worst possible spin, with Screven and Coekaerts commenting: "IBM doesn't want to continue publicly releasing RHEL source code because it has to pay its engineers? That seems odd, given that Red Hat as a successful independent open source company chose to publicly release RHEL source and pay its engineers for many years before IBM acquired Red Hat in 2019 for $34 billion."

So, what will Oracle do now? For starters, Oracle Linux will continue to be RHEL-compatible through RHEL 9.2. After that release -- and without access to the published RHEL source code -- there are no guarantees. But Screven and Coekaerts suggest that "if an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem." As for Oracle Linux's code: "Oracle is committed to Linux freedom. Oracle makes the following promise: as long as Oracle distributes Linux, Oracle will make the binaries and source code for that distribution publicly and freely available. Furthermore, Oracle welcomes downstream distributions of every kind, community, and commercial. We are happy to work with distributors to ease that process, work together on the content of Oracle Linux, and ensure Oracle software products are certified on your distribution."

John.Banister writes: SUSE announced that they're spending $10 million on maintaining a fork of RHEL, with the source code of the fork to be freely available to all. I don't know that people who want to copy RHEL source will necessarily see copying the source of a fork as furthering their goals, but it could be that SUSE will build a nice alternative enterprise Linux to complement their current product. And, I reckon, better SUSE than Oracle, since I keep reading comments on people getting screwed by Oracle, but not so many on people getting screwed by SUSE. ZDNet's Steven Vaughan-Nichols writes: This all started when Red Hat's VP of core platforms, Mike McGrath, declared, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal." That may not sound like much to you, but those were fighting words to many open-source and Linux distributors. According to Linux's fundamental license, the GPLv2, no restrictions can be placed on distributing the source code to those who've received the binaries. In the view of many in the open-source community, that's exactly what Red Hat has done.

Others see this as the latest step in the long dance between Red Hat's business licensing demands and open-source licensing. Red Hat has had conflicts with the RHEL clones since 2005, when Red Hat's trademarks were the issue of the day. Usually, these fights stayed confined to the RHEL and its immediate clone rivals. Not this time.

Dirk-Peter van Leeuwen, SUSE CEO, said this: "For decades, collaboration and shared success have been the building blocks of our open-source community. We have a responsibility to defend these values. This investment will preserve the flow of innovation for years to come and ensures that customers and community alike are not subjected to vendor lock-in and have genuine choice tomorrow as well as today." What does that mean? While SUSE will continue to invest in and support its own Linux distributions, SUSE Linux Enterprise (SLE) and openSUSE, SUSE plans on creating its own RHEL-compatible clone. Once completed, this new distro will be contributed to an open-source foundation, which will provide ongoing free access to alternative source code.

Wednesday Greg Kroah-Hartman announced the release of the 6.4.2 kernel. "All users of the 6.4 kernel series must upgrade."

The Hacker News reports: Details have emerged about a newly identified security flaw in the Linux kernel that could allow a user to gain elevated privileges on a target host. Dubbed StackRot (CVE-2023-3269, CVSS score: 7.8), the flaw impacts Linux versions 6.1 through 6.4. There is no evidence that the shortcoming has been exploited in the wild to date.

"As StackRot is a Linux kernel vulnerability found in the memory management subsystem, it affects almost all kernel configurations and requires minimal capabilities to trigger," Peking University security researcher Ruihan Li said. "However, it should be noted that maple nodes are freed using RCU callbacks, delaying the actual memory deallocation until after the RCU grace period. Consequently, exploiting this vulnerability is considered challenging."

Following responsible disclosure on June 15, 2023, it has been addressed in stable versions 6.1.37, 6.3.11, and 6.4.1 as of July 1, 2023, after a two-week effort led by Linus Torvalds. A proof-of-concept (PoC) exploit and additional technical specifics about the bug are expected to be made public by the end of the month.
ZDNet points out that Linux 6.4 "offers improved hardware enablement for ARM boards" and does a better job with the power demands of Steam Deck gaming devices. And "On the software side, the Linux 6.4 release includes more upstreamed Rust code. We're getting ever closer to full in-kernel Rust language support."

The Register also notes that Linux 6.4 also includes "the beginnings of support for Apple's M2 processors," along with support for hibernation of RISC-V CPUs, "a likely presage to such silicon powering laptop computers."

End-of-life for Red Hat 7 is scheduled to happen in one year. Thursday Red Hat announced an add-on option for four more years of "extended support" for RHEL 7: As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...

For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...

ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.

When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.
CentOS 7 will also hit its end-of-life in one year on June 30 of 2024.