Project Status Update - week 8

Fall is here. And lots of things fell over this week security-wise. If you're in devops, it wasn't a good week. Fortunately there are fun things to report as well this week.

This week's image releases

Only one new "image" this week: the wsl-base 2026.10.2 image added a missing package.

This week's content releases (packages)

The desktop suites were busy this week and I built out the GNOME Circle apps suite as well. Here are the highlights:

• Linux-kernel-stable 7.2.12, and linux-firmware 20261019
• GNOME Circle has its own set now, +gnome-circle, and gained Citations, Decoder, Lorem, Pika Backup and Warp
• Papers, the new GNOME document viewer, and Snapshot joined the +gnome set, along with Loupe, Showtime, Decibels and GNOME Software
• Fingerprint login: libfprint and fprintd, in both +gnome and +plasma
• Plasma-6.8.1 (updated from 6.8.0), and the new Plasma Login Manager, Plasma's own display manager forked from SDDM. It's in a new +plasma-login set, and will replace SDDM.
• New desktop apps: OBS Studio 33, KeePassXC, virt-manager
• New on the server side: bind, postfix, clamav, haproxy, ntpsec, lxc and lxcfs, lldpd, linuxptp, and a pile of console tools like mutt and minicom
• llama.cpp, for running LLMs on your own hardware
• Python 3.15.1, Go 1.26.10, pipewire 1.6.10, webkitgtk 2.54.2, harfbuzz 15.0.0, nss 3.132, btrfs-progs 7.3
• Security fixes for the browser (CVE-2026-113470) and Go (CVE-2026-111943), with everything built with Go rebuilt
• More of the stateless work: glibc, openssl, linux-pam, p11-kit, systemd, dbus, polkit, sudo and others now read their defaults from /usr when /etc doesn't have them

This week's bugs and issues

• "Failed unmounting /usr/lib/modules/..." showed up at every shutdown. udevd still had the module index mapped, which pinned the whole modules image. The unmount is now left to the very last stage of shutdown.
• Security-related updates were on everyone's mind. There's a veritable wave of CVEs and I posted twice about this: Update your system and Vulnerable. Again, this is the new normal.

Reproducibility audit

We found 4 packages that failed to build reproducibly this week, and all 4 are fixed:

• shaderc-2026.1-6 and zxing-cpp-3.1.1-2: precompiled headers. The debug info depended on which precompiled header image gcc happened to load, so the build-id could change while the code was identical. Precompiled headers are now off for both, and glslang shipped with them off from the start.
• plasma-pa-6.8.1-2: a build-order race. With a parallel build, the applet's QML could be compiled before the type info it needs existed, and the output depended on which got there first. A patch adds the missing dependency.
• obs-studio-33.0.0-4: the release date in its metainfo was the day of the build. It's pinned to the actual release date now.

The reproducibility audit runs 24/7 and continues to rebuild existing packages over and over to validate our reproducible builds promise. If you spot a failure we haven't found yet, please let us know. The new page at Verifying reproducible builds shows how to rebuild a package yourself.

This week's dispatch changes (the builder and pkg)

• pkg now trusts the system CA store instead of a built-in copy of the web root certificates. It follows /etc/ca-certs/distrusted too, so roots that are removed from the store, like the three eMudhra roots NSS just dropped, stop being trusted by pkg as well.
• pkg fetch output is a lot shorter: one "fetched" line per package instead of one per payload. --collapse=none brings back the old view (see pkg(1)).
• Fixed a hang of up to 30 minutes in pkg when a proxy or server dropped a keep-alive connection during the early timestamp.json fetch. It now gives up after 10 seconds and falls back.
• The CVE tracking is being rebuilt from the ground up. The distro trackers we used gave mostly false positives and missed backports. The new data comes from the CVE List, NVD, and the OSV language ecosystems (crates.io, PyPI, Go, npm), matched to packages through curated identities (CPE, vendor/product, repo).
• The builder rejects packages that ship files under /run, /tmp, /var/tmp or /dev. samba was shipping /run/samba, which is wiped at boot anyway.
• Pushing to the public mirror moved out of dispatch into a separate tool, repo-sync. It pushes in parallel over many connections, and snapshots its sources so a repo roll mid-push stays consistent.

The fun stuff

I've always had a negative opinion about some OSS projects that grew too large and too fast, and IMHO were driven by feature creep into something that does way more with too many resources. I'm not saying that it's a fair judgement of them, but my approach is rooted in the work we did to make the Eee PC boot in 5 seconds - we have to do less work, not hide it.

Plymouth and grub2 are high on my list of things I just don't like. Not that they don't work. It's just that they're too complex, too large, and fragile.

But I do like fancy startup screens. Not because they're fancy, but because they show the one thing that matters - and nothing more. All the kernel boot-up messages are really just excess information that shouldn't be shown. Unless there's a serious error.

But I really don't think I want Plymouth. So this week I explored a way to get simple, text-only EFI framebuffer messaging that shows that systemd-boot is booting the default kernel, and at shutdown, the same framebuffer is repainted with a notification that the system is shutting down. All this does is reserve the "lower third" of the EFI framebuffer and paint some text in it. We can use this to "mask" systemd-boot and just show which default kernel we're booting. Press Esc and you get the default sd-boot menu (boot-manager.toml(5) shows how to hide or show it). Don't press it and the next screen is the GNOME login manager. At shutdown we hide all the shutdown messages, repaint the EFI logo, and print a message that the system is shutting down.

The cost? 1/50 of the codebase of Plymouth. No daemon starting in the initrd. A small patch to sd-boot, and a small userspace program for the other parts. There are some screenshots of how this looks on our Discord, and I'll write a longer post about it later.

Testing and validation

I added an (older) Xeon to my hardware testing pool this week, so now I have an x86_64-v4 architecture system running tests. That completes the set of -v2, -v3 and -v4. And it has an NVIDIA GPU (an older one), but it at least allows me to test nouveau. Hoarding? Not yet. Need more.

Documentation and website changes

• Governance: who runs the project, and how.
• Security: how Sandcastle is kept secure, and what to expect when you report a problem.
• Supported hardware: x86_64-v2, Secure Boot off, and nouveau only for NVIDIA. It's linked before every install.
• Developer docs: a recipe.toml reference and a glossary.
• Verifying reproducible builds is written out.
• The front page leads with the newest post.

What's next

I'm continuing to work on our CVE handling so that dispatch becomes an ally and not an obstruction to dealing with vulnerabilities. This is vital for keeping users safe.

The lowerthird project will become part of the default live-usb image. That needs a new image, so that will happen this week.

We'll upgrade our LLVM and Rust this week, and that means a new Buildroot-7.x chain gets built. This process takes about 2 days, after which Buildroot-6.4 will get retired, and the floor moves up. This is something that will happen every month or so, based on the current cadence of things.

I've made a goal to allow for some more visibility behind the scenes for users, without exposing dispatch-web directly to the internet, which I can't do for obvious security reasons. But there's so much stuff we could share with users on our website(s) that will help them understand the living and moving nature of the distribution and the build system, so that deserves time.

--sofar (aka Auke)