Code in Fedora and Update on Rocky Linux
-
Modernizing Fedora's C code [LWN.net]
It is not often that you see a Fedora change proposal for a version of the distribution that will not be available for 18 months or so, but that is exactly what was recently posted to the mailing list. The change targets the C source code in the myriad of packages that the distribution ships; it would fix code that uses some ancient compatibility features that were removed by the C99 standard but are still supported by GCC. As might be guessed from the long runway proposed, there is quite a bit of work to do to get there.
As usual with Fedora change proposals, this one was posted to the Fedora devel mailing list on behalf of its owner, Florian Weimer, by Fedora program manager Ben Cotton; it is also available in an updated form on the Fedora wiki. At the moment, Fedora 37 is imminent, but the proposal targets Fedora 40, which is currently slated for the northern-hemisphere Spring of 2024. The goal, as described by the title is "Porting Fedora to Modern C".
-
Packaging Rust for Fedora
Linux distributions were, as a general rule, designed during an era when most software of interest was written in C; as a result, distributions are naturally able to efficiently package C applications and the libraries they depend on. Modern languages, though, tend to be built around their own package-management systems that are designed with different goals in mind. The result is that, for years, distributors have struggled to find the best ways to package and ship applications written in those languages. A recent discussion in the Fedora community on the packaging of Rust applications shows that the problems have not yet all been solved.
The initial spark for the discussion was this Fedora 38 change proposal driven by Panu Matilainen. The RPM package manager has long carried its own internal OpenPGP parser for the management of keys and signatures for packages. This parser seemingly pleases nobody; the proposal describes it as "rather infamous for its limitations and flaws" and puts forward a plan to replace it with the Sequoia library, which is written in Rust (and which was covered here in 2020). The use of Rust provides the sort of safety net that is welcome in security-relevant code like this, but it can also be a red flag for developers who worry about how Rust fits into the distribution as a whole.
Inevitably, there were complaints about this proposal. Kevin Kofler, for example, asked why a library written in C had not been chosen. According to Matilainen, efforts to find such a library have been underway for years without success. The most obvious alternative, GPGME, is unsuitable because it is built around communicating with an external GPG process, "which is a setup you do NOT want in the rpm context where chroots come and go etc.". Neal Gompa agreed that the GPGME model creates pain in this context, and seemed to agree that there was no better alternative than Sequoia despite his own disagreements with the Rust community. "So here we are, in a subpar situation created by bad tools because nobody cares enough about security anyway".
-
Atempo Partners with CIQ to Complete Certification Process for Rocky Linux on All Atempo Offerings
-
Atempo Partners with CIQ to Complete Certification Process for Rocky Linux on All Atempo Offerings
Atempo has partnered with CIQ to complete the certification of Rocky Linux for all of Atempo’s offerings. Atempo is one of Europe’s largest data protection and data management solutions providers. CIQ is the company building the next generation of software infrastructure for enterprises running data-intensive workloads atop the Rocky Linux enterprise Linux distribution. The certification means that customers can deploy Atempo solutions powered by Rocky Linux with confidence that the technology stacks are integrated for optimal performance with the Rocky Linux enterprise Linux distribution.