Brief items

Security quote of the week

— Alexander "Solar Designer" Peslyak, from a presentation, slide 13

Comments (1 posted)

Kernel release status

The 6.4 kernel was released on June 25; Linus said:

Most of the stuff in my mailbox the last week has been about upcoming things for 6.5, and I already have 15 pull requests pending. I appreciate all you proactive people.

But that's for tomorrow. Today we're all busy build-testing the newest kernel release, and checking that it's all good. Right?

Headline features in this release include: generic iterators for BPF, the removal of the SELinux runtime disable knob, the removal of the SLOB memory allocator, linear address masking support on Intel CPUs, process-level samepage merging control, support for user trace events, more infrastructure for writing kernel modules in Rust, per-VMA locks, and much more. See the LWN merge-window summaries (part 1, part 2), and the (in-progress) KernelNewbies 6.4 page for the details.

Stable updates: 6.3.10, 6.1.36, 5.15.119, 5.10.186, 5.4.249, 4.19.288, and 4.14.320 were released on June 28.

Comments (none posted)

AlmaLinux's response to Red Hat's policy change

The AlmaLinux organization has posted a message describing the impact of Red Hat's decision to stop releasing the source to the RHEL distribution and how AlmaLinux will respond.

In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released. These updates will be carefully curated to ensure they are 1:1 compatible with RHEL, while not violating Red Hat’s licensing, and will be vetted and tested just like all of our other releases.

Update: Rocky Linux has also sent out a release on the subject. "There will be no disruption or change for any Rocky Linux users, collaborators, or partners".

Comments (203 posted)

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Over on the Software Freedom Conservancy blog, Policy Fellow and Hacker-in-Residence Bradley M. Kuhn analyzes the recent changes to Red Hat Enterprise Linux (RHEL) source availability in light of the GPL. It contains some interesting information about two alleged GPL violations that came about because the company's business model is structured in a way that brings it too close to non-compliance with the license, he said:

Perhaps the biggest problem with a murky business model that skirts the line of GPL compliance is that violations can and do happen — since even a minor deviation from the business model clearly violates the GPL agreements. Pre-IBM Red Hat deserves a certain amount of credit, as SFC is aware of only two documented incidents of GPL violations that have occurred since 2006 regarding the RHEL business model. We've decided to share some general details of these violations for the purpose of explaining where this business model can so easily cross the line.

[...] In another violation incident, we learned that Red Hat, in a specific non-USA country, was requiring that any customer who lowered the number of RHEL machines under service contract with Red Hat sign an additional agreement. This additional agreement promised that the customer had deleted every copy of RHEL in their entire organization other than the copies of RHEL that were currently contracted for service with Red Hat. Again, this is a "further restriction". The GPL agreements give everyone the unfettered right to make and keep as many copies of the software as they like, and a distributor of GPL'd software may not require a user to attest that they've deleted these legitimate, licensed copies of third-party-licensed software under the GPL. SFC informed Red Hat's legal department of this violation, and we were assured that this additional agreement would no longer be presented to any Red Hat customers in the future.

Comments (104 posted)

McGrath: Red Hat’s commitment to open source

Red Hat's Mike McGrath responds to the many criticisms aimed at the company since it changed its policy regarding RHEL source code.

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make. That brings me to CentOS Stream, of which there is immense confusion. I acknowledge that this is a change in a longstanding tradition where we went above and beyond, and change like this can cause some confusion. That confusion manifested as accusations about us going closed-source and about alleged GPL violations. There is CentOS Stream the binary deliverable, and CentOS Stream the source repository. The CentOS Stream gitlab source is where we build RHEL releases, in the open for all to see. To call RHEL “closed source” is categorically untrue and inaccurate. CentOS Stream moves faster than RHEL, so it might not be on HEAD, but the code is there. If you can’t find it, it’s a bug – please let us know.

Comments (197 posted)

Distributions quote of the week

So here is the reality with security updates. The vast majority of security updates are shipped in RHEL 3-9 months after we fix them, because minimizing the quantity of updates is an important goal in RHEL to reduce update churn for customers, so we only want to release quick fixes for issues that pose serious risk. (Most security issues are just not very urgent.) This means you get most security fixes drastically sooner in CentOS Stream than you would in RHEL.

However, higher-severity security updates do get fixed in RHEL first. Developers are not permitted to fix higher-severity security issues in CentOS Stream until after the fix is shipped in at least one RHEL update. We're encouraged to do so immediately after the fix ships in RHEL, so there *should* only be a minor delay of, say, one or two business days for the developer to notice the update has shipped. So in general, CentOS Stream *should* generally be ahead of RHEL and ideally only slightly behind for the more serious CVEs.

— Michael Catanzaro

Comments (none posted)

Ekstrand: NVK update: Enabling new extensions, conformance status & more

Faith Ekstrand has provided an update on the status of the NVK Vulkan driver for NVIDIA GPUs.

Probably the single most common question I get from folks is, "When will NVK be in upstream mesa?" The short answer is that it'll be upstreamed along with the new kernel API. The new API is going to be required in order to implement Vulkan correctly in a bunch of cases. Even though it mostly works on top of upstream nouveau, I don't want to be maintaining support for that interface for another 10 years when it only partially works.

We don't yet have an exact timetable for when the new API will be ready. I'm currently hoping that we get it all upstream this year but I can't say when exactly.

Comments (1 posted)