❌

Reading view

There are new articles available, click to refresh the page.

Someone Forked systemd Over Its New Birth Date Field

The blog Linuxiac reports: A new systemd fork has appeared with a specific purpose: removing systemd's recently added support for storing a user's birth date in JSON user records. The fork, called Liberated systemd, published its first tagged release as v261 shortly after the official systemd 261 release. In other words, the fork follows upstream systemd while reverting the change that added the new optional birthDate field. Importantly, this is not a new init system, a wider redesign of systemd, or a general-purpose alternative to the upstream project. Its stated purpose is to remain close to upstream systemd while removing what the author describes as "surveillance enablement"... The author recommends testing the fork in a virtual machine before using it on real hardware and warns nightly builds are more likely to be unstable than named releases.

Read more of this story at Slashdot.

After Six Years Of Work and Over 360 Patches, Linux 7.2 Finally Removes Bug-Prone strncpy

Tech Times reports: Linux 7.2's merge window closed out a cleanup campaign on Friday that most kernel developers had stopped expecting to see end: the complete removal of strncpy(), a C string-copy function that the kernel's own documentation labels "actively dangerous," from every subsystem, driver, and architecture-specific file in the kernel source tree. The merge landed June 20, 2026. After around 362 commits spread across six years of incremental work, no call site using the function remained, and the function itself β€” including the last per-CPU-architecture optimized implementations β€” was struck from the source. The removal matters beyond housekeeping. strncpy() is a persistent source of a specific class of memory error: kernel buffers that contain sensitive data can leak bytes past an unterminated string boundary, a pattern that enables memory disclosure vulnerabilities. Eliminating the function from the tree removes that entire class from the kernel's attack surface β€” and, critically, makes strncpy() unavailable to any future contributor, turning a best-practice suggestion into an enforced policy. Phoronix notes it's replaced by five different functions: In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies. "The reason five functions were needed," explains Tech Times, "is that different parts of the kernel were using strncpy() for five semantically distinct memory operations β€” each with a different intent, different termination requirement, and different padding behavior. " The original function obscured all of those differences under a single ambiguous name. The 362-commit campaign to replace it was, in effect, a codebase-wide audit that forced every call site to declare its actual intent in code That is an engineering outcome with lasting value: the kernel's string-handling semantics are now explicit where they were previously implicit, and future maintainers can read a function name and understand what a copy operation actually does.

Read more of this story at Slashdot.

❌