Fedora / Red Hat / IBM: Sanctioning Volunteers, Pushing Microsoft SystemD, and Fake 'Security' (User Restrictions/Handcuffs)
-
LWN ☛ FESCo provenpackager sanction causes problems [Ed: IBM continues to abuse Fedora volunteers, who to IBM are just slaves]
The Fedora Engineering Steering Council (FESCo) has made a series of missteps in deciding to revoke a longtime Fedora contributor's provenpackager status. FESCo made the decision during a closed session, based on private complaints. It then publicly announced its decision, including the contributor's name, while only supplying a vague account of the contributor's actions. This has left the Fedora community with more questions than answers, and raised a number of complaints about the transparency of FESCo's process. In addition, the sequence of events has sparked discussions about package ownership, as well as when and how it's appropriate to push changes to packages that a developer doesn't own.
[...]
In Fedora, packages are typically owned by a maintainer who has packager status. This status is not granted automatically—users have to have a sponsor and learn the ropes to be added to the "packager" group. Once added to the group, they then have the ability to commit changes to the repository for packages they own. Then the package can be submitted to Fedora's Koji build system to be built for a release. Each package repository has a branch for each release that the package exists in, so a package might have f39, f40, f41, and rawhide branches for Fedora 39 through Fedora 41 and Rawhide, for example.
There are many scenarios where packagers may wish to modify packages they do not own. For example, when a person is packaging an update to an application they may need a newer version of a library it depends on. If the owner of the library package has not gotten around to updating it yet, it can be inconvenient to wait for its maintainer to make the update. This is a common scenario in a project where some contributors are paid to work on packaging, while others are volunteers who check in infrequently as time allows. Anyone can submit a pull request (PR) to modify a package, even if they aren't a Fedora packager at all, but only the maintainer (or co-maintainers), can commit those changes.
-
LWN ☛ Systemd improves image features and adds varlink API [Ed: Systemd promoted by the Red Hatter at LWN]
The systemd v257 release brings a number of incremental enhancements to various components and utilities for working with Linux systems. This includes more support for varlink, automated downloading of disk images at boot time, and a number of improvements to the secure-boot process for unified kernel images (UKIs), which we have covered in a separate article.
Lennart Poettering announced the release The release was announced on December 10 to the systemd-devel mailing list, and Lennart Poettering followed up with a blog post that linked to his Mastodon threads about new features in v257.
-
LWN ☛ Systemd takes steps toward a more secure boot process [Ed: It's not security, it's IBM and Microsoft (back doors) asserting more control]
The systemd project has been working for some time on promoting unified kernel images (UKIs), a format that bundles a kernel, initial disk image, kernel command line, and other associated data into a single file. The advantage of the format is the ability to authenticate the entire collection with secure boot, which makes it easier for end users to know that their operating system hasn't been tampered with. The downside is the lack of flexibility and increase in disk usage, since all of the things packaged in a UKI must be updated together. But the recent systemd 257 release (along with other changes to be covered in a future article) includes some major changes to the UKI format, and the rest of the boot process, that partially mitigate those downsides. The release also includes improvements for hardware-locked disk encryption, which may also help secure some computers.