If you're still using Vagrant (I am) and try to boot a box that uses UEFI (like boxen/debian-13), a simple vagrant init boxen/debian-13 and vagrant up will entertain you with a nice traceback: The important part here is Of course we checked that the file permissions on this file are correct (I'll save you the ls output), so what's next? Yes, of course, SELinux! A process in the svirt_t domain tries to access something in the user_home_t domain and is denied by the kernel. So far, SELinux is both working as designed and preventing us from doing our work, nice. For "normal" (non-UEFI) boxes, Vagrant uploads the image to libvirt, which stores it in ~/.local/share/libvirt/images/ and boots fine from there. For UEFI boxen, one also needs loader and nvram files, which Vagrant keeps in ~/.vagrant.d/boxes/<box_name> and that's what explodes in our face here. As ~/.local/share/libvirt/images/ works well, and is labeled svirt_home_t let's see what other folders use that label: Okay, that all makes sense, and it's just missing the Vagrant-specific folders! Now relabel the Vagrant boxes: And it works!

In my post yesterday, ARM is great, ARM is terrible (and so is RISC-V), I described my desire to find ARM hardware with AES instructions to support full-disk encryption, and the poor state of the OS ecosystem around the newer ARM boards. I was anticipating buying either a newer ARM SBC or an x86 mini PC of some sort. More-efficient AES alternatives Always one to think, what if I didn t have to actually buy something , I decided to research whether it was possible to use encryption algorithms that are more performant on the Raspberry Pi 4 I already have. The answer was yes. From cryptsetup benchmark:

root@mccoy:~# cryptsetup benchmark --cipher=xchacha12,aes-adiantum-plain64 
# Tests are approximate using memory only (no storage IO).
#            Algorithm         Key        Encryption        Decryption
xchacha12,aes-adiantum        256b       159.7 MiB/s       160.0 MiB/s
xchacha20,aes-adiantum        256b       116.7 MiB/s       169.1 MiB/s
    aes-xts                   256b        52.5 MiB/s        52.6 MiB/s

With best-case reads from my SD card at 45MB/s (with dd if=/dev/mmcblk0 of=/dev/null bs=1048576 status=progress), either of the ChaCha-based algorithms will be fast enough. Great, I thought. Now I can just solve this problem without spending a dollar. But not so fast. Serial terminals vs. serial consoles My primary use case for this device is to drive my actual old DEC vt510 terminal. I have long been able to do that by running a getty for my FTDI-based USB-to-serial converter on /dev/ttyUSB0. This gets me a login prompt, and I can do whatever I need from there. This does not get me a serial console, however. The serial console would show kernel messages and could be used to interact with the pre-multiuser stages of the system that is, everything before the loging prompt. You can use it to access an emergency shell for repair, etc. Although I have long booted that kernel with console=tty0 console=ttyUSB0,57600, the serial console has never worked but I d never bothered investigating because the text terminal was sufficient. You might be seeing where this is going: to have root on an encrypted LUKS volume, you have to enter the decryption password in the pre-multiuser environment (which happens to be on the initramfs). So I started looking. First, I extracted the initrd with cpio and noticed that the ftdi_sio and usbserial modules weren t present. Added them to /etc/initramfs-tools/modules and rebooted; no better. So I found the kernel s serial console guide, which explicitly notes To use a serial port as console you need to compile the support into your kernel . Well, I have no desire to custom-build a kernel on a Raspberry Pi with MicroSD storage every time a new kernel comes out. I thought well I don t stricly need the kernel to know about the console on /dev/ttyUSB0 for this; I just need the password prompt which comes from userspace to know about it. So I looked at the initramfs code, and wouldn t you know it, it uses /dev/console. Looking at /proc/consoles on that system, indeed it doesn t show ttyUSB0. So even though it is possible to load the USB serial driver in the initramfs, there is no way to make the initramfs use it, because it only uses whatever the kernel recognizes as a console, and the kernel won t recognize this. So there is no way to use a USB-to-serial adapter to enter a password for an encrypted root filesystem. Drat. The on-board UARTs? I can hear you know: The Pi already has on-board serial support! Why not use that? Ah yes, the reason I don t want to use that is because it is difficult to use that, particularly if you want to have RTS/CTS hardware flow control (or DTR/DSR on these old terminals, but that s another story, and I built a custom cable to map it to RTS/CTS anyhow). Since you asked, I ll take you down this unpleasant path. The GPIO typically has only 2 pins for serial communication: 8 and 10, for TX and RX, respectively. But dive in and you get into a confusing maze of UARTs. The mini UART , the one we are mostly familiar with on the Pi, does not support hardware flow control. The PL011 does. So the natural question is: how do we switch to the PL011, and what pins does it use? Great questions, and the answer is undocumented, at least for the Pi 4. According to that page, for the Pi 4, the primary UART is UART1, UART1 is the mini UART, the secondary UART is not normally present on the GPIO connector and might be used by Bluetooth anyway, and there is no documented pin for RTS/CTS anyhow. (Let alone some of the other lines modems use) There are supposed to be /dev/ttyAMA* devices, but I don t have those. There s an enable_uart kernel parameter, which does things like stop the mini UART from changing baud rates every time the VPU changes clock frequency (I am not making this up!), but doesn t seem to control the PL011 UART selection. This page has a program to do it, and map some GPIO pins to RTS/CTS, in theory. Even if you get all that working, you still have the problem that the Pi UARTs (all of them of every type) is 3.3V and RS-232 is 5V, so unless you get a converter, you will fry your Pi the moment you connect it to something useful. So, you re probably looking at some soldering and such just to build a cable that will work with an iffy stack. So, I could probably make it work given enough time, but I don t have that time to spare working with weird Pi serial problems, so I have always used USB converters when I need serial from a Pi. Conclusion I bought a fanless x86 micro PC with a N100 chip and all the ports I might want: a couple of DB-9 serial ports, some Ethernet ports, HDMI and VGA ports, and built-in wifi. Done.

My trip to pgday.at started Wednesday at the airport in D sseldorf. I was there on time, and the plane started with an estimated flight time of about 90 minutes. About half an hour into the flight, the captain announced that we would be landing in 30 minutes - in D sseldorf, because of some unspecified technical problems. Three hours after the original departure time, the plane made another attempt, and we made it to Vienna.

On the plane I had already met Dirk Krautschick who had the great honor of bringing Slonik (in the form of a big extra bag) to the conference, and we took a taxi to the hotel. On the taxi, the next surprise happened: Hans-J rgen Sch nig unfortunately couldn't make it to the conference, and his talks had to be replaced. I had submitted a talk to the conference, but it was not accepted, and neither queued on the reserve list. But two speakers on the reserve list had cancelled, and another was already giving a talk in parallel to the slot that had to be filled, so Pavlo messaged me if I could hold the talk - well of course I could. Before, I didn't have any specific plans for the evening yet, but suddenly I was a speaker, so I joined the folks going to the speakers dinner at the Wiener Grill Haus two corners from the hotel. It was a very nice evening, chatting with a lot of folks from the PostgreSQL community that I had not seen for a while. Thursday was the conference day. The hotel was a short walk from the venue, the Apothekertrakt in Vienna's Schloss Sch nbrunn. The courtyard was already filled with visitors registering for the conference. Since I originally didn't have a talk scheduled, I had signed up to volunteer for a shift as room host. We got our badge and swag bag, and I changed into the "crew" T-shirt. The opening and sponsor keynotes took place in the main room, the Orangerie. We were over 100 people in the room, but apparently still not enough to really fill it, so the acoustics with some echo made it a bit difficult to understand everything. I hope that part can be improved for next time (which is planned to happen!). I was host for the Maximilian room, where the sponsor sessions were scheduled in the morning. The first talk was by our Peter Hofer, also replacing the absent Hans. He had only joined the company at the beginning of the same week, and was already tasked to give Hans' talk on PostgreSQL as Open Source. Of course he did well.

Next was Tanmay Sinha from Readyset. They are building a system that caches expensive SQL queries and selectively invalidates the cache whenever any data used by these queries changes. Whenever actually fixing the application isn't feasible, that system looks like an interesting alternative to manually maintaining materialized views, or perhaps using pg_ivm. After lunch, I went to Federico Campoli's Mastering Index Performance, but really spent the time polishing the slides for my talk. I had given the original version at pgconf.de in Berlin in May, and the slides were still in German, so I had to do some translating. Luckily, most slides are just git commit messages, so the effort was manageable. The next slot was mine, talking about Modern VACUUM. I started with a recap of MVCC, vacuum and freezing in PostgreSQL, and then showed how over the past years, the system was updated to be more focused (the PostgreSQL 8.4 visibility map tells vacuum which pages to visit), faster (12 made autovacuum run 10 times faster by default), less scary (14 has an emergency mode where freezing switches to maximum speed if it runs out of time; 16 makes freezing create much less WAL) and more performant (17 makes vacuum use much less memory). In summary, there is still room for the DBA to tune some knobs (for example, the default autovacuum_max_workers=3 isn't much), but the vacuum default settings are pretty much okay these days for average workloads. Specific workloads still have a whopping 31 postgresql.conf settings at their disposal just for vacuum.

Right after my talk, there was another vacuum talk: When Autovacuum Met FinOps by Mayuresh Bagayatkar. He added practical advice on tuning the performance in cloud environments. Luckily, our contents did not overlap. After the coffee break, I was again room host, now for Floor Drees and Contributing to Postgres beyond code. She presented the various ways in which PostgreSQL is more than just the code in the Git repository: translators, web site, system administration, conference organizers, speakers, bloggers, advocates. As a member of the PostgreSQL Contributors Committee, I could only approve and we should closer cooperate in the future to make people's contributions to PostgreSQL more visible and give them the recognition they deserve.

That was already the end of the main talks and everyone rushed to the Orangerie for the lightning talks. My highlight was the Sheldrick Wildlife Trust. Tickets for the conference had included the option to donate for the elephants in Kenya, and the talk presented the trust's work in the elephant orphanage there. After the conference had officially closed, there was a bonus track: the Celebrity DB Deathmatch, aptly presented by Boriss Mejias. PostgreSQL, MongoDB, CloudDB and Oracle were competing for the grace of a developer. MongoDB couldn't stand the JSON workload, CloudDB was dismissed for handing out new invoices all the time, and Oracle had even brought a lawyer to the stage, but then lost control over a literally 10 meter long contract with too much fine print. In the end, PostgreSQL (played by Floor) won the love of the developer (played by our Svitlana Lytvynenko).

The day closed with a gathering at the Brandauer Schlossbr u - just at the other end of the castle ground, but still a 15min walk away. We enjoyed good beer and Kaiserschmarrn. I went back to the hotel a bit before midnight, but some extended that time quite some bit more. On Friday, my flight back was only in the afternoon, so I spent some time in morning in the Technikmuseum just next to the hotel, enjoying some old steam engines and a live demonstration of Tesla coils. This time, the flight actually went to the destination, and I was back in D sseldorf in the late afternoon.

In summary, pgday.at was a very nice event in a classy location. Thanks to the organizers for putting in all the work - and next year, Hans will hopefully be present in person! The post A Trip To Vienna With Surprises appeared first on CYBERTEC PostgreSQL Services & Support.

I m something of a filesystem geek, I guess. I first wrote about ZFS on Linux 14 years ago, and even before I used ZFS, I had used ext2/3/4, jfs, reiserfs, xfs, and no doubt some others. I ve also used btrfs. I last posted about it in 2014, when I noted it has some advantages over ZFS, but also some drawbacks, including a lot of kernel panics. Since that comparison, ZFS has gained trim support and btrfs has stabilized. The btrfs status page gives you an accurate idea of what is good to use on btrfs. Background: Moving towards ZFS and btrfs I have been trying to move everything away from ext4 and onto either ZFS or btrfs. There are generally several reasons for that:

1. The checksums for every block help detect potential silent data corruption
2. Instant snapshots make consistent backups of live systems a lot easier, and without the hassle and wasted space of LVM snapshots
3. Transparent compression and dedup can save a lot of space in storage-constrained environments

For any machine with at least 32GB of RAM (plus my backup server, which has only 8GB), I run ZFS. While it lacks some of the flexibility of btrfs, it has polish. zfs list -o space shows a useful space accounting. zvols can be behind VMs. With my project simplesnap, I can easily send hourly backups with ZFS, and I choose to send them over NNCP in most cases. I have a few VMs in the cloud (running Debian, of course) that I use to host things like this blog, my website, my gopher site, the quux NNCP public relay, and various other things. In these environments, storage space can be expensive. For that matter, so can RAM. ZFS is RAM-hungry, so that rules out ZFS. I ve been running btrfs in those environments for a few years now, and it s worked out well. I do async dedup, lzo or zstd compression depending on the needs, and the occasional balance and defrag. Filesystems on the Raspberry Pi I run Debian trixie on all my Raspberry Pis; not Raspbian or Raspberry Pi OS for a number of reasons. My 8-yr-old uses a Raspberry Pi 400 as her primary computer and loves it! She doesn t do web browsing, but plays Tuxpaint, some old DOS games like Math Blaster via dosbox, and uses Thunderbird for a locked-down email account. But it was SLOW. Just really, glacially, slow, especially for Thunderbird. My first step to address that was to get a faster MicroSD card to hold the OS. That was a dramatic improvement. It s still slow, but a lot faster. Then, I thought, maybe I could use btrfs with LZO compression to reduce the amount of I/O and speed things up further? Analysis showed things were mostly slow due to I/O, not CPU, constraints. The conversion Rather than use the btrfs in-place conversion from ext4, I opted to dar it up (like tar), run mkfs.btrfs on the SD card, then unpack the archive back onto it. Easy enough, right? Well, not so fast. The MicroSD card is 128GB, and the entire filesystem is 6.2GB. But after unpacking 100MB onto it, I got an out of space error. btrfs has this notion of block groups. By default, each block group is dedicated to either data or metadata. btrfs fi df and btrfs fi usage will show you details about the block groups. btrfs allocates block groups greedily (the ssd_spread mount option I use may have exacerbated this). What happened was it allocated almost the entire drive to data block groups, trying to spread the data across it. It so happened that dar archived some larger files first (maybe /boot), so btrfs was allocating data and metadata blockgroups assuming few large files. But then it started unpacking one of the directories in /usr with lots of small files (maybe /usr/share/locale). It quickly filled up the metadata block group, and since the entire SD card had been allocated to different block groups, I got ENOSPC. Deleting a few files and running btrfs balance resolved it; now it allocated 1GB to metadata, which was plenty. I re-ran the dar extract and now everything was fine. See more details on btrfs balance and block groups. This was the only btrfs problem I encountered. Benchmarks I timed two things prior to switching to btrfs: how long it takes to boot (measured from the moment I turn on the power until the moment the XFCE login box is displayed), and how long it takes to start Thunderbird. After switching to btrfs with LZO compression, somewhat to my surprise, both measures were exactly the same! Why might this be? It turns out that SD cards are understood to be pathologically bad with random read performance. Boot and Thunderbird both are likely doing a lot of small random reads, not large streaming reads. Therefore, it may be that even though I have reduced the total I/O needed, the impact is unsubstantial because the real bottleneck is the seeks across the disk. Still, I gain the better backup support and silent data corruption prevention, so I kept btrfs. SSD mount options and MicroSD endurance btrfs has several mount options specifically relevant to SSDs. Aside from the obvious trim support, they are ssd and ssd_spread. The documentation on this is vague and my attempts to learn more about it found a lot of information that was outdated or unsubstantiated folklore. Some reports suggest that older SSDs will benefit from ssd_spread, but that it may have no effect or even a harmful effect on newer ones, and can at times cause fragmentation or write amplification. I could find nothing to back this up, though. And it seems particularly difficult to figure out what kind of wear leveling SSD firmware does. MicroSD firmware is likely to be on the less-advanced side, but still, I have no idea what it might do. In any case, with btrfs not updating blocks in-place, it should be better than ext4 in the most naive case (no wear leveling at all) but may have somewhat more write traffic for the pathological worst case (frequent updates of small portions of large files). One anecdotal report I read and can t find anymore, somehow was from a person that had set up a sort of torture test for SD cards, with reports that ext4 lasted a few weeks or months before the MicroSDs failed, while btrfs lasted years. If you are looking for a MicroSD card, by the way, The Great MicroSD Card Survey is a nice place to start. For longevity: I mount all my filesystems with noatime already, so I continue to recommend that. You can also consider limiting the log size in /etc/systemd/journald.conf, running daily fstrim (which may be more successful than live trims in all filesystems). Conclusion I ve been pretty pleased with btrfs. The concerns I have today relate to block groups and maintenance (periodic balance and maybe a periodic defrag). I m not sure I d be ready to say put btrfs on the computer you send to someone that isn t Linux-savvy because the chances of running into issues are higher than with ext4. Still, for people that have some tech savvy, btrfs can improve reliability and performance in other ways.

About 95% of my Debian contributions this month were sponsored by Freexian. You can also support my work directly via Liberapay or GitHub Sponsors. Python team forky is open! As a result I m starting to think about the upcoming Python 3.14. At some point we ll doubtless do a full test rebuild, but in advance of that I concluded that one of the most useful things I could do would be to work on our very long list of packages with new upstream versions. Of course there s no real chance of this ever becoming empty since upstream maintainers aren t going to stop work for that long, but there are a lot of packages there where we re quite a long way out of date, and many of those include fixes that we ll need for 3.14, either directly or by fixing interactions with new versions of other packages that in turn will need to be fixed. We can backport changes when we need to, but more often than not the most efficient way to do things is just to keep up to date. So, I upgraded these packages to new upstream versions (deep breath):

• aioftp
• aiosignal (building on work by IanLucca)
• audioop-lts
• celery
• djangorestframework
• djoser
• fpylll
• frozenlist
• git-repo-updater
• ipykernel
• klepto
• kombu
• multipart
• netmiko (sponsoring work by Eduardo Silva; contributed supporting fix upstream)
• pathos
• ppft
• pydantic
• pydantic-core
• pydantic-settings
• pylsqpack
• pymssql
• pytest-mock
• pytest-pretty
• pytest-repeat
• pytest-rerunfailures
• python-a2wsgi
• python-apptools (sponsoring work by Kathlyn Lara Murussi)
• python-asgiref
• python-asyncssh
• python-bitarray
• python-bitstring
• python-bytecode
• python-channels-redis
• python-charset-normalizer
• python-daphne
• python-django-analytical
• python-django-guid
• python-django-health-check
• python-django-pgbulk
• python-django-pgtrigger
• python-django-postgres-extra
• python-django-storages
• python-holidays
• python-httpx-sse
• python-icalendar
• python-lazy-model
• python-line-profiler
• python-lz4
• python-marshmallow-dataclass
• python-mastodon
• python-model-bakery
• python-oauthlib
• python-parse-type
• python-pathvalidate
• python-pgspecial
• python-processview
• python-pytest-subtests
• python-roman
• python-semantic-release
• python-testfixtures
• python-time-machine
• python-tokenize-rt
• python-typeguard
• python-typing-extensions
• python-urllib3
• pyupgrade
• requests (fixing CVE-2024-47081)
• responses
• zope.deferredimport
• zope.schema
• zope.testrunner

That s only about 10% of the backlog, but of course others are working on this too. If we can keep this up for a while then it should help. I packaged pytest-run-parallel, pytest-unmagic (still in NEW), and python-forbiddenfruit (still in NEW), all needed as new dependencies of various other packages. setuptools upstream will be removing the setup.py install command on 31 October. While this may not trickle down immediately into Debian, it does mean that in the near future nearly all Python packages will have to use pybuild-plugin-pyproject (note that this does not mean that they necessarily have to use pyproject.toml; this is just a question of how the packaging runs the build system). We talked about this a bit at DebConf, and I said that I d noticed a number of packages where this isn t straightforward and promised to write up some notes. I wrote the Python/PybuildPluginPyproject wiki page for this; I expect to add more bits and pieces to it as I find them. On that note, I converted several packages to pybuild-plugin-pyproject:

• billiard
• lazr.config
• python-timeline
• zope.sqlalchemy
• zope.testing

I fixed several build/test failures:

• aiosmtplib
• blinker
• ipykernel
• ipyparallel
• quart

I fixed some other bugs:

• austin: binutils now has a libsframe-dev package, please add an explicit build dependency
• python-django-pgbulk: Missing dependency on python3-typing-extensions (contributed upstream)
• python-maturin: Upcoming rust-which update

I reviewed Debian defaults: nftables as banaction and systemd as backend, but it looked as though nothing actually needed to be changed so we closed this with no action. Rust team Upgrading Pydantic was complicated, and required a rust-pyo3 transition (which Jelmer Vernoo started and Peter Michael Green has mostly been driving, thankfully), packaging rust-malloc-size-of (including an upstream portability fix), and upgrading several packages to new upstream versions:

• rust-serde
• rust-serde-derive
• rust-serde-json
• rust-smallvec
• rust-speedate
• rust-time
• rust-time-core
• rust-time-macros

bugs.debian.org I fixed bugs.debian.org: misspelled checkbox id uselessmesages , as well as a bug that caused incoming emails with certain header contents to go missing. OpenSSH I fixed openssh-server: refuses further connections after having handled PerSourceMaxStartups connections with a cherry-pick from upstream. Other bits and pieces I upgraded libfido2 to a new upstream version. I fixed mimalloc: FTBFS on armhf: cc1: error: -mfloat-abi=hard : selected architecture lacks an FPU, which was blocking changes to pendulum in the Python team. I also spent some time helping to investigate libmimalloc3: Illegal instruction Running mtxrun generate, though that bug is still open. I fixed various autopkgtest bugs in gssproxy, prompted by #1007 in Debusine. Since my old team is decommissioning Bazaar/Breezy code hosting in Launchpad (the end of an era, which I have distinctly mixed feelings about), I converted Storm to git.

• Debian packages:
  • chrony:
    • Bugs:
      • opened #1111222: 099-scfilter system test is flaky
  • debian-policy:
    • Bugs:
      • opened and replied to #1111126: Copyright format does not explain how to describe a license text itself
  • devscripts:
    • Bugs:
      • opened #1112065: uscan: Regression of handling @PACKAGE@ in upstream URL
  • firmware-free:
    • Merge requests:
      • merged !10: Build CIS files and keyspan_pda firmware from source
  • firmware-nonfree:
    • Bugs:
      • closed #920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend
      • closed #934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
      • closed #988335: RTL8125B Failure of key exchange and association
      • closed #1023631: firmware-misc-nonfree: Possibly missing firmware for Creative Labs Sound Blaster Z PCIe sound card
      • closed #1050852: firmware-misc-nonfree: System crashes and reboots when i915/kbl_dmc_ver1_04.bin is present
      • closed #1061430: firmware-realtek: Realtek 10ec:8136 wrongly identified as Fast Ethernet instead of Gigabit
      • closed #1062817: firmware-amd-graphics: Invalid UVD handle causes the graphics driver to crash
      • closed #1085387: iwlwifi: wifi does not work at startup, starts working after 2-3 reboots and then works fine
      • closed #1093167: firmware-nonfree: AMD NPU firmware is not packaged
      • replied to #1105064: firmware-realtek: Please add rtl_bt/rtl8723ds_fw.bin
      • replied to #1109015: Wifi not working anymore with new atheros firmware from experimental
    • Merge requests:
      • opened and merged !126: Refactor build for next upstream version and forky release cycle
      • opened and merged !127: Update to 20250808
    • Uploads:
      • uploaded version 20250808-1 to unstable
  • initramfs-tools:
    • Bugs:
      • closed #1108204: initramfs-tools: update-initramfs trigger does not update the initramfs in some cases
      • closed #1108924: initramfs-tools: Cannot boot Trixie d-i rc2 USB storage target riscv64 MODULES=most (missing: cdns3 cdns3_starfive)
    • Merge requests:
      • reviewed and closed !182: unmkinitramfs: handle both uppercase and lowercase hex numbers
      • merged !183: hook-functions: add modules for non-default checksums on btrfs
      • opened and merged !184: unmkinitramfs: Accept lower-case hex digits in cpio headers
    • Uploads:
      • uploaded version 0.150 to unstable
  • kernel-handbook:
    • Merge requests:
      • closed !7: Add disabling SECURITY_LOCKDOWN_LSM to chapter-common-tasks
      • reviewed and merged !10: chapter-common-tasks: Update linux headers common binary parameter
  • kernel-team:
    • Merge requests:
      • merged !9: Improvements to find-recent-urgent for meeting agenda
  • ktls-utils:
    • Uploads:
      • uploaded version 1.2.1-2 to unstable
      • uploaded version 1.2.1-3 to unstable
  • kup:
    • Uploads:
      • uploaded version 0.3.6-6 to unstable
  • linux:
    • Bugs:
      • closed #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601
      • replied to and closed #1108271: e2fsprogs: orphan_file prevents ro LVM snapshots from being mounted
      • replied to #1110193: r8169 Rx very slow; r8168 works fine
      • closed #1110780: linux-image-6.12.38+deb13-amd64: HID BPF support is not enabled by default
      • replied to #1111455: linux-image-6.12.41+deb13-amd64: kernel BUG at fs/netfs/read_collect.c:316 netfs: Can t donate prior to front
      • opened and closed #1111670: ext4 regression in 6.16.1
    • Merge requests:
      • reviewed !1382: Store build time signing key encrypted
      • closed !1507: Drop yama: Disable by default and use upstream default to restrict ptrace
      • reviewed !1577: [arm64] udeb: Add USB TYPE-C modules for usb-modules. Then enable MT6359_AUXADC and panel KD070FHFID015 for MediaTek devices
      • merged !1588: linux-misc-tools: Fix FTBFS on sparc64
      • merged !1597: [armhf] Add phy-gmii-sel module to nic-shared-modules udeb
      • merged !1598: d/c/defines.toml: Bump abi_suffix to +deb14 for unstable releases and define forky and trixie-backports releases
      • (LTS) opened !1600: Sign modules using an ephemeral key; bump ABI for every upload
      • merged !1601: Enable DRM_NOUVEAU_GSP_DEFAULT for Nvidia
      • reviewed !1602: Backport Store build time signing key encrypted
      • (LTS) opened and merged !1603: Sign modules using an ephemeral key; bump ABI for every upload
      • opened and merged !1613: bootconfig: Fix negative seeks on 32-bit with LFS enabled
      • opened !1615: Draft: Support for drivers in Rust
      • merged !1622: Sign modules and support lockdown always
    • Uploads:
      • uploaded version 6.16.3-1 to unstable
    • (LTS) Added some regression fixes to the bullseye-security branch, but did not upload it
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded version 6.1.147-1~deb11u1 to bullseye-security
  • linux-base:
    • Bugs:
      • replied to #1111052: Please increase default UDP receive buffer size (rmem_max)
    • Uploads:
      • uploaded version 4.14 to unstable
  • wireless-regdb:
    • Uploads:
      • (LTS) uploaded version 2025.07.10-1~deb12u1 to bookworm
• Debian non-package bugs:
  • general:
    • closed #1111472: general: Big issues with ThinkPad s Dual Mouse (Trackpad/Trackpoint) setup
  • installation-reports:
    • replied to #1111507: firmware-realtek-udeb missing rtl8168e-3.fw (needed for d-i)
  • release.debian.org:
    • (LTS) opened #1110340: bookworm-pu: package wireless-regdb/2025.07.10-1~deb12u1
• Mailing lists:
  • debian-devel:
    • replied to How do I fully test a watch file
    • replied to Please check open Merge Requests before your next upload
    • replied to Request to reconsider i386 (x86) port for Debian 13
  • debian-events-eu:
    • posted Debian Day/release party near Leuven, 16 August
  • debian-kernel:
    • replied to Agenda items for kernel-team meeting on 2025-08-06
    • posted Agenda items for kernel-team meeting on 2025-08-27
    • replied to Kernel Handbook - Out of date ABI maintenance info
  • debian-lts-announce:
    • posted [SECURITY] [DLA 4271-1] linux-6.1 security update
  • debian-www:
    • posted Stale copy of Debian Kernel Handbook
  • initramfs:
    • posted initramfs-tools 0.150 release
  • linux-trace-kernel:
    • posted [PATCH] bootconfig: Fix negative seeks on 32-bit with LFS enabled
  • stable:
    • replied to [PATCH 6.12 164/444] bootconfig: Fix unaligned access when building footer

Review: Regenesis, by C.J. Cherryh

Series:	Cyteen #2
Publisher:	DAW
Copyright:	January 2009
ISBN:	0-7564-0592-0
Format:	Mass market
Pages:	682

The main text below is an edited version of my original review of Regensis written on 2012-12-21. Additional comments from my re-read are after the original review. Regenesis is a direct sequel to Cyteen, picking up very shortly after the end of that book and featuring all of the same characters. It would be absolutely pointless to read this book without first reading Cyteen; all of the emotional resonance and world-building that make Regensis work are done there, and you will almost certainly know whether you want to read it after reading the first book. Besides, Cyteen is one of the best SF novels ever written and not the novel to skip. Because this is such a direct sequel, it's impossible to provide a good description of Regenesis without spoiling at least characters and general plot developments from Cyteen. So stop reading here if you've not yet read the previous book. I've had this book for a while, and re-read Cyteen in anticipation of reading it, but I've been nervous about it. One of the best parts of Cyteen is that Cherryh didn't belabor the ending, and I wasn't sure what part of the plot could be reasonably extended. Making me more nervous was the back-cover text that framed the novel as an investigation of who actually killed the first Ari, a question that was fairly firmly in the past by the end of Cyteen and that neither I nor the characters had much interest in answering. Cyteen was also a magical blend of sympathetic characters, taut tension, complex plotting, and wonderful catharsis, the sort of lightning in a bottle that can rarely be caught twice. I need not have worried. If someone had told me that Regenesis was another 700 pages of my favorite section of Cyteen, I would have been dubious. But that's exactly what it is. And the characters only care about Ari's murderer because it comes up, fairly late in the novel, as a clue in another problem. Ari and Justin are back in the safe laboratory environment of Reseune, safe now that politics are not trying to kill or control them. Yanni has taken over administration. There is a general truce, and even some deeper agreement. Everyone can take a breath and relax, albeit with the presence of Justin's father Jordan as an ongoing irritant. But broader Union politics are not stable: there is an election in progress for the Defense councilor that may break the tenuous majority in favor of Reseune and the Science Directorate, and Yanni is working out a compromise to gain more support by turning a terraforming project loose on a remote world. As the election and the politics heat up, interpersonal relationships abruptly deteriorate, tensions with Jordan sharply worsen, and there may be moles in Reseune's iron-clad security. Navigating the crisis while keeping her chosen family safe will once again tax all of Ari's abilities. The third section of Cyteen, where Ari finally has the tools to take fate into her own hands and starts playing everyone off against each other, is one of my favorite sections of any book. If it was yours as well, Regenesis is another 700 pages of exactly that. As an extension and revisiting, it does lose a bit of immediacy and surprise from the original. Regenesis is also less concerned with the larger questions of azi society, the nature of thought and personality, loyalty and authority, and the best model for the development of human civilization. It's more of a political thriller. But it's a political thriller that recaptures much of the drama and tension of Cyteen and is full of exceptionally smart and paranoid people thinking through all angles of a problem, working fast on their feet, and successfully navigating tricky and treacherous political landscapes. And, like Cyteen but unlike others of Cherryh's novels I've read, it's a novel about empowerment, about seizing control of one's surroundings and effectively using all of the capability and leverage at one's fingertips. That gives it a catharsis that's almost as good as Cyteen. It's also, like its predecessor, a surprisingly authoritarian novel. I think it's in that, more than anything else in these books, that one sees the impact of the azi. Regenesis makes it clear that the story is set, not in a typical society, but inside a sort of corporation, with an essentially hierarchical governance structure. There are other SF novels set within corporations (Solitaire comes to mind), but normally they follow peons or at best mid-level personnel or field agents, or otherwise take the viewpoint of the employees or the exploited. When they follow the corporate leaders, the focus usually isn't down inside the organization, but out into the world, with the corporation as silent resources on which the protagonist can draw. Regenesis is instead about the leadership. It's about decisions about the future of humanity that characters feel they can make undemocratically (in part because they or their predecessors have effectively engineered the opinions of the democratic population), but it's also about how one manages and secures a top-down organization. Reseune is, as in the previous novel, a paranoid's suspicions come true; everyone is out to get everyone else, or at least might be, and the level of omnipresent security and threat forces a close parsing of alliances and motivations that elevates loyalty to the greatest virtue. In Cyteen, we had long enough with Ari to see the basic shape of her personality and her slight divergences from her predecessor, but her actions are mostly driven by necessity. Regenesis gives us more of a picture of what she's like when her actions aren't forced, and here I think Cherryh manages a masterpiece of subtle characterization. Ari has diverged substantially from her predecessor without always realizing, and those divergences are firmly grounded in the differences she found or created between her life and the first Ari's. She has friends, confidents, and a community, which combined with past trauma has made her fiercely, powerfully protective. It's that protective instinct that weaves the plot together. So many of the events of Cyteen and Regenesis are driven by people's varying reactions to trauma. If you, like me, loved the last third of Cyteen, read this, because Regenesis is more of exactly that. Cherryh finds new politics, new challenges, and a new and original plot within the same world and with the same characters, but it has the same feel of maneuvering, analysis, and decisive action. You will, as with Cyteen have to be comfortable with pages of internal monologue from people thinking through all sides of a problem. If you didn't like that in the previous book, avoid this one; if you loved it, here's the sequel you didn't know you were waiting for. Original rating: 9 out of 10

---

Some additional thoughts after re-reading Regenesis in 2025: Cyteen mostly held up to a re-reading and I had fond memories of Regenesis and hoped that it would as well. Unfortunately, it did not. I think I can see the shape of what I enjoyed the first time I read it, but I apparently was in precisely the right mood for this specific type of political power fantasy. I did at least say that you have to be comfortable with pages of internal monologue, but on re-reading, there was considerably more of that than I remembered and it was quite repetitive. Ari spends most of the book chasing her tail, going over and around and beside the same theories that she'd already considered and worrying over the nuances of every position. The last time around, I clearly enjoyed that; this time, I found it exhausting and not very well-written. The political maneuvering is not that deep; Ari just shows every minutia of her analysis. Regenesis also has more about the big questions of how to design a society and the role of the azi than I had remembered, but I'm not sure those discussions reach any satisfying conclusions. The book puts a great deal of effort into trying to convince the reader that Ari is capable of designing sociological structures that will shape Union society for generations to come through, mostly, manipulation of azi programming (deep sets is the term used in the book). I didn't find this entirely convincing the first time around, and I was even less convinced in this re-read. Human societies are a wicked problem, and I don't find Cherryh's computer projections any more convincing than Asimov's psychohistory. Related, I am surprised, in retrospect, that the authoritarian underpinnings of this book didn't bother me more on my first read. They were blatantly obvious on the second read. This felt like something Cherryh put into these books intentionally, and I think it's left intentionally ambiguous whether the reader is supposed to agree with Ari's goals and decisions, but I was much less in the mood on this re-read to read about Ari making blatantly authoritarian decisions about the future of society simply because she's smart and thinks she, unlike others, is acting ethically. I say this even though I like Ari and mostly enjoyed spending time in her head. But there is a deep fantasy of being able to reprogram society at play here that looks a lot nastier from the perspective of 2025 than apparently it did to me in 2012. Florian and Catlin are still my favorite characters in the series, though. I find it oddly satisfying to read about truly competent bodyguards, although like all of the azi they sit in an (I think intentionally) disturbing space of ambiguity between androids and human slaves. The somewhat too frank sexuality from Cyteen is still present in Regenesis, but I found it a bit less off-putting, mostly because everyone is older. The authoritarian bent is stronger, since Regenesis is the story of Ari consolidating power rather than the underdog power struggle of Cyteen, and I had less tolerance for it on this re-read. The main problem with this book on re-read was that I bogged down about halfway through and found excuses to do other things rather than finish it. On the first read, I was apparently in precisely the right mood to read about Ari building a fortified home for all of her friends; this time, it felt like endless logistics and musings on interior decorating that didn't advance the plot. Similarly, Justin and Grant's slow absorption into Ari's orbit felt like a satisfying slow burn friendship in my previous reading and this time felt touchy and repetitive. I was one of the few avid defenders of Regenesis the first time I read it, and sadly I've joined the general reaction on a re-read: This is not a very good book. It's too long, chases its own tail a bit too much, introduces a lot more authoritarianism and doesn't question it as directly as I wanted, and gets even deeper into Cherryh's invented pseudo-psychology than Cyteen. I have a high tolerance for the endless discussions of azi deep sets and human flux thinking, and even I got bored this time through. On re-read, this book was nowhere near as good as I thought it was originally, and I would only recommend it to people who loved Cyteen and who really wanted a continuation of Ari's story, even if it is flabby and not as well-written. I have normally been keeping the rating of my first read of books, but I went back and lowered this one by two points to ensure it didn't show as high on my list of recommendations.

Re-read rating: 6 out of 10

Here s my monthly but brief update about the activities I ve done in the F/L/OSS world.

Debian

Debian 13 was released! Woot! Whilst I didn t get a chance to do much, here s still a few things that I worked on:

• Helped Anshul with Golang 1.25 packaging and upload.
• Assited Anshul in fixing Golang bugs in the stable release via a -pu.
• Mentoring for newcomers.
• Moderation of -project mailing list.

---

Ubuntu

I joined Canonical to work on Ubuntu full-time back in February 2021. Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:

• Released Questing snapshot 4! \o/
• Prepared for 25.10 Beta, held weekly release syncs, et al.
• Granted FFe and triaged a bunch of other bugs from both, Release team and Archive Admin POV. :)
• Got a recognition award for helping Chlo with Google Guest Agent packages.
• Preparing for the a round of internal review, 360s, and trying to not be sick. :)

---

Debian (E)LTS

This month I have worked 16.00 hours on Debian Long Term Support (LTS) and 4.50 hours on its sister Extended LTS project and did the following things:

• [LTS] Prepared the LTS update for wordpress, bumping the package from 5.7.11 to 5.7.13.
  • Prepared an update for stable, too, and pinged Craig. Haven t heard yet.
  • Got incredibly sick so will carry on the coordination work and release the updates to all the releases. Everything s mostly ready and tested.
  • Gave Salvatore a quick heads up via IRC.
• [E/LTS] Frontdesk duty from 28th July to 04th August.
  • Triaged a bunch of packages and CVEs.
  • Raised an inconsistency about issues being fixed in buster & bookworm but not in bullseye.
  • Also triaged some newly supported packages for ELTS.
• [E/LTS] Helped Daniel Leidert in showing him around as he did his first frontdesk rota. Yay!
  • We paired on an hour long meets call and discussed various toolings and workflows.
  • Pair-reviewed a few CVEs together.
  • Also discussed how to triage newly supported packages for ELTS, too!
• [LTS] Attended the monthly LTS meeting on Jitsi. Summary here.
  • [ELTS] Raised questions about installing debusine on Ubuntu.
    • Still trying to play around to get a bit more comfortable before starting to do actual uploads there.
• [LTS] Helping a few folks - like assisting Lee to see if we have a reproducer for CVE-2025-27613 for git, et al.
• [Stable] Been working on fixing 2 packages:
  • ruby-graphql: The Debian Security team asked to fix that via p-u so prepared a patch update.
  • ruby-saml: The update is finally ready but not tested yet - should be a quick one though.
  • Got incredibly sick and couldn t move things forward but will take care of the work in the following month.

---

Until next time.
:wq for today.

Motivation On the 8th of August 2025 (a day before the Debian Trixie release), I was upgrading my personal laptop from Debian Bookworm to Trixie. It was a major update. However, the update didn t go smoothly, and I ran into some errors. From the Debian support IRC channel, I got to know that it would be best if I removed the texlive packages. However, it was not so easy to just remove texlive with a simple apt remove command. I had to remove the texlive packages from /usr/bin. Then I ran into other errors. Hours after I started the upgrade, I realized I preferred having my system as it was before, as I had to travel to Noida the next day. Needless to say, I wanted to go to sleep rather than fix my broken system. Only if I had a way to go back to my system before I started upgrading, it would have saved a lot of trouble for me. I ended up installing Trixie from scratch. It turns out that there was a way to recover to the state before the upgrade - using Timeshift to roll back the system to a state (in our example, it is the state before the upgrade process started) in the past. However, it needs the Btrfs filesystem with appropriate subvolumes, not provided by Debian installer in their guided partitioning menu. I have set it up after a few weeks of the above-mentioned incident. Let me demonstrate how it works.

Check the screenshot above. It shows a list of snapshots made by Timeshift. Some of them were made by me manually. Others were made by Timeshift automatically as per the routine - I have set up hourly backups and weekly backups etc. In the above-mentioned major update, I could have just taken a snapshot using Timeshift before performing the upgrade and could have rolled back to that snapshot when I found that I cannot spend more time on fixing my installation errors. Then I could just perform the upgrade later.

Installation In this tutorial, I will cover how I installed Debian with Btrfs and disk encryption, along with creating subvolumes @ for root and @home for /home so that I can use Timeshift to create snapshots. These snapshots are kept on the same disk where Debian is installed, and the use-case is to roll back to a working system in case I mess up something or to recover an accidentally deleted file. I went through countless tutorials on the Internet, but I didn t find a single tutorial covering both the disk encryption and the above-mentioned subvolumes (on Debian). Debian doesn t create the desired subvolumes by default, therefore the process requires some manual steps, which beginners may not be comfortable performing. Beginners can try distros such as Fedora and Linux Mint, as their installation includes Btrfs with the required subvolumes. Furthermore, it is pertinent to note that I used Debian Trixie s DVD iso on a real laptop (not a virtual machine) for my installation. Debian Trixie is the codename for the current stable version of Debian. Then I took screenshots in a virtual machine by repeating the process. Moreover, a couple of screenshots are from the installation I did on the real laptop. Let s start the tutorial by booting up the Debian installer.

The above screenshot shows the first screen we see on the installer. Since we want to choose Expert Install, we select Advanced Options in the screenshot above.

Let s select the Expert Install option in the above screenshot. It is because we want to create subvolumes after the installer is done with the partition, and only then proceed to installing the base system. Non-expert install modes proceed directly to installing the system right after creating partitions without pausing for us to create the subvolumes.

After selecting the Expert Install option, you will get the screen above. I will skip to partitioning from here and leave the intermediate steps such as choosing language, region, connecting to Wi-Fi, etc. For your reference, I did create the root user.

Let s jump right to the partitioning step. Select the Partition disks option from the menu as shown above.

Choose Manual.

Select your disk where you would like to install Debian.

Select Yes when asked for creating a new partition.

I chose the msdos option as I am not using UEFI. If you are using UEFI, then you need to choose the gpt option. Also, your steps will (slightly) differ from mine if you are using UEFI. In that case, you can watch this video by the YouTube channel EF Linux in which he creates an EFI partition. As he doesn t cover disk encryption, you can continue reading this post after following the steps corresponding to EFI.

Select the free space option as shown above.

Choose Create a new partition.

I chose the partition size to be 1 GB.

Choose Primary.

Choose Beginning.

Now, I got to this screen.

I changed mount point to /boot and turned on the bootable flag and then selected Done setting up the partition.

Now select free space.

Choose the Create a new partition option.

I made the partition size equal to the remaining space on my disk. I do not intend to create a swap partition, so I do not need more space.

Select Primary.

Select the Use as option to change its value.

Select physical volume for encryption.

Select Done setting up the partition.

Now select Configure encrypted volumes.

Select Yes.

Select Finish.

Selecting Yes will take a lot of time to erase the data. Therefore, I would say if you have hours for this step (in case your SSD is like 1 TB), then I would recommend selecting Yes. Otherwise, you could select No and compromise on the quality of encryption. After this, you will be asked to enter a passphrase for disk encryption and confirm it. Please do so. I forgot to take the screenshot for that step.

Now select that encrypted volume as shown in the screenshot above.

Here we will change a couple of options which will be shown in the next screenshot.

In the Use as menu, select btrfs journaling file system.

Now, click on the mount point option.

Change it to / - the root file system.

Select Done setting up the partition.

This is a preview of the paritioning after performing the above-mentioned steps.

If everything is okay, proceed with the Finish partitioning and write changes to disk option.

The installer is reminding us to create a swap partition. I proceeded without it as I planned to add swap after the installation.

If everything looks fine, choose yes for writing the changes to disks.

Now we are done with partitioning and we are shown the screen in the screenshot above. If we had not selected the Expert Install option, the installer would have proceeded to install the base system without asking us. However, we want to create subvolumes before proceeding to install the base system. This is the reason we chose Expert Install. Now press Ctrl + F2.

You will see the screen as in the above screenshot. It says Please press Enter to activate this console. So, let s press Enter.

After pressing Enter, we see the above screen.

The screenshot above shows the steps I performed in the console. I followed the already mentioned video by EF Linux for this part and adapted it to my situation (he doesn t encrypt the disk in his tutorial). First we run df -h to have a look at how our disk is partitioned. In my case, the output was:

# df -h
Filesystem              Size  Used  Avail   Use% Mounted on
tmpfs                   1.6G  344.0K  1.6G    0% /run
devtmpfs                7.7G       0  7.7G   0% /dev
/dev/sdb1               3.7G    3.7G    0   100% /cdrom
/dev/mapper/sda2_crypt  952.9G  5.8G  950.9G  0% /target
/dev/sda1               919.7M  260.0K  855.8M  0% /target/boot

df -h shows us that /dev/mapper/sda2_crypt and /dev/sda1 are mounted on /target and /target/boot respectively. Let s unmount them. For that, we run:

# umount /target
# umount /target/boot

Next, let s mount our root filesystem to /mnt.

# mount /dev/mapper/sda2_crypt /mnt

Let s go into the /mnt directory.

# cd /mnt

Upon listing the contents of this directory, we get:

/mnt # ls
@rootfs

Debian installer has created a subvolume @rootfs automatically. However, we need the subvolumes to be @ and @home. Therefore, let s rename the @rootfs subvolume to @.

/mnt # mv @rootfs @

Listing the contents of the directory again, we get:

/mnt # ls
@

We only one subvolume right now. Therefore, let us go ahead and create another subvolume @home.

/mnt # btrfs subvolume create @home
Create subvolume './@home'

If we perform ls now, we will see there are two subvolumes:

/mnt # ls
@ @home

Let us mount /dev/mapper/sda2_crypt to /target

/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@ /dev/mapper/sda2_crypt /target/

Now we need to create a directory for /home.

/mnt # mkdir /target/home/

Now we mount the /home directory with subvol=@home option.

/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@home /dev/mapper/sda2_crypt /target/home/

Now mount /dev/sda1 to /target/boot.

/mnt # mount /dev/sda1 /target/boot/

Now we need to add these options to the fstab file, which is located at /target/etc/fstab. Unfortunately, vim is not installed in this console. The only way to edit is Nano.

nano /target/etc/fstab

Edit your fstab file to look similar to the one in the screenshot above. I am pasting the fstab file contents below for easy reference.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda2_crypt /        btrfs   noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@ 0       0
/dev/mapper/sda2_crypt /home    btrfs   noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@home 0       0
# /boot was on /dev/sda1 during installation
UUID=12842b16-d3b3-44b4-878a-beb1e6362fbc /boot           ext4    defaults        0       2
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Please double check the fstab file before saving it. In Nano, you can press Ctrl+O followed by pressing Enter to save the file. Then press Ctrl+X to quit Nano. Now, preview the fstab file by running

cat /target/etc/fstab

and verify that the entries are correct, otherwise you will booted to an unusable and broken system after the installation is complete. Next, press Ctrl + Alt + F1 to go back to the installer.

Proceed to Install the base system.

Screenshot of Debian installer installing the base system.

I chose the default option here - linux-image-amd64. After this, the installer will ask you a few more questions. For desktop environment, I chose KDE Plasma. You can choose the desktop environment as per your liking. I will not cover the rest of the installation process and assume that you were able to install from here.

Post installation Let s jump to our freshly installed Debian system. Since I created a root user, I added the user ravi to the suoders file (/etc/sudoers) so that ravi can run commands with sudo. Follow this if you would like to do the same. Now we set up zram as swap. First, install zram-tools.

sudo apt install zram-tools

Now edit the file /etc/default/zramswap and make sure to have the following lines are uncommented:

ALGO=lz4
PERCENT=50

Now, run

sudo systemctl restart zramswap

If you run lsblk now, you should see the below-mentioned entry in the output:

zram0          253:0    0   7.8G  0 disk  [SWAP]

This shows us that zram has been activated as swap. Now we install timeshift, which can be done by running

sudo apt install timeshift

After the installation is complete, run Timeshift and schedule snapshots as you please. We are done now. Hope the tutorial was helpful. See you in the next post and let me know if you have any suggestions and questions on this tutorial.

Posted on August 28, 2025
Tags: madeof:atoms, craft:sewing, FreeSoftWear

A bit more than a year ago, I had been thinking about making myself a cartridge pleated skirt. For a number of reasons, one of which is the historybounding potential, I ve been thinking pre-crinoline, so somewhere around the 1840s, and that s a completely new era for me, which means: new underwear. Also, the 1840s are pre-sewing machine, and I was already in a position where I had more chances to handsew than to machine sew, so I decided to embrace the slowness and sew 100% by hand, not even using the machine for straight seams. If I remember correctly, I started with the corded petticoat, looking around the internet for instructions, and then designing my own based on the practicality of using modern wide fabric from my stash (and specifically some DITTE from costumers favourite source of dirty cheap cotton IKEA). Around the same time I had also acquired a sashiko kit, and I used the Japanese technique for sewing running stitches pushing the needle with a thimble that covers the base of the middle finger, and I can confirm that for this kind of things it s great! I ve since worn the petticoat a few times for casual / historyBounding / folkwearBounding reasons, during the summer, and I can confirm it s comfortable to use; I guess that during the winter it could be nice to add a flannel layer below it. Then I proceeded with the base layers: I had been browsing through The workwoman's guide and that provided plenty of examples, and I selected the basic ankle-length drawers from page 53 and the alternative shift on page 47. As for fabric, I had (and still have) a significant lack of underwear linen in my stash, but I had plenty of cotton voile that I had not used in a while: not very historically accurate for plain underwear, but quite suitable for a wearable mockup. Working with a 1830s source had an interesting aspect: other of the usual, mildly annoying, imperial units, it also used a lot a few obsolete units, especially nails, that my qalc, my usual calculator and converter, doesn t support. Not a big deal, because GNU units came to the rescue, and that one knows a lot of obscure and niche units, and it s quite easy to add those that are missing¹ Working on this project also made me freshly aware of something I had already noticed: converting instructions for machine sewing garments into instructions for hand sewing them is usually straightforward, but the reverse is not always true. Starting from machine stitching, you can usually convert straight stitches into backstitches (or running backstitches), zigzag and overlocking into overcasting and get good results. In some cases you may want to use specialist hand stitches that don t really have a machine equivalent, such as buttonhole stitches instead of simply overcasting the buttonhole, but that s it. Starting from hand stitching, instead, there are a number of techniques that could be converted to machine stitching, but involve a lot of visible topstitching that wasn t there in the original instructions, or at times are almost impossible to do by machine, if they involve whipstitching together finished panels on seams that are subject to strong tension. Anyway, halfway through working with the petticoat I cut both the petticoat and the drawers at the same time, for efficiency in fabric use, and then started sewing the drawers. The book only provided measurements for one size (moderate), and my fabric was a bit too narrow to make them that size (not that I have any idea what hip circumference a person of moderate size was supposed to have), so the result is just wide enough to be comfortably worn, but I think that when I ll make another pair I ll try to make them a bit wider. On the other hand they are a bit too long, but I think that I ll fix it by adding a tuck or two. Not a big deal, anyway. The shift gave me a bit more issues: I used the recommended gusset size, and ended up with a shift that was way too wide at the top, so I had to take a box pleat in the center front and back, which changed the look and wear of the garment. I have adjusted the instructions to make gussets wider, and in the future I ll make another shift following those. Even with the pleat, the narrow shoulder straps are set quite far to the sides, and they tend to droop, and I suspect that this is to be expected from the way this garment is made. The fact that there are buttonholes on the shoulder straps to attach to the corset straps and prevent the issue is probably a hint that this behaviour was to be expected. I ve also updated the instructions so that they shoulder straps are a bit wider, to look more like the ones in the drawing from the book. Making a corset suitable for the time period is something that I will probably do, but not in the immediate future, but even just wearing the shift under a later midbust corset with no shoulder strap helps. I m also not sure what the point of the bosom gores is, as they don t really give more room to the bust where it s needed, but to the high bust where it s counterproductive. I also couldn t find images of original examples made from this pattern to see if they were actually used, so in my next make I may just skip them. On the other hand, I m really happy with how cute the short sleeves look, and if² I ll ever make the other cut of shift from the same book, with the front flaps, I ll definitely use these pleated sleeves rather than the straight ones that were also used at the time. As usual, all of the patterns have been published on my website under a Free license:

• pattern for the petticoat;
• pattern for the shift;
• pattern for the drawers.

---

1. My ~/.units file currently contains definitions for beardseconds, bananas and the more conventional Nm and NeL (linear mass density of fibres).
2. yeah, right. when.

I originally setup a machine without any full disk encryption, then somehow regretted it quickly after. My original reasoning was that this was a "play" machine so I wanted as few restrictions on accessing the machine as possible, which meant removing passwords, mostly. I actually ended up having a user password, but disabled the lock screen. Then I started using the device to manage my photo collection, and suddenly there was a lot of "confidential" information on the device that I didn't want to store in clear text anymore.

Pre-requisites So, how does one convert an existing install from plain text to full disk encryption? One way is to backup to an external drive, re-partition everything and copy things back, but that's slow and boring. Besides, cryptsetup has a cryptsetup-reencrypt command, surely we can do this in place? Having not set aside enough room for /boot, I briefly considered a "encrypted /boot" configuration and conversion (e.g. with this guide) but remembered grub's support for this is flaky, at best, so I figured I would try something else. Here, I'm going to guide you through how I first converted from grub to systemd-boot then to UKI kernel, then re-encrypt my main partition. Note that secureboot is disabled here, see further discussion below.

systemd-boot and Unified Kernel Image conversion systemd folks have been developing UKI ("unified kernel image") to ship kernels. The way this works is the kernel and initrd (and UEFI boot stub) in a single portable executable that lives in the EFI partition, as opposed to /boot. This neatly solves my problem, because I already have such a clear-text partition and won't need to re-partition my disk to convert. Debian has started some preliminary support for this. It's not default, but I found this guide from Vasudeva Kamath which was pretty complete. Since the guide assumes some previous configuration, I had to adapt it to my case. Here's how I did the conversion to both systemd-boot and UKI, all at once. I could have perhaps done it one at a time, but doing both at once works fine. Before your start, make sure secureboot is disabled, see the discussion below.

1. install systemd tools:

   apt install systemd-ukify systemd-boot
   

2. Configure systemd-ukify, in /etc/kernel/install.conf:

   layout=uki
   initrd_generator=dracut
   uki_generator=ukify
   

   TODO: it doesn't look like this generates a initrd with dracut, do we care?
3. Configure the kernel boot arguments with the following in /etc/kernel/uki.conf:

   [UKI]
   Cmdline=@/etc/kernel/cmdline
   

   The /etc/kernel/cmdline file doesn't actually exist here, and that's fine. Defaults are okay, as the image gets generated from your current /proc/cmdline. Check your /etc/default/grub and /proc/cmdline if you are unsure. You'll see the generated arguments in bootctl list below.
4. Build the image:

   dpkg-reconfigure linux-image-$(uname -r)
   

5. Check the boot options:

   bootctl list
   

   Look for a Type #2 (.efi) entry for the kernel.
6. Reboot:

   reboot
   

You can tell you have booted with systemd-boot because (a) you won't see grub and (b) the /proc/cmdline will reflect the configuration listed in bootctl list. In my case, a systemd.machine_id variable is set there, and not in grub (compare with /boot/grub/grub.cfg). By default, the systemd-boot loader just boots, without a menu. You can force the menu to show up by un-commenting the timeout line in /boot/efit/loader/loader.conf, by hitting keys during boot (e.g. hitting "space" repeatedly), or by calling:

systemctl reboot --boot-loader-menu=0

See the systemd-boot(7) manual for details on that. I did not go through the secureboot process, presumably I had already disabled secureboot. This is trickier: because one needs a "special key" to sign the UKI image, one would need the collaboration of debian.org to get this working out of the box with the keys shipped onboard most computers. In other words, if you want to make this work with secureboot enabled on your computer, you'll need to figure out how to sign the generated images before rebooting here, because otherwise you will break your computer. Otherwise, follow the following guides:

• Enabling Secure Boot with UKI on Debian
• Disabling Lockdown Mode with Secure Boot on Distro Kernel
• Signing the systemd-boot on Upgrade Using Dpkg Triggers

Re-encrypting root filesystem Now that we have a way to boot an encrypted filesystem, we can switch to LUKS for our filesystem. Note that you can probably follow this guide if, somehow, you managed to make grub work with your LUKS setup, although as this guide shows, you'd need to downgrade the cryptographic algorithms, which seems like a bad tradeoff. We're using cryptsetup-reencrypt for this which, amazingly, supports re-encrypting devices on the fly. The trick is it needs free space at the end of the partition for the LUKS header (which, I guess, makes it a footer), so we need to resize the filesystem to leave room for that, which is the trickiest bit. This is a possibly destructive behavior. Be sure your backups are up to date, or be ready to lose all data on the device. We assume 512 byte sectors here. Check your sector size with fdisk -l and adjust accordingly.

1. Before you perform the procedure, make sure requirements are installed:

   apt install cryptsetup systemd-cryptsetup cryptsetup-initramfs
   

   Note that this requires network access, of course.
2. Reboot in a live image, I like GRML but any Debian live image will work, possibly including the installer
3. First, calculate how many sectors to free up for the LUKS header

   qalc> 32Mibyte / ( 512 byte )
     (32 mebibytes) / (512 bytes) = 65536
   

4. Find the sector sizes of the Linux partitions:

   fdisk  -l /dev/nvme0n1   awk '/filesystem/   print $1 " " $4  '  
   

   For example, here's an example with a /boot and / filesystem:

   $ sudo fdisk -l /dev/nvme0n1   awk '/filesystem/   print $1 " " $4  '
   /dev/nvme0n1p2 999424
   /dev/nvme0n1p3 3904979087
   

5. Substract 1 from 2:

   qalc> set precision 100
   qalc> 3904979087 - 65536
   

   Or, last step and this one, in one line:

   fdisk -l /dev/nvme0n1   awk '/filesystem/   print $1 " " $4 - 65536  '
   

6. Recheck filesystem:

   e2fsck -f /dev/nvme0n1p2
   

7. Resize filesystem:

   resize2fs /dev/nvme0n1p2 $(fdisk -l /dev/nvme0n1   awk '/nvme0n1p2/   print $4 - 65536  ')s
   

   Notice the trailing s here: it makes resize2fs interpret the number as a 512 byte sector size, as opposed to the default (4k blocks).
8. Re-encrypt filesystem:

   cryptsetup reencrypt --encrypt /dev/nvme0n1p2 --resize-device-size=32M
   

   This is it! This is the most important step! Make sure your laptop is plugged in and try not to interrupt it. This can, apparently, be resumed without problem, but I'd hate to show you how. This will show progress information like:

   Progress:   2.4% ETA 23m45s,      53GiB written, speed   1.3 GiB/s
   

   Wait until the ETA has passed.
9. Open and mount the encrypted filesystem and mount the EFI system partition (ESP):

   cryptsetup open /dev/nvme0n1p2 crypt
   mount /dev/mapper/crypt /mnt
   mount /dev/nvme0n1p1 /mnt/boot/efi
   

   If this fails, now is the time to consider restoring from backups.
10. Enter the chroot

    for fs in proc sys dev ; do
      mount --bind /$fs /mnt/$fs
    done
    chroot /mnt
    

    Pro tip: this can be done in one step in GRML with:

    grml-chroot /mnt bash
    

11. Generate a crypttab:

    echo crypt_dev_nvme0n1p2 UUID=$(blkid -o value -s UUID /dev/nvme0n1p2) none luks,discard >> /etc/crypttab
    

12. Adjust root filesystem in /etc/fstab, make sure you have a line like this:

    /dev/mapper/crypt_dev-nvme0n1p2 /               ext4    errors=remount-ro 0       1
    

    If you were already using a UUID entry for this, there's nothing to change!
13. Configure the root filesystem in the initrd:

    echo root=/dev/mapper/crypt_dev_nvme0n1p2 > /etc/kernel/cmdline
    

14. Regenerate UKI:

    dpkg-reconfigure linux-image-$(uname -r)
    

    Be careful here! systemd-boot inherits the command line from the system where it is generated, so this will possibly feature some unsupported commands from your boot environment. In my case GRML had a couple of those, which broke the boot. It's still possible to workaround this issue by tweaking the arguments at boot time, that said.
15. Exit chroot and reboot

    exit
    reboot
    

Some of the ideas in this section were taken from this guide but was mostly rewritten to simplify the work. My guide also avoids the grub hacks or a specific initrd system (as the guide uses initramfs-tools and grub, while I, above, switched to dracut and systemd-boot). RHEL also has a similar guide, perhaps even better. Somehow I have made this system without LVM at all, which simplifies things a bit (as I don't need to also resize the physical volume/volume groups), but if you have LVM, you need to tweak this to also resize the LVM bits. The RHEL guide has some information about this.

Matthew blogged about his Amiga CDTV project, a truly unique Amiga hack which also manages to be a novel Doom project (no mean feat: it's a crowded space) This re-awakened my dormant wish to muck around with my childhood Amiga some more. When I last wrote about it (four years ago ) I'd upgraded the disk drive emulator with an OLED display and rotary encoder. I'd forgotten to mention I'd also sourced a modern trapdoor RAM expansion which adds 2MiB of RAM. The Amiga can only see 1.5MiB¹ of it at the moment, I need perform a mainboard modification to access the final 512kiB², which means some soldering. What I had planned to do back then: replace the switch in the left button of the original mouse, which was misbehaving; perform the aformentioned mainboard mod; upgrade the floppy emulator wiring to a ribbon cable with plug-and-socket, for easier removal; fit an RTC chip to the RAM expansion board to get clock support in the OS. However much of that might be might be moot, because of two other mods I am considering, PiStorm I've re-considered the PiStorm accelerator mentioned in Matt's blog. Four years ago, I'd passed over it, because it required you to run Linux on a Raspberry Pi, and then an m68k emulator as a user-space process under Linux. I didn't want to administer another Linux system, and I'm generally uncomfortable about using a regular Linux distribution on SD storage over the long term. However in the intervening years Emu68, a bare-metal m68k emulator has risen to prominence. You boot the Pi straight into Emu68 without Linux in the middle. For some reason that's a lot more compelling to me. The PiStorm enormously expands the RAM visible to the Amiga. There would be no point in doing the mainboard mod to add 512k (and I don't know how that would interact with the PiStorm). It also can provide virtual hard disk devices to the Amiga (backed by files on the SD card), meaning the floppy emulator would be superfluous. Denise Mainboard I've just learned about a truly incredible project: the Denise Mini-ITX Amiga mainboard. It fitss into a Mini-ITX case (I have a suitable one spare already). Some assembly required. You move the chips from the original Amiga over to the Denise mainboard. It's compatible with the PiStorm (or vice-versa). It supports PC-style PS/2 keyboards (I have a Model M in the loft, thanks again Simon) and has a bunch of other modern conveniences: onboard RTC; mini-ITX power (I'll need something like a picoPSU too) It wouldn't support my trapdoor RAM card but it takes a 72-pin DIMM which can supply 2MiB of Chip RAM, and the PiStorm can do the rest (they're compatible³). No stock at the moment but if I could get my hands on this, I could build something that could permanently live on my desk.

Welcome to the seventh report from the Reproducible Builds project in 2025. Our monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. If you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website. In this report:

1. Reproducible Builds Summit 2025
2. Reproducible Builds an official goal for SUSE Enterprise Linux
3. Reproducible Builds at FOSSY 2025
4. New OSS Rebuild project from Google
5. New extension of Python setuptools to support reproducible builds
6. diffoscope
7. New library to patch system functions for reproducibility
8. Independently Reproducible Git Bundles
9. Website updates
10. Distribution work
11. Reproducibility testing framework
12. Upstream patches

---

Reproducible Builds Summit 2025 We are extremely pleased to announce the upcoming Reproducible Builds Summit, set to take place from October 28th 30th 2025 in Vienna, Austria! We are thrilled to host the eighth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin, Hamburg and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving. If you re interesting in joining us this year, please make sure to read the event page which has more details about the event and location. Registration is open until 20th September 2025, and we are very much looking forward to seeing many readers of these reports there!

Reproducible Builds an official goal for SUSE Enterprise Linux On our mailing list this month, Bernhard M. Wiedemann revealed the big news that reproducibility is now an official goal for SUSE Linux Enterprise Server (SLES) 16:

[Everything] changed earlier this year when reproducible-builds for SLES-16 became an official goal for the product. More people are talking about digital sovereignty and supply-chain security now. [ ] Today, only 9 of 3319 (source) packages have significant problems left (plus 7 with pending fixes), so 99.5% of packages have reproducible builds.

Reproducible Builds at FOSSY 2025 On Saturday 2nd August, Vagrant Cascadian and Chris Lamb presented at this year s FOSSY 2025. Their talk, titled Never Mind the Checkboxes, Here s Reproducible Builds!, was introduced as follows:

There are numerous policy compliance and regulatory processes being developed that target software development but do they solve actual problems? Does it improve the quality of software? Do Software Bill of Materials (SBOMs) actually give you the information necessary to verify how a given software artifact was built? What is the goal of all these compliance checklists anyways or more importantly, what should the goals be? If a software object is signed, who should be trusted to sign it, and can they be trusted forever?

Hosted by the Software Freedom Conservancy and taking place in Portland, Oregon, USA, FOSSY aims to be a community-focused event: Whether you are a long time contributing member of a free software project, a recent graduate of a coding bootcamp or university, or just have an interest in the possibilities that free and open source software bring, FOSSY will have something for you . More information on the event is available on the FOSSY 2025 website, including the full programme schedule. Vagrant and Chris also staffed a table, where they will be available to answer any questions about Reproducible Builds and discuss collaborations with other projects.

New OSS Rebuild project from Google The Google Open Source Security Team (GOSST) published an article this month announcing OSS Rebuild, a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts. As the post itself documents, the new project comprises four facets:

• Automation to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages.
• SLSA Provenance for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention.
• Build observability and verification tools that security teams can integrate into their existing vulnerability management workflows.
• Infrastructure definitions to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance.

One difference with most projects that aim for bit-for-bit reproducibility, OSS Rebuild aims for a kind of semantic reproducibility:

Through automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression).

The extensive post includes examples about how to access OSS Rebuild attestations using the Go-based command-line interface.

New extension of Python setuptools to support reproducible builds Wim Jeantine-Glenn has written a PEP 517 Build backend in order to enable reproducible builds when building Python projects that use setuptools. Called setuptools-reproducible, the project s README file contains the following:

Setuptools can create reproducible wheel archives (.whl) by setting SOURCE_DATE_EPOCH at build time, but setting the env var is insufficient for creating reproducible sdists (.tar.gz). setuptools-reproducible [therefore] wraps the hooks build_sdist build_wheel with some modifications to make reproducible builds by default.

diffoscope diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 301, 302 and 303 to Debian:

• Improvements:
  • Use Difference.from_operation in an attempt to pipeline the output of the extract-vmlinux script, potentially avoiding it all in memory. [ ]
  • Memoize a number of calls to --version, saving a very large number of external subprocess calls.
• Bug fixes:
  • Don t check for PyPDF version 3 specifically, check for versions greater than 3. [ ]
  • Ensure that Java class files are named .class on the filesystem before passing them to javap(1). [ ]
  • Mask stderr from extract-vmlinux script. [ ][ ]
  • Avoid spurious differences in h5dump output caused by exposure of absolute internal extraction paths. (#1108690)
• Misc:
  • Use our_check_output in the ODT comparator. [ ]
  • Update copyright years. [ ]

In addition:

• Siva Mahadevan made a change to use the --print-armap long option when calling nm(1) for wider compatibility. [ ]
• Vagrant Diffoscope updated diffoscope in GNU Guix to 300 [ ], 301 [ ], 302 and fixed the execute bit on the extract-vmlinux script [ ].

Lastly, Chris Lamb added a tmpfs to try.diffoscope.org so that diffoscope has a non-trivial temporary area to unpack archives, etc. [ ] Elsewhere in our tooling, however, reprotest is our tool for building the same source code twice in different environments and then checking the binaries produced by each build for any differences. This month, reprotest version 0.7.30 was uploaded to Debian unstable by Holger Levsen, chiefly including a change by Rebecca N. Palmer to not call sudo with the -h flag in order to fix Debian bug #1108550. [ ]

New library to patch system functions for reproducibility Nicolas Graves has written and published libfate, a simple collection of tiny libraries to patch system functions deterministically using LD_PRELOAD. According to the project s README:

libfate provides deterministic replacements for common non-deterministic system functions that can break reproducible builds. Instead of relying on complex build systems or apps or extensive patching, libfate uses the LD_PRELOAD trick to intercept system calls and return fixed, predictable values.

Describing why he wrote it, Nicolas writes:

I originally used the OpenSUSE dettrace approach to make Emacs reproducible in Guix. But when Guix switch to GCC@14, dettrace stopped working as expected. dettrace is a complex piece of software, my need was much less heavy: I don t need to systematically patch all sources of nondetermism, just the ones that make a process/binary unreproducible in a container/chroot.

Independently Reproducible Git Bundles Simon Josefsson has published another interesting article this month. Titled Independently Reproducible Git Bundles, the blog post describes the advantages of why you might a reproducible bundle, and the pitfalls that can arise when trying to create them:

One desirable property is that someone else should be able to reproduce the same git bundle, and not only that a single individual is able to reproduce things on one machine. It surprised me to see that when I ran the same set of commands on a different machine (started from a fresh git clone), I got a different checksum. The different checksums occurred even when nothing had been committed on the server side between the two runs.

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

• Bernhard M. Wiedemann added an entry related to R-B-OS on the History page. [ ]
• Chris Lamb:
  • Replaced rbtlog run by Fay by rbtlog run by Benl on the Who is involved page. [ ]
  • Added a new, centered version of the RB logo. [ ]
• Holger Levsen:
  • Added and worked on the page for the Vienna 2025 summit. [ ][ ]
  • Add Jarl Gullberg to the Who is involved? page. [ ]
  • Add a talk from the recent MiniDebConf in Hamburg to our database of talks and presentations. [ ]
• Julien Cristau fixed a link to the diffoci repository on the [Tools](/tools/ page. [ ]

Distribution work In Debian this month:

• 5 reviews of Debian packages were added, 4 were updated and 2 were removed this month adding to our ever-increasing knowledge about identified issues.
• The release notes for the upcoming Debian Trixie release feature the following paragraph related to Reproducible Builds, thanks to the collaboration of Justin B Rye, Chris Hofstaedtler, Vagrant Cascadian and Holger Levsen:

Debian contributors have made significant progress toward ensuring package builds produce byte-for-byte reproducible results. You can check the status for packages installed on your system using the new package debian-repro-status, or visit reproduce.debian.net for Debian s overall statistics for trixie and later. You can contribute to these efforts by joining #debian-reproducible on IRC to discuss fixes, or verify the statistics by installing the new rebuilderd package and setting up your own instance.

The IzzyOnDroid Android APK repository made further progress in July, crossing the 50% reproducibility threshold congratulations. Furthermore, a new release of the Neo Store was released, which exposes the reproducible status directly next to the version of each app.
In GNU Guix, a series of patches intended to fix the reproducibility for the Mono programming language was merged, fixing reproducibility in Mono versions 1.9 [ ], 2.4 [ ] and 2.6 [ ].
Lastly, in addition to the news that openSUSE Enterprise Linux now [has an official goal of reproducibility]((https://lists.reproducible-builds.org/pipermail/rb-general/2025-July/003846.html), Bernhard M. Wiedemann posted another monthly update for their work there.

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In July, however, a number of changes were made by Holger Levsen, including:

• Switch the URL for the Tails package set. [ ]
• Make the dsa-check-packages output more useful. [ ]
• Setup the ppc64el architecture again, has it has returned this time with a 2.7 GiB database instead of 72 GiB. [ ]

In addition, Jochen Sprickerhof improved the reproducibility statistics generation:

• Enable caching of statistics. [ ][ ][ ]
• Add some common non-reproducible patterns. [ ]
• Change output to directory. [ ]
• Add a page sorted by diffoscope size. [ ][ ]
• Switch to Python s argparse module and separate output(). [ ]

Holger also submitted a number of Debian bugs against rebuilderd and rebuilderd-worker:

• Config files and scripts for a simple one machine setup. [ ][ ]
• Create a rebuilderd user. [ ]
• Create rebuilderd-worker user with sbuild. [ ]

Lastly, Mattia Rizzolo added a scheduled job to renew some SSL certificates [ ] and Vagrant Cascadian performed some node maintenance [ ][ ].

Upstream 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 appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • dpdk
  • HTTP-CookieJar
  • ibus-libzhuyin
  • java-21-openjdk
  • kea
  • libcamera
  • libpinyin
  • libsemigroups
  • llvm, llvm20 , llvm20, llvm19, llvm15, llvm17 (and all backports to llvm7-19)
  • mumble
  • python-Babel/pympress
  • python-numpy
  • python-numpy
  • python-paho-mqtt
  • python-rencode
  • rabbitmq-server
  • rage
  • re-flex
  • shadow-rs
• Chris Lamb:
  • #1109484 filed against rust-microformats
  • #1109731 filed against piglit
• Rafa Mikrut:
  • cargo-i18n
• Robin Candau:
  • netdata

There were a number of other patches from openSUSE developers:

• BCI-dockerfile-generator (Dirk Mueller)
• agama (Imobach Gonzalez Sosa)
• emacs (Werner Fink)
• firecracker (Andrea Manzini)
• maven-archiver (Fridrich Strba)
• moditect (Fridrich Strba)
• obs-build (Adrian Schroeter)
• ovmf (Richard Lyu)
• python-rdflib (Daniel Garcia)
• python313:doc (Daniel Garcia)

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:

• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org

In July I attended DebCamp and DebConf in Brest, France. I very much enjoyed the opportunity to reconnect with other Debian contributors in person. I had a number of interesting and fruitful conversations there, besides the formally organised BoFs and talks. I also gave my own talk on What s new in the Linux kernel (and what s missing in Debian). Here s the usual categorisation of activity:

• Debian packages:
  • firmware-nonfree:
    • Bugs:
      • replied to #1093084: firmware-amd-graphics: Some graphical glitches and occasional stuttering with AMD graphics
      • closed #1100723: firmware-misc-nonfree: ralink firmware disapears after upgrade due backport firmware-misc-free split in multiple packages
      • replied to and closed #1108250: firmware-intel-graphics: i915 timeout errors after firmware upgrade
      • replied to and reassigned #1108599: firmware-linux-free: please add support MT7921/MT7925 WIFI Combo Cards
      • replied to #1109015: Wifi not working anymore with new atheros firmware from experimental
    • Uploads:
      • uploaded version 20250627-1 to experimental
      • uploaded version 20250708-1 to experimental
  • initramfs-tools:
    • Bugs:
      • replied to #1099456: initramfs-tools: misleading error messages
    • Merge requests:
      • reviewed !172: Use 3cpio for unmkinitramfs/lsinitramfs if available
      • reviewed and merged !179: update-initramfs: add copyright information
      • opened and merged !180: hook-functions: Add Cadence USB driver to base
      • reviewed !182: unmkinitramfs: handle both uppercase and lowercase hex numbers
  • ktls-utils:
    • Uploads:
      • uploaded version 1.2.1-1 to experimental
  • kup:
    • Bugs:
      • closed #1064112: kup-client: Recommends transitional package gnupg-agent instead of gpg-agent
    • Uploads:
      • uploaded version 0.3.6-5 to experimental
  • lintian:
    • Bugs:
      • replied to #1051140: lintian in bookworm does not know about any bookworm* suites
  • linux:
    • Bugs:
      • closed #763547: firmware-linux: please include ihex2fw tool into one of linux-* packages
      • closed #1016718: binfmt_elf: May fail to load executable with no static data next to BSS
      • replied to #1035878: rpi400: visual speckling on faulty HDMI port during mouse movement
      • closed #1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
      • replied to #1086638: linux-image-6.11.5: usbguard-daemon invalid opcode: 0000, usb s not usable
      • closed #1092931: Most recent kernel is causing issues with touchpad function.
      • replied to #1102175: Repeated lockups in AMDGPU DRM driver
      • replied to #1102522: linux-image-6.12.21-amd64: Fails to suspend Acer TravelMate Spin B311R-31
      • replied to #1104165: linux-image-6.12.22-amd64: Freezing with amdgpu_dm_plane_helper_prepare_fb bind failed some time after returning from suspend
      • replied to #1104670: linux-image-6.12.25-amd64: system does not shut down - GHES: Fatal hardware error
      • replied to #1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
      • replied to #1107785: CLOCK_MONOTONIC increases in s2idle, triggering watchdogs, killing processes
      • replied to #1108037: linux-perf: perf report demangle only works on some(?) symbols
      • replied to #1108168: linux-image-6.12.32-amd64: black screen, then crash in nouveau when rebooting
      • replied to #1108294: kernel 6.12 breaks cgroup awareness of openjdk 21
      • closed #1108430: Kernel Regression between 6.1.0-35 and 6.1.0-37: IPv6 link-local multicast over GRE tunnel is silently dropped
      • replied to #1108496: linux-image-6.12.30+bpo-amd64: USB audio glitches: retire_capture_urb
      • replied to #1108965: linux: Enable RTL8851BE module
      • replied to #1109038: breaks with rtl8139 network interface via usb
      • replied to and closed #1109040: Subject: linux-headers-6.1.0-37-amd64 missing config files; cannot build external modules on Bookworm
      • replied to #1109666: Fails to boot on Marvell Armada 385
      • replied to #1109776: Support for non-4kB pages in Xe driver
      • replied to #1109891: hyperv-daemons no longer available for bullseye/arm64
    • Merge requests:
      • merged !1502: Add linux-misc-tools package for bootconfig, ihex2fw, thermometer, and tmon
      • reviewed !1542: 6.1 stable updates
      • reviewed !1543: Draft: [arm64] Provide an installer package for usbgadget usage
      • reviewed !1560: [arm64] Enable Qualcomm RB1 boards
      • reviewed and merged !1565: [cloud] Enable SATA_AHCI
      • opened and merged !1569: Update to 6.16-rc5
      • opened !1570: rtw89: Enable RTW89_8851BE, RTW89_8852BTE as modules
      • opened !1571: rtw88: Enable RTW88_8821AU, RTW88_8812AU, RTW88_8814AE, RTW88_8814AU as modules
      • opened !1572: Revert cgroup: Do not report unavailable v1 controllers in /proc/cgroups
      • opened !1573: hyperv-daemons: Fix and install the sample network info scripts
      • opened !1576: Clean up tools build
      • merged !1580: Update to 6.16-rc6
      • merged !1586: Update to 6.16-rc7
      • opened !1587: binder: Add module description, fixing warning from modpost
      • opened !1588: linux-misc-tools: Fix FTBFS on sparc64
      • reviewed !1591: Move all package specific build-deps
    • Uploads:
      • uploaded version 6.12.33-1~bpo12+1 to bookworm-backports
      • uploaded version 6.12.35-1~bpo12+1 to bookworm-backports
      • uploaded version 6.12.38-1~bpo12+1 to bookworm-backports
      • uploaded version 6.16~rc7-1~exp1 to experimental
    • (LTS) Updated the bullseye-security branch, but did not upload it:
      • updated to upstream version 5.10.240
      • enabled building hyperv-daemons for arm64
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded version 6.1.140-1~deb11u1 to bullseye-security
  • linux-base:
    • Bugs:
      • closed #1010699: linux: Please touch /run/reboot-required in postinst
      • closed #1041189: general: Optimize kernel settings for gaming
    • Uploads:
      • uploaded version 4.13 to experimental
  • nfs-utils:
    • Bugs:
      • closed #1109999: [nfs-common] default option ($ STATDOPTS ) is not used
  • sbuild:
    • Bugs:
      • opened #1109103: Cross-build with profiles does not set DEB_BUILD_OPTIONS=nocheck
  • wireless-regdb:
    • Uploads:
      • uploaded version 2025.07.10-1 to unstable
    • (LTS) Prepared backports of the above version to bookworm and bullseye-security
• Debian non-package bugs:
  • release.debian.org:
    • opened #1109500: unblock: wireless-regdb/2025.07.10-1
  • wnpp:
    • replied to and closed #1072579: ITP: cis-tools CIS file tools from pcmcia-cs
    • replied to #1109020: ITP: sphinxcontrib-youtube Sphinx extension that allows you to embed YouTube and Vimeo
• Mailing lists:
  • cgroups:
    • replied to [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups
  • debian-boot:
    • replied to Installer freeze on Gigabyte X870E Aorus Master, ath12k wifi related
  • debian-devel:
    • replied to Building multiple flavors of a package with a HUGE upstream
  • debian-kernel:
    • posted Agenda items for kernel-team meeting on 2025-07-16
    • posted Agenda items for kernel-team meeting on 2025-07-30
    • posted Installation location of BPF vmlinux.h
    • replied to Request to backport CONFIG_UCLAMP_TASK to 6.12 stable
  • linux-block:
    • replied to Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
  • linux-firmware:
    • replied to Bug#1109015: Wifi not working anymore with new atheros firmware from experimental
  • linux-pci:
    • replied to Bug#1104670: linux-image-6.12.25-amd64: system does not shut down - GHES: Fatal hardware error
    • posted Failure to resume ASMedia ASM4242 on AMD systems
  • linux-pm:
    • posted User-space watchdog timers vs suspend-to-idle
  • linux-rt-users:
    • posted PREEMPT_RT vs i915
  • linux-sh:
    • posted [PATCH v2] sh: Do not use hyphen in exported variable name
  • linux-trace-kernel:
    • posted and replied to [PATCH] bootconfig: Fix unaligned access when building footer
  • stable:
    • replied to [PATCH 2/5] x86/bugs: Add a Transient Scheduler Attacks mitigation

Review: Cyteen, by C.J. Cherryh

Series:	Cyteen #1
Publisher:	Warner Aspect
Copyright:	1988
Printing:	September 1995
ISBN:	0-446-67127-4
Format:	Trade paperback
Pages:	680

The main text below is an edited version of my original review of Cyteen written on 2012-01-03. Additional comments from my re-read are after the original review. I've reviewed several other C.J. Cherryh books somewhat negatively, which might give the impression I'm not a fan. That is an artifact of when I started reviewing. I first discovered Cherryh with Cyteen some 20 years ago, and it remains one of my favorite SF novels of all time. After finishing my reading for 2011, I was casting about for what to start next, saw Cyteen on my parents' shelves, and decided it was past time for my third reading, particularly given the recent release of a sequel, Regenesis. Cyteen is set in Cherryh's Alliance-Union universe following the Company Wars. It references several other books in that universe, most notably Forty Thousand in Gehenna but also Downbelow Station and others. It also has mentions of the Compact Space series (The Pride of Chanur and sequels). More generally, almost all of Cherryh's writing is loosely tied together by an overarching future history. One does not need to read any of those other books before reading Cyteen; this book will fill you in on all of the politics and history you need to know. I read Cyteen first and have never felt the lack. Cyteen was at one time split into three books for publishing reasons: The Betrayal, The Rebirth, and The Vindication. This is an awful way to think of the book. There are no internal pauses or reasonable volume breaks; Cyteen is a single coherent novel, and Cherryh has requested that it never be broken up that way again. If you happen to find all three portions as your reading copy, they contain all the same words and are serviceable if you remember it's a single novel under three covers, but I recommend against reading the portions in isolation. Human colonization of the galaxy started with slower-than-light travel sponsored by the private Sol Corporation. The inhabitants of the far-flung stations and the crews of the merchant ships that supplied them have formed their own separate cultures, but initially remained attached to Earth. That changed with the discovery of FTL travel and a botched attempt by Earth to reassert its authority. At the time of Cyteen, there are three human powers: distant Earth (which plays little role in this book), the merchanter Alliance, and Union. The planet Cyteen is one of only a few Earth-like worlds discovered by human expansion, and is the seat of government and the most powerful force in Union. This is primarily because of Reseune: the Cyteen lab that produces the azi. If Cyteen is about any one thing, it's about azi: genetically engineered human clones who are programmed via intensive psychological conditioning starting before birth. The conditioning uses a combination of drugs to make them receptive and "tape," specific patterns of instruction and sensory stimulation. They are designed for specific jobs or roles, they're conditioned to be obedient to regular humans, and they're not citizens. They are, in short, slaves. In a lot of books, that's as deep as the analysis would go. Azi are slaves, and slavery is certainly bad, so there would probably be a plot around azi overthrowing their conditioning, or around the protagonists trying to free them from servitude. But Cyteen is not any SF novel, and azi are considerably more complex and difficult than that analysis. We learn over the course of the book that the immensely powerful head of Reseune Labs, Ariane Emory, has a specific broader purpose in mind for the azi. One of the reasons why Reseune fought for and gained the role of legal protector of all azi in Union, regardless of where they were birthed, is so that Reseune could act to break any permanent dependence on azi as labor. And yet, they are slaves; one of the protagonists of Cyteen is an experimental azi, which makes him the permanent property of Reseune and puts him in constant jeopardy of being used as a political prisoner and lever of manipulation against those who care about him. Cyteen is a book about manipulation, about programming people, about what it means to have power over someone else's thoughts, and what one can do with that power. But it's also a book about connection and identity, about what makes up a personality, about what constitutes identity and how people construct the moral codes and values that they hold at their core. It's also a book about certainty. Azi are absolutely certain, and are capable of absolute trust, because that's part of their conditioning. Naturally-raised humans are not. This means humans can do things that azi can't, but the reverse is also true. The azi are not mindless slaves, nor are they mindlessly programmed, and several of the characters, both human and azi, find a lot of appeal in the core of certainty and deep self-knowledge of their own psychological rules that azis can have. Cyteen is a book about emotions, and logic, and where they come from and how to balance them. About whether emotional pain and uncertainty is beneficial or damaging, and about how one's experiences make up and alter one's identity. This is also a book about politics, both institutional and personal. It opens with Ariane Emory, Councilor for Science for five decades and the head of the ruling Union Expansionist party. She's powerful, brilliant, dangerously good at reading people, and dangerously willing to manipulate and control people for her own ends. What she wants, at the start of the book, is to completely clone a Special (the legal status given to the most brilliant minds of Union). This was attempted before and failed, but Ariane believes it's now possible, with a combination of tape, genetic engineering, and environmental control, to reproduce the brilliance of the original mind. To give Union another lifespan of work by their most brilliant thinkers. Jordan Warrick, another scientist at Reseune, has had a long-standing professional and personal feud with Ariane Emory. As the book opens, he is fighting to be transferred out from under her to the new research station that would be part of the Special cloning project, and he wants to bring his son Justin and Justin's companion azi Grant with them. Justin is a PR, a parental replicate, meaning he shares Jordan's genetic makeup but was not an attempt to reproduce the conditions of Jordan's rearing. Grant was raised as his brother. And both have, for reasons that are initially unclear, attracted the attention of Ariane, who may be using them as pawns. This is just the initial setup, and along with this should come a warning: the first 150 pages set up a very complex and dangerous political situation and build the tension that will carry the rest of the book, and they do this by, largely, torturing Justin and Grant. The viewpoint jumps around, but Justin and Grant are the primary protagonists for this first section of the book. While one feels sympathy for both of them, I have never, in my multiple readings of the book, particularly liked them. They're hard to like, as opposed to pity, during this setup; they have very little agency, are in way over their heads, are constantly making mistakes, and are essentially having their lives destroyed. Don't let this turn you off on the rest of the book. Cyteen takes a dramatic shift about 150 pages in. A new set of protagonists are introduced who are some of the most interesting, complex, and delightful protagonists in any SF novel I have read, and who are very much worth waiting for. While Justin has his moments later on (his life is so hard that his courage can be profoundly moving), it's not necessary to like him to love this book. That's one of the reasons why I so strongly dislike breaking it into three sections; that first section, which is mostly Justin and Grant, is not representative of the book. I can't talk too much more about the plot without risking spoiling it, but it's a beautiful, taut, and complex story that is full of my favorite things in both settings and protagonists. Cyteen is a book about brilliant people who think on their feet. Cherryh succeeds at showing this through what they do, which is rarely done as well as it is here. It's a book about remembering one's friends and remembering one's enemies, and waiting for the most effective moment to act, but it also achieves some remarkable transformations. About 150 pages in, you are likely to loathe almost everyone in Reseune; by the end of the book, you find yourself liking, or at least understanding, nearly everyone. This is extremely hard, and Cherryh pulls it off in most cases without even giving the people she's redeeming their own viewpoint sections. Other than perhaps George R.R. Martin I've not seen another author do this as well. And, more than anything else, Cyteen is a book with the most wonderful feeling of catharsis. I think this is one of the reasons why I adore this book and have difficulties with some of Cherryh's other works. She's always good at ramping up the tension and putting her characters in awful, untenable positions. Less frequently does she provide the emotional payoff of turning the tables, where you get to watch a protagonist do everything you've been wanting them to do for hundreds of pages, except even better and more delightfully than you would have come up with. Cyteen is one of the most emotionally satisfying books I've ever read. I could go on and on; there is just so much here that I love. Deep questions of ethics and self-control, presented in a way that one can see the consequences of both bad decisions and good ones and contrast them. Some of the best political negotiations in fiction. A wonderful look at friendship and loyalty from several directions. Two of the best semi-human protagonists I've seen, who one can see simultaneously as both wonderful friends and utterly non-human and who put nearly all of the androids in fiction to shame by being something trickier and more complex. A wonderful unfolding sense of power. A computer that can somewhat anticipate problems and somewhat can't, and that encapsulates much of what I love about semi-intelligent bases in science fiction. Cyteen has that rarest of properties of SF novels: Both the characters and the technology meld in a wonderful combination where neither could exist without the other, where the character issues are illuminated by the technology and the technology supports the characters. I have, for this book, two warnings. The first, as previously mentioned, is that the first 150 pages of setup is necessary but painful to read, and I never fully warmed to Justin and Grant throughout. I would not be surprised to hear that someone started this book but gave up on it after 50 or 100 pages. I do think it's worth sticking out the rocky beginning, though. Justin and Grant continue to be a little annoying, but there's so much other good stuff going on that it doesn't matter. The other warning is that part of the setup of the story involves the rape of an underage character. This is mostly off-camera, but the emotional consequences are significant (as they should be) and are frequently discussed throughout the book. There is also rather frank discussion of adolescent sexuality later in the book. I think both of these are relevant to the story and handled in a way that isn't gratuitous, but they made me uncomfortable and I don't have any past history with those topics. Those warnings notwithstanding, this is simply one of the best SF novels ever written. It uses technology to pose deep questions about human emotions, identity, and interactions, and it uses complex and interesting characters to take a close look at the impact of technology on lives. And it does this with a wonderfully taut, complicated plot that sustains its tension through all 680 pages, and with characters whom I absolutely love. I have no doubt that I'll be reading it for a fourth and fifth time some years down the road. Followed by Regenesis, although Cyteen stands well entirely on its own and there's no pressing need to read the sequel. Rating: 10 out of 10

---

Some additional thoughts after re-reading Cyteen in 2025: I touched on this briefly in my original review, but I was really struck during this re-read how much the azi are a commentary on and a complication of the role of androids in earlier science fiction. Asimov's Three Laws of Robotics were an attempt to control the risks of robots, but can also be read as turning robots into slaves. Azis make the slavery more explicit and disturbing by running the programming on a human biological platform, but they're more explicitly programmed and artificial than a lot of science fiction androids. Artificial beings and their relationship to humans have been a recurring theme of SF since Frankenstein, but I can't remember a novel that makes the comparison to humans this ambiguous and conflicted. The azi not only like being azi, they can describe why they prefer it. It's clear that Union made azi for many of the same reasons that humans enslave other humans, and that Ariane Emory is using them as machinery in a larger (and highly ethically questionable) plan, but Cherryh gets deeper into the emergent social complications and societal impact than most SF novels manage. Azi are apparently closer to humans than the famous SF examples such as Commander Data, but the deep differences are both more subtle and more profound. I've seen some reviewers who are disturbed by the lack of a clear moral stance by the protagonists against the creation of azi. I'm not sure what to think about that. It's clear the characters mostly like the society they've created, and the groups attempting to "free" azi from their "captivity" are portrayed as idiots who have no understanding of azi psychology. Emory says she doesn't want azi to be a permanent aspect of society but clearly has no intention of ending production any time soon. The book does seem oddly unaware that the production of azi is unethical per se and, unlike androids, has an obvious exit ramp: Continue cloning gene lines as needed to maintain a sufficient population for a growing industrial civilization, but raise the children as children rather than using azi programming. If Cherryh included some reason why that was infeasible, I didn't see it, and I don't think the characters directly confronted it. I don't think societies in books need to be ethical, or that Cherryh intended to defend this one. There are a lot of nasty moral traps that civilizations can fall into that make for interesting stories. But the lack of acknowledgment of the problem within the novel did seem odd this time around. The other part of this novel that was harder to read past in this re-read is the sexual ethics. There's a lot of adolescent sexuality in this book, and even apart from the rape scene which was more on-the-page than I had remembered and which is quite (intentionally) disturbing there is a whole lot of somewhat dubious consent. Maybe I've gotten older or just more discriminating, but it felt weirdly voyeuristic to know this much about the sex lives of characters who are, at several critical points in the story, just a bunch of kids. All that being said, and with the repeated warning that the first 150 pages of this novel are just not very good, there is still something magic about the last two-thirds of this book. It has competence porn featuring a precociously brilliant teenager who I really like, it has one of the more interesting non-AI programmed computer systems that I've read in SF, it has satisfying politics that feel like modern politics (media strategy and relationships and negotiated alliances, rather than brute force and ideology), and it has a truly excellent feeling of catharsis. The plot resolution is a bit too abrupt and a bit insufficiently explained (there's more in Regenesis), but even though this was my fourth time through this book, the pacing grabbed me again and I could barely put down the last part of the story. Ethics aside (and I realize that's quite the way to start a sentence), I find the azi stuff fascinating. I know the psychology in this book is not real and is hopelessly simplified compared to real psychology, but there's something in the discussions of value sets and flux and self-knowledge that grabs my interest and makes me want to ponder. I think it's the illusion of simplicity and control, the what-if premise of thought where core motivations and moral rules could be knowable instead of endlessly fluid the way they are in us humans. Cherryh's azi are some of the most intriguing androids in science fiction to me precisely because they don't start with computers and add the humanity in, but instead start with humanity and overlay a computer-like certainty of purpose that's fully self-aware. The result is more subtle and interesting than anything Star Trek managed. I was not quite as enamored with this book this time around, but it's still excellent once the story gets properly started. I still would recommend it, but I might add more warnings about the disturbing parts.

Re-read rating: 9 out of 10

tl;dr: there is an attack in the wild which is triggering dangerous-but-seemingly-intended behaviour in the Oj JSON parser when used in the default and recommended manner, which can lead to everyone s favourite kind of security problem: object deserialization bugs! If you have the oj gem anywhere in your Gemfile.lock, the quickest mitigation is to make sure you have Oj.default_options = mode: :strict somewhere, and that no library is overwriting that setting to something else.

Prologue As a sensible sysadmin, all the sites I run send me a notification if any unhandled exception gets raised. Mostly, what I get sent is error-handling corner cases I missed, but now and then things get more interesting. In this case, it was a PG::UndefinedColumn exception, which looked something like this:

PG::UndefinedColumn: ERROR:  column "xyzzydeadbeef" does not exist

This is weird on two fronts: firstly, this application has been running for a while, and if there was a schema problem, I d expect it to have made itself apparent long before now. And secondly, while I don t profess to perfection in my programming, I m usually better at naming my database columns than that. Something is definitely hinky here, so let s jump into the mystery mobile!

The column name is coming from outside the building! The exception notifications I get sent include a whole lot of information about the request that caused the exception, including the request body. In this case, the request body was JSON, and looked like this:

 "name":":xyzzydeadbeef", ... 

The leading colon looks an awful lot like the syntax for a Ruby symbol, but it s in a JSON string. Surely there s no way a JSON parser would be turning that into a symbol, right? Right?!? Immediately, I thought that that possibly was what was happening, because I use Sequel for my SQL database access needs, and Sequel treats symbols as database column names. It seemed like too much of a coincidence that a vaguely symbol-shaped string was being sent in, and the exact same name was showing up as a column name. But how the flying fudgepickles was a JSON string being turned into a Ruby symbol, anyway? Enter Oj.

Oj? I barely know aj A long, long time ago, the standard Ruby JSON library had a reputation for being slow. Thus did many competitors flourish, claiming more features and better performance. Strong amongst the contenders was oj (for Optimized JSON ), touted as The fastest JSON parser and object serializer . Given the history, it s not surprising that people who wanted the best possible performance turned to Oj, leading to it being found in a great many projects, often as a sub-dependency of a dependency of a dependency (which is how it ended up in my project). You might have noticed in Oj s description that, in addition to claiming fastest , it also describes itself as an object serializer . Anyone who has kept an eye on the security bug landscape will recall that object deserialization is a rich vein of vulnerabilities to mine. Libraries that do object deserialization, especially ones with a history that goes back to before the vulnerability class was well-understood, are likely to be trouble magnets. And thus, it turns out to be with Oj. By default, Oj will happily turn any string that starts with a colon into a symbol:

>> require "oj"
>> Oj.load(' "name":":xyzzydeadbeef","username":"bob","answer":42 ')
=>  "name"=>:xyzzydeadbeef, "username"=>"bob", "answer"=>42 

How that gets exploited is only limited by the creativity of an attacker. Which I ll talk about more shortly but first, a word from my rant cortex.

Insecure By Default is a Cancer While the object of my ire today is Oj and its fast-and-loose approach to deserialization, it is just one example of a pervasive problem in software: insecurity by default. Whether it s a database listening on 0.0.0.0 with no password as soon as its installed, or a library whose default behaviour is to permit arbitrary code execution, it all contributes to a software ecosystem that is an appalling security nightmare. When a user (in this case, a developer who wants to parse JSON) comes across a new piece of software, they have by definition no idea what they re doing with that software. They re going to use the defaults, and follow the most easily-available documentation, to achieve their goal. It is unrealistic to assume that a new user of a piece of software is going to do things the right way , unless that right way is the only way, or at least the by-far-the-easiest way. Conversely, the developer(s) of the software is/are the domain experts. They have knowledge of the problem domain, through their exploration while building the software, and unrivalled expertise in the codebase. Given this disparity in knowledge, it is tantamount to malpractice for the experts the developer(s) to off-load the responsibility for the safe and secure use of the software to the party that has the least knowledge of how to do that (the new user). To apply this general principle to the specific case, take the Using section of the Oj README. The example code there calls Oj.load, with no indication that this code will, in fact, parse specially-crafted JSON documents into Ruby objects. The brand-user user of the library, no doubt being under pressure to Get Things Done, is almost certainly going to look at this Using example, get the apparent result they were after (a parsed JSON document), and call it a day. It is unlikely that a brand-new user will, for instance, scroll down to the Further Reading section, find the second last (of ten) listed documents, Security.md , and carefully peruse it. If they do, they ll find an oblique suggestion that parsing untrusted input is never a good idea . While that s true, it s also rather unhelpful, because I d wager that by far the majority of JSON parsed in the world is untrusted , in one way or another, given the predominance of JSON as a format for serializing data passing over the Internet. This guidance is roughly akin to putting a label on a car s airbags that driving at speed can be hazardous to your health : true, but unhelpful under the circumstances. The solution is for default behaviours to be secure, and any deviation from that default that has the potential to degrade security must, at the very least, be clearly labelled as such. For example, the Oj.load function should be named Oj.unsafe_load, and the Oj.load function should behave as the Oj.safe_load function does presently. By naming the unsafe function as explicitly unsafe, developers (and reviewers) have at least a fighting chance of recognising they re doing something risky. We put warning labels on just about everything in the real world; the same should be true of dangerous function calls. OK, rant over. Back to the story.

But how is this exploitable? So far, I ve hopefully made it clear that Oj does some Weird Stuff with parsing certain JSON strings. It caused an unhandled exception in a web application I run, which isn t cool, but apart from bombing me with exception notifications, what s the harm? For starters, let s look at our original example: when presented with a symbol, Sequel will interpret that as a column name, rather than a string value. Thus, if our save an update to the user code looked like this:

# request_body has the JSON representation of the form being submitted
body = Oj.load(request_body)
DB[:users].where(id: user_id).update(name: body["name"])

In normal operation, this will issue an SQL query along the lines of UPDATE users SET name='Jaime' WHERE id=42. If the name given is Jaime O Dowd , all is still good, because Sequel quotes string values, etc etc. All s well so far. But, imagine there is a column in the users table that normally users cannot read, perhaps admin_notes. Or perhaps an attacker has gotten temporary access to an account, and wants to dump the user s password hash for offline cracking. So, they send an update claiming that their name is :admin_notes (or :password_hash). In JSON, that ll look like "name":":admin_notes" , and Oj.load will happily turn that into a Ruby object of "name"=>:admin_notes . When run through the above update the user code fragment, it ll produce the SQL UPDATE users SET name=admin_notes WHERE id=42. In other words, it ll copy the contents of the admin_notes column into the name column which the attacker can then read out just by refreshing their profile page.

But Wait, There s More! That an attacker can read other fields in the same table isn t great, but that s barely scratching the surface. Remember before I said that Oj does object serialization ? That means that, in general, you can create arbitrary Ruby objects from JSON. Since objects contain code, it s entirely possible to trigger arbitrary code execution by instantiating an appropriate Ruby object. I m not going to go into details about how to do this, because it s not really my area of expertise, and many others have covered it in detail. But rest assured, if an attacker can feed input of their choosing into a default call to Oj.load, they ve been handed remote code execution on a platter.

Mitigations As Oj s object deserialization is intended and documented behaviour, don t expect a future release to make any of this any safer. Instead, we need to mitigate the risks. Here are my recommended steps:

1. Look in your Gemfile.lock (or SBOM, if that s your thing) to see if the oj gem is anywhere in your codebase. Remember that even if you don t use it directly, it s popular enough that it is used in a lot of places. If you find it in your transitive dependency tree anywhere, there s a chance you re vulnerable, limited only by the ingenuity of attackers to feed crafted JSON into a deeply-hidden Oj.load call.
2. If you depend on oj directly and use it in your project, consider not doing that. The json gem is acceptably fast, and JSON.parse won t create arbitrary Ruby objects.
3. If you really, really need to squeeze the last erg of performance out of your JSON parsing, and decide to use oj to do so, find all calls to Oj.load in your code and switch them to call Oj.safe_load.
4. It is a really, really bad idea to ever use Oj to deserialize JSON into objects, as it lacks the safety features needed to mitigate the worst of the risks of doing so (for example, restricting which classes can be instantiated, as is provided by the permitted_classes argument to Psych.load). I d make it a priority to move away from using Oj for that, and switch to something somewhat safer (such as the aforementioned Psych). At the very least, audit and comment heavily to minimise the risk of user-provided input sneaking into those calls somehow, and pass mode: :object as the second argument to Oj.load, to make it explicit that you are opting-in to this far more dangerous behaviour only when it s absolutely necessary.
5. To secure any unsafe uses of Oj.load in your dependencies, consider setting the default Oj parsing mode to :strict, by putting Oj.default_options = mode: :strict somewhere in your initialization code (and make sure no dependencies are setting it to something else later!). There is a small chance that this change of default might break something, if a dependency is using Oj to deliberately create Ruby objects from JSON, but the overwhelming likelihood is that Oj s just being used to parse ordinary JSON, and these calls are just RCE vulnerabilities waiting to give you a bad time.

Is Your Bacon Saved? If I ve helped you identify and fix potential RCE vulnerabilities in your software, or even just opened your eyes to the risks of object deserialization, please help me out by buying me a refreshing beverage. I would really appreciate any support you can give. Alternately, if you d like my help in fixing these (and many other) sorts of problems, I m looking for work, so email me.

Posted on July 25, 2025
Tags: madeof:atoms, craft:sewing, FreeSoftWear

I might be slightly insane? Or am I going to prove something about the nature and accessibility of sewing and MYOG¹ as a hobby? I love my modular backpack, but it has a very modern look that is maybe not the best thing when otherwise dressed in historybounding dress, and it s also a bit bigger than I planned or needed it to be. So, when one of the shops I buy from had some waterproof cotton canvas on sale I failed my saving throw against temptations and bought a few meters, with the intent to make myself a backpack in a different style. It needs to be a backpack, because my back doesn t like asymmetrical bags², and as far as I know 19th century backpacks weren t the most comfortable things, so I decided to go for a vaguely timeless roll top model that has the added advantage not to require a lot of hardware for the closure, just a few D-rings. Leather straps would look cool, but also require some tools that I still don t have, so I decided to look for some cotton webbing, and when I finally found some in 25 mm and 50 mm width I could finally start on the project. Except for one thing: thread. As much as I believe that regular n 50 cotton thread got a bad reputation from sellers who decided to cut quality in favour of profit, it is not up to the task of sewing a backpack. Nor that I d use regular sew-all poly thread either. I do have some of the thread I used for my other backpack, which would have been strong enough, but it s also in black, which isn t exactly the look I was aiming for on the natural / ecru colour of both the canvas and the webbing. I also misremembered it as only being available in that colour (it isn t), so I wasn t tempted into doing a full online order of technical materials just for that. On the other hand, I did have in my stash some strong thread I could trust for this job, in natural / ecru. There was only one problem: it was 33 2 Tex linen, and not suitable for the sewing machine. You can t handsew a backpack. Or can you? Of course it s going to be much slower, but I m still in a situation where I have more time and space for handsewing than I have for machine sewing. And as for strength, my perception is that for the same stitch length an handsewn backstitch is stronger than a machine lockstitch, or at least it is more effort to unpick (and thus harder to accidentally unravel if the thread breaks). And so I tried. And it worked. Having to backstitch everything instead of being able to use a running backstitch of course meant that it was slower than other sewing projects, and any time there were more than two layers of fabric I had to use the stabbing motion rather than the sewing one, which is even slower, but other than a few places with many layers of both fabric and webbing it wasn t hard. And to be fair, the seams were fewer and shorter than other sewing projects, and with the usual interruptions and uneven time availability it was done in less than a month, which is somewhat typical for one of my handsewn projects. It may have been because of the pattern, but I think it s relevant that it was also easier than other backpacks I ve made, with significantly less cursing, even when doing seams that would have been quite fiddly when sewn by machine. I have to admit that now I m tempted to plan another backpack using the same pattern or a slight variation, sewn by machine in a different fabric, to see the difference in the time it takes and to check if the changes I think would make it easier to sew by machine are actually the right thing to do. But maybe I ll wait a bit, other projects are in the queue. The pattern is as usual online, released as #FreeSoftWear. Having used it for a while, I have to say that it is just the right size to fit all the things I usually carry, The fact that it only opens from the top means that finding things that have fallen to the very bottom involves a bit of rummaging, but not having to change a zipper every few years when (not if) it breaks is also very nice, so I m not sure which shape of backpack I prefer. The soft back of course is an issue when the backpack is filled with small items, but the molle webbing is there exactly because I have plans to solve it, beside the trivial put something flat towards the back . As an object, I m happy with the result. As a project, it was way more than successful, exceeding all expectations, especially for something somewhat experimental like this one was.

---

1. Make Your Own Gear, i.e. sewing or otherwise constructing outdoorish equipment.
2. at least not if I fill them with stuff as I usually do with my backpack :D

Update on 2025-07-28: added note about Debian 13/trixie support for OpenVox (thanks, Ben Ford!) Debian v13 with codename trixie is scheduled to be published as new stable release on 9th of August 2025. I was the driving force at several of my customers to be well prepared for the upcoming stable release (my efforts for trixie started in August 2024). On the one hand, to make sure packages we care about are available and actually make it into the release. On the other hand, to ensure there are no severe issues that make it into the release and to get proper and working upgrades. So far everything is looking pretty well and working fine, the efforts seemed to have payed off. :) As usual with major upgrades, there are some things to be aware of, and hereby I m starting my public notes on trixie that might be worth for other folks. My focus is primarily on server systems and looking at things from a sysadmin perspective. Further readings As usual start at the official Debian release notes, make sure to especially go through What s new in Debian 13 + issues to be aware of for trixie (strongly recommended read!). Package versions As a starting point, let s look at some selected packages and their versions in bookworm vs. trixie as of 2025-07-20 (mainly having amd64 in mind):

Package	bookworm/v12	trixie/v13
ansible	2.14.3	2.19.0
apache	2.4.62	2.4.64
apt	2.6.1	3.0.3
bash	5.2.15	5.2.37
ceph	16.2.11	18.2.7
docker	20.10.24	26.1.5
dovecot	2.3.19	2.4.1
dpkg	1.21.22	1.22.21
emacs	28.2	30.1
gcc	12.2.0	14.2.0
git	2.39.5	2.47.2
golang	1.19	1.24
libc	2.36	2.41
linux kernel	6.1	6.12
llvm	14.0	19.0
lxc	5.0.2	6.0.4
mariadb	10.11	11.8
nginx	1.22.1	1.26.3
nodejs	18.13	20.19
openjdk	17.0	21.0
openssh	9.2p1	10.0p1
openssl	3.0	3.5
perl	5.36.0	5.40.1
php	8.2+93	8.4+96
podman	4.3.1	5.4.2
postfix	3.7.11	3.10.3
postgres	15	17
puppet	7.23.0	8.10.0
python3	3.11.2	3.13.5
qemu/kvm	7.2	10.0
rsync	3.2.7	3.4.1
ruby	3.1	3.3
rust	1.63.0	1.85.0
samba	4.17.12	4.22.3
systemd	252.36	257.7-1
unattended-upgrades	2.9.1	2.12
util-linux	2.38.1	2.41
vagrant	2.3.4	2.3.7
vim	9.0.1378	9.1.1230
zsh	5.9	5.9

Misc unsorted

• The asterisk package once again didn t make it into trixie (see #1031046)
• The new debian-repro-status package provides the identically named command-line tool debian-repro-status to query the reproducibility status of your installed Debian packages
• The Grml live system project provided further of their packages into Debian. Available as of trixie are now also grml-keyring (OpenPGP certificates used for signing the Grml repositories), grml-hwinfo (a tool which collects information of the hardware ) + grml-paste (command line interface for paste.debian.net)
• If you use pacemaker, be aware that its fence-agents package is now a transitional package. All the fence-agents got split into separate packages (fence-agents-$whatever). If you want to have all the fence-agents available, make sure to install the fence-agents-all package. If you have Recommends disabled, you definitely should be aware of this.
• usrmerge is finalized (also see dpkg warning issue in release notes)
• For an overview of the XMPP/Jabber situation in trixie see xmpp-team s blog post
• The curl package now includes the wcurl command line tool, being a simple wrapper around curl to easily download files

apt The new apt version 3.0 brings several new features, including:

• support for colors (f.e. green for installs/upgrades, yellow for downgrades, red for removals, can be disabled via &dash&dashno-color, APT_NO_COLOR=1 or NO_COLOR=1 and customized via e.g. APT::Color::Action::Install cyan )
• organizes output in more readable sections and shows removals more prominently
• uses sequoia to verify signatures
• includes a new solver
• the new apt modernize-sources command converts /etc/apt/sources.list.d/*.list files into the new .sources format (AKA DEB822)
• the new apt distclean command removes all files under $statedir/lists except Release, Release.gpg, and InRelease (it can be used for example, when finalizing images distributed to users)
• new configuration option APT::NeverAutoRemove::KernelCount for keeping a configurable amount of kernels, f.e. setting APT::NeverAutoRemove::KernelCount 3 will keep 3 kernels (including the running, and most recent)
• new command line option &dash&dashsnapshot, and configuration option APT::Snapshot, controlling the snapshot chosen for archives with Snapshot: enable
• new command line option &dash&dashupdate to run the update command before the specified command, like apt &dash&dashupdate install zsh,
  apt &dash&dashupdate remove foobar or apt &dash&dashupdate safe-upgrade
• apt-key is gone, and there s no replacement for it available (if you need an interface for listing present keys)

systemd systemd got upgraded from v252.36-1~deb12u1 to 257.7-1 and there are lots of changes. Be aware that systemd v257 has a new net.naming_scheme, v257 being PCI slot number is now read from firmware_node/sun sysfs file. The naming scheme based on devicetree aliases was extended to support aliases for individual interfaces of controllers with multiple ports. This might affect you, see e.g. #1092176 and #1107187, the Debian Wiki provides further useful information. There are new systemd tools available:

• run0: temporarily and interactively acquire elevated or different privileges (serves a similar purpose as sudo)
• systemd-ac-power: Report whether we are connected to an external power source
• systemd-confext: Activates System Extension Images
• systemd-vpick: Resolve paths to .v/ versioned directories
• varlinkctl: Introspect with and invoke Varlink services

The tools provided by systemd gained several new options:

• busctl: new option &dash&dashlimit&dashmessages=NUMBER (Stop monitoring after receiving the specified number of message)
• hostnamectl: new option &dashj (same as &dash&dashjson=pretty on tty, &dash&dashjson=short otherwise)
• journalctl: new options &dash&dashimage&dashpolicy=POLICY (Specify disk image dissection policy), &dash&dashinvocation=ID (Show logs from the matching invocation ID), &dashI (Show logs from the latest invocation of unit), &dash&dashexclude-identifier=STRING (Hide entries with the specified syslog identifier),&dash&dashtruncate-newline (Truncate entries by first newline character), &dash&dashlist-invocations (Show invocation IDs of specified unit), &dash&dashlist-namespaces (Show list of journal namespaces)
• kernel-install: new commands add&dashall + list and plenty of new command line options
• localectl: new option &dash&dashfull (Do not ellipsize output)
• loginctl: new options &dash&dashjson=MODE (Generate JSON output for list-sessions/users/seats) + &dashj (Same as &dash&dashjson=pretty on tty, &dash&dashjson=short otherwise)
• networkctl: new commands edit FILES DEVICES (Edit network configuration files), cat [FILES DEVICES ] (Show network configuration files), mask FILES (Mask network configuration files) + unmask FILES (Unmask network configuration files) + persistent-storage BOOL (Notify systemd-networkd if persistent storage is ready), and new options &dash&dashno-ask-password (Do not prompt for password), &dash&dashno-reload (Do not reload systemd-networkd or systemd-udevd after editing network config), &dash&dashdrop-in=NAME (Edit specified drop-in instead of main config file), &dash&dashruntime (Edit runtime config files) + &dash&dashstdin (Read new contents of edited file from stdin)
• systemctl new commands list-paths [PATTERN] (List path units currently in memory, ordered by path), whoami [PID ] (Return unit caller or specified PIDs are part of), soft-reboot (Shut down and reboot userspace) + sleep (Put the system to sleep), and new options &dash&dashcapsule=NAME (Connect to service manager of specified capsule), &dash&dashbefore (Show units ordered before with list-dependencies ), &dash&dashafter (Show units ordered after with list-dependencies ), &dash&dashkill-value=INT (Signal value to enqueue), &dash&dashno-warn (Suppress several warnings shown by default), &dash&dashmessage=MESSAGE (Specify human readable reason for system shutdown), &dash&dashimage&dashpolicy=POLICY (Specify disk image dissection policy), &dash&dashreboot&dashargument=ARG (Specify argument string to pass to reboot()), &dash&dashdrop-in=NAME (Edit unit files using the specified drop-in file name), &dash&dashwhen=TIME (Schedule halt/power-off/reboot/kexec action after a certain timestamp) + &dash&dashstdin (Read
  new contents of edited file from stdin)
• systemd-analyze new commands architectures [NAME ] (List known architectures), smbios11 (List strings passed via SMBIOS Type #11), image-policy POLICY (Analyze image policy string), fdstore SERVICE (Show file descriptor store contents of service), malloc [D-BUS SERVICE ] (Dump malloc stats of a D-Bus service), has-tpm2 (Report whether TPM2 support is available), pcrs [PCR ] (Show TPM2 PCRs and their names) + srk [>FILE] (Write TPM2 SRK (to FILE)) and new options &dash&dashno-legend (Disable column headers and hints in plot with either &dash&dashtable or &dash&dashjson=), &dash&dashinstance=NAME (Specify fallback instance name for template units), &dash&dashunit=UNIT (Evaluate conditions and asserts of unit), &dash&dashtable (Output plot s raw time data as a table), &dash&dashscale-svg=FACTOR (Stretch x-axis of plot by FACTOR (default: 1.0)), &dash&dashdetailed (Add more details to SVG plot), &dash&dashtldr (Skip comments and empty lines), &dash&dashimage
  -policy=POLICY (Specify disk image dissection policy) + &dash&dashmask (Parse parameter as numeric capability mask)
• systemd-ask-password: new options &dash&dashuser (Ask only our own user s agents) + &dash&dashsystem (Ask agents of the system and of all users)
• systemd-cat: new option &dash&dashnamespace=NAMESPACE (Connect to specified journal namespace)
• systemd-creds: new options &dash&dashuser (Select user-scoped credential encryption), &dash&dashuid=UID (Select user for scoped credentials) + &dash&dashallow-null (Allow decrypting credentials with empty key)
• systemd-detect-virt: new options &dash&dashcvm (Only detect whether we are run in a confidential VM) + &dash&dashlist-cvm (List all known and detectable types of confidential virtualization)
• systemd-firstboot: new options &dash&dashimage-policy=POLICY (Specify disk image dissection policy), &dash&dashkernel-command-line=CMDLINE (Set kernel command line) + &dash&dashreset (Remove existing files)
• systemd-id128: new commands var-partition-uuid (Print the UUID for the /var/ partition) + show [NAME UUID] (Print one or more UUIDs), and new options &dash&dashno-pager (Do not pipe output into a pager), &dash&dashno-legend (Do not show the headers and footers), &dash&dashjson=FORMAT (Output inspection data in JSON), &dashj (Equivalent to &dash&dashjson=pretty (on TTY) or &dash&dashjson=short (otherwise)) + &dashP &dash&dashvalue (Only print the value)
• systemd-inhibit: new option &dash&dashno-ask-password (Do not attempt interactive authorization)
• systemd-machine-id-setup: new option &dash&dashimage-policy=POLICY (Specify disk image dissection policy)
• systemd-mount: new options &dash&dashjson=pretty short off (Generate JSON output) + &dash&dashtmpfs (Create a new tmpfs on the mount point)
• systemd-notify: new options &dash&dashreloading (Inform the service manager about configuration reloading), &dash&dashstopping (Inform the service manager about service shutdown), &dash&dashexec (Execute command line separated by ; once done), &dash&dashfd=FD (Pass specified file descriptor with along with message) + &dash&dashfdname=NAME (Name to assign to passed file descriptor(s))
• systemd-path: new option &dash&dashno-pager (Do not pipe output into a pager)
• systemd-run: new options &dash&dashexpand-environment=BOOL (Control expansion of environment variables), &dash&dashjson=pretty short off (Print unit name and invocation id as JSON), &dash&dashignore-failure (Ignore the exit status of the invoked process) + &dash&dashbackground=COLOR (Set ANSI color for background)
• systemd-sysext: new options &dash&dashmutable=yes no auto import ephemeral ephemeral-import (Specify a mutability mode of the merged hierarchy), &dash&dashno-reload (Do not reload the service manager), &dash&dashimage-policy=POLICY (Specify disk image dissection policy) + &dash&dashnoexec=BOOL (Whether to mount extension overlay with noexec)
• systemd-sysusers: new options &dash&dashtldr (Show non-comment parts of configuration) + &dash&dashimage-policy=POLICY (Specify disk image dissection policy)
• systemd-tmpfiles: new command &dash&dashpurge(Delete files and directories marked for creation in specified configuration files (careful!)), and new options &dash&dashuser (Execute user configuration), &dash&dashtldr (Show non-comment parts of configuration files), &dash&dashgraceful (Quietly ignore unknown users or groups), &dash&dashimage-policy=POLICY (Specify disk image dissection policy) + &dash&dashdry-run (Just print what would be done)
• systemd-umount: new options &dash&dashjson=pretty short off (Generate JSON output) + &dash&dashtmpfs (Create a new tmpfs on the mount point)
• timedatectl: new commands ntp-servers INTERFACE SERVER (Set the interface specific NTP servers) + revert INTERFACE (Revert the interface specific NTP servers) and new option &dashP NAME (Equivalent to &dash&dashvalue &dash&dashproperty=NAME)

Debian s systemd ships new binary packages:

• systemd-boot-efi-amd64-signed (Tools to manage UEFI firmware updates (signed))
• systemd-boot-tools (simple UEFI boot manager tools)
• systemd-cryptsetup (Provides cryptsetup, integritysetup and veritysetup utilities)
• systemd-netlogd (journal message forwarder)
• systemd-repart (Provides the systemd-repart and systemd-sbsign utilities)
• systemd-standalone-shutdown (standalone shutdown binary for use in exitrds)
• systemd-ukify (tool to build Unified Kernel Images)

Linux Kernel The trixie release ships a Linux kernel based on latest longterm version 6.12. As usual there are lots of changes in the kernel area, including better hardware support, and this might warrant a separate blog entry. To highlight some changes with Debian trixie:

• New Debian package linux-bpf-dev, providing the header file for BPF CO-RE builds
• New Debian package intel-sdsi, Intel On Demand (SDSi) provisioning tool
• New Debian package virtme-ng, providing helper scripts to easily test a Linux kernel on a QEMU VM
• The kernel modules are installed xz compressed
• Several new syscalls, like cachestat, fchmodat2, futex_wake, futex_wait, futex_requeue, listmount, statmount, lsm_get_self_attr/lsm_set_self_attr/lsm_list_modules/, mseal + setxattrat/getxattrat/listxattrat/removexattrat
• New Integrity Policy Enforcement (IPE) LSM
• Plenty of changes in io_uring, including support for bind/listen
• support devices with a block size larger than system page sizes in the XFS filesystem + VFS
• ntfs driver was replaced by ntfs3
• Device Memory TCP for faster network device transfers
• Support for perf ftrace profile
• support for atomic write operations in the block layer
• FUSE pass-through for file I/O
• ability to prevent writes to block devices containing mounted filesystems
• support for data-type profiling in the perf tool
• Guest-first memory for KVM
• TCP Authentication Option Linux implementation [RFC5925]
• mount beneath support for filesystems
• new noswap mount option for tmpfs filesystems
• Linux NFS server gained support for RPC-with-TLS [RFC 9289 (Towards Remote Procedure Call Encryption by Default)]
• PLB (Protective Load Balancing) for IPv6 (PLB is a host based mechanism for load balancing across switch links)

See Kernelnewbies.org for further changes between kernel versions. Configuration management For puppet users, Debian provides the puppet-agent (v8.10.0), puppetserver (v8.7.0) and puppetdb (v8.4.1) packages. Puppet s upstream does not provide packages for trixie, yet. Given how long it took them for Debian bookworm, and with their recent Plans for Open Source Puppet in 2025, it s unclear when (and whether at all) we might get something. As a result of upstream behavior, also the OpenVox project evolved, and they already provide Debian 13/trixie support (https://apt.voxpupuli.org/openvox8-release-debian13.deb). FYI: the AIO puppet-agent package for bookworm (v7.34.0-1bookworm) so far works fine for me on Debian/trixie. Be aware that due to the apt-key removal you need a recent version of the puppetlabs-apt for usage with trixie. The puppetlabs-ntp module isn t yet ready for trixie (regarding ntp/ntpsec), if you should depend on that. ansible is available and made it with version 2.19 into trixie. Prometheus stack Prometheus server was updated from v2.42.0 to v2.53, and all the exporters that got shipped with bookworm are still around (in more recent versions of course). Trixie gained some new exporters:

• prometheus-dnsmasq-exporter
• prometheus-mysqlrouter-exporter
• prometheus-pgbackrest-exporter
• prometheus-pgbouncer-exporter
• prometheus-phpfpm-exporter

Virtualization docker (v26.1.5), ganeti (v3.1.0), libvirt (v11.3.0, be aware of significant changes to libvirt packaging), lxc (v6.0.4), podman (v5.4.2), openstack (see openstack-team on Salsa), qemu/kvm (v10.0.2), xen (v4.20.0) are all still around. Proxmox already announced their PVE 9.0 BETA, being based on trixie and providing 6.14.8-1 kernel, QEMU 10.0.2, LXC 6.0.4, OpenZFS 2.3.3. Vagrant is available in version 2.3.7, but Vagrant upstream does not provide packages for trixie yet. Given that HashiCorp adopted the BSL, the future of vagrant in Debian is unclear. If you re relying on VirtualBox, be aware that upstream doesn t provide packages for trixie, yet. VirtualBox is available from Debian/unstable (version 7.1.12-dfsg-1 as of 2025-07-20), but not shipped with stable release since quite some time (due to lack of cooperation from upstream on security support for older releases, see #794466). Be aware that starting with Linux kernel 6.12, KVM initializes virtualization on module loading by default. This prevents VirtualBox VMs from starting. In order to avoid this, either add kvm.enable_virt_at_load=0 parameter into kernel command line or unload the corresponding kvm_intel / kvm_amd module. If you want to use Vagrant with VirtualBox on trixie, be aware that Debian s vagrant package as present in trixie doesn t support the VirtualBox package version 7.1 as present in Debian/unstable (manually patching vagrant s meta.rb and rebuilding the package without Breaks: virtualbox (>= 7.1) is known to be working). util-linux The are plenty of new options available in the tools provided by util-linux:

• blkdiscard: new option &dash&dashquiet (suppress warning messages)
• blockdev: new options &dash&dashgetdiskseq (get disk sequence number) + &dash&dashgetzonesz (get zone size)
• dmesg: new option &dash&dashkmsg-file (use the file in kmsg format), new &dash&dashtime-format argument raw
• findmnt: new options &dash&dashlist-columns (list the available columns), &dash&dashdfi (imitate the output of df(1) with -i option), &dash&dashid (filter by mount node ID), &dash&dashfilter (apply display filter) + &dash&dashuniq-id (filter by
  mount node 64-bit ID)
• fstrim: new option -types . (limit the set of filesystem types)
• hardlink: new options &dash&dashrespect-dir (directory names have to be identical), &dash&dashexclude-subtree (regular expression to exclude directories), &dash&dashprioritize-trees (files found in the earliest specified top-level directory have higher priority), &dash&dashlist-duplicates (print every group of duplicate files), &dash&dashmount (stay within the same filesystem) + &dash&dashzero (delimit output with NULs instead of newlines)
• ipcmk: new options &dash&dashposix-shmem (create POSIX shared memory segment of size), &dash&dashposix-semaphore (create POSIX semaphore), &dash&dashposix-mqueue (create POSIX message queue) + &dash&dashname (name of the POSIX resource)
• ipcrm: new options &dash&dashposix-shmem (remove POSIX shared memory segment by name), &dash&dashposix-mqueue (remove POSIX message queue by name), &dash&dashposix-semaphore (remove POSIX semaphore by name) + &dash&dashall= (remove all in specified category)
• lsblk: new options &dash&dashct-filter (restrict the next counter), &dash&dashct (define a custom counter), &dash&dashhighlight (colorize lines matching the expression), &dash&dashlist-columns (list the available columns), &dash&dashnvme (output info about NVMe devices), &dash&dashproperties-by (methods used to gather data), &dash&dashfilter (print only lines matching the expression), &dash&dashvirtio (output info about virtio devices)
• lscpu: new options &dash&dashraw (use raw output format (for -e, -p and -C)) + &dash&dashhierarchic= (use subsections in summary (auto, never, always))
• lsipc: new options &dash&dashposix-shmems (POSIX shared memory segments), &dash&dashposix-mqueues (POSIX message queues), &dash&dashposix-semaphores (POSIX semaphores), &dash&dashname (POSIX resource identified by name)
• lslocks: new option &dash&dashlist-columns (list the available columns)
• lslogins: new option &dash&dashlastlog2 (set an alternate path for lastlog2)
• lsns: new options &dash&dashpersistent (namespaces without processes), &dash&dashfilter (apply display filter) + &dash&dashlist-columns (list the available columns)
• mkswap: new options &dash&dashendianness= (specify the endianness to use (native, little or big)), &dash&dashoffset (specify the offset in the device), &dash&dashsize (specify the size of a swap file in bytes) + &dash&dashfile (create a swap file)
• namei: &dash&dashcontext (print any security context of each file)
• nsenter: new options &dash&dashnet-socket (enter socket s network namespace), &dash&dashuser-parent (enter parent user namespace), &dash&dashkeep-caps (retain capabilities granted in user namespaces), &dash&dashenv (inherit environment variables from tar get process) + &dash&dashjoin-cgroup (join the cgroup of the target process)
• runuser: new option &dash&dashno-pty (do not create a new pseudo-terminal)
• setarch: new option &dash&dashshow= (show current or specific personality and exit)
• setpriv: new options &dash&dashptracer (allow ptracing from the given process), &dash&dashlandlock-access (add Landlock access), &dash&dashlandlock-rule (add Landlock rule) + &dash&dashseccomp-filter (load seccomp filter from file)
• su: new option &dash&dashno-pty (do not create a new pseudo-terminal)
• unshare: new option &dash&dashload-interp ( load binfmt definition in the namespace)
• whereis: new option -g (interpret name as glob (pathnames pattern))
• wipefs: new argument option feature for &dash&dashbackup= option to specify directory (instead of default $HOME)
• zramctl: new option &dash&dashalgorithm-params (algorithm parameters to use)

Now no longer present in util-linux as of trixie:

• addpart (tell the kernel about the existence of a specified partition): use partx instead
• delpart (tell the kernel to forget about a specified partition): use partx instead
• last (show a listing of last logged in users, binary got moved to wtmpdb), lastb (show a listing of last logged in users), mesg (control write access of other users to your terminal), utmpdump (dump UTMP and WTMP files in raw format): see Debian release notes for details

The following binaries got moved from util-linux to the util-linux-extra package:

• ctrlaltdel (set the function of the Ctrl-Alt-Del combination)
• mkfs.bfs (make an SCO bfs filesystem)
• fsck.cramfs + mkfs.cramfs (compressed ROM file system)
• fsck.minix + mkfs.minix (Minix filesystem)
• resizepart (tell the kernel about the new size of a partition)

And the util-linux-extra package also provides new tools:

• bits: convert bit masks from/to various formats
• blkpr: manage persistent reservations on a device
• coresched: manage core scheduling cookies for tasks
• enosys: utility to make syscalls fail with ENOSYS
• exch: atomically exchanges paths between two files
• fadvise: utility to use the posix_fadvise system call
• pipesz: set or examine pipe buffer sizes and optionally execute command.
• waitpid: utility to wait for arbitrary processes

OpenSSH OpenSSH was updated from v9.2p1 to 10.0p1-5, so if you re interested in all the changes, check out the release notes between those versions (9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9 + 10.0). Let s highlight some notable behavior changes in Debian:

• OpenSSH no longer supports DSA keys: see Debian s release notes for further details
• openssh-server no longer reads ~/.pam_environment: see Debian s release notes for further details

There are some notable new features:

• allow forwarding Unix Domain sockets via ssh -W
• OpenSSH penalty behavior: visit my separate blog post for more details
• add support for reading ED25519 private keys in PEM PKCS8 format. Previously only the OpenSSH private key format was supported.
• the new hybrid post-quantum algorithm mlkem768x25519-sha256 (based on the FIPS 203 Module-Lattice Key Encapsulation mechanism (ML-KEM) combined with X25519 ECDH) is now used by default for key agreement. This algorithm is considered to be safe against attack by quantum computers, is guaranteed to be no less strong than the popular curve25519-sha256 algorithm, has been standardised by NIST and is considerably faster than the previous default.
• the ssh-agent will now delete all loaded keys when signaled with SIGUSR1. This allows deletion of keys without having access to $SSH_AUTH_SOCK.
• support systemd-style socket activation in ssh-agent using the LISTEN_PID/LISTEN_FDS mechanism. Activated when these environment variables are set, the agent is started with the -d or -D option and no socket path is set.
• add a sshd -G option that parses and prints the effective configuration without attempting to load private keys and perform other checks. (This allows usage of the option before keys have been generated and for configuration evaluation and verification by unprivileged users.)
• add support for configuration tags to ssh(1). This adds a ssh_config(5) Tag directive and corresponding Match tag predicate that may be used to select blocks of configuration.
• add a match localnetwork predicate. This allows matching on the addresses of available network interfaces and may be used to vary the effective client configuration based on network location.
• add a %j token that expands to the configured ProxyJump hostname
• add support for Match sessiontype to ssh_config. Allows matching on the type of session initially requested, either shell for interactive sessions, exec for command execution sessions, subsystem for subsystem requests, such as sftp, or none for transport/forwarding-only sessions.
• allow glob(3) patterns to be used in sshd_config AuthorizedKeysFile and AuthorizedPrincipalsFile directives.

Thanks to everyone involved in the release, looking forward to trixie + and happy upgrading!
Let s continue with working towards Debian/forky. :)

Welcome to the 6th report from the Reproducible Builds project in 2025. Our monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. If you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website. In this report:

1. Reproducible Builds at FOSSY 2025
2. Distribution work
3. diffoscope
4. OSS Rebuild updates
5. Website updates
6. Upstream patches
7. Reproducibility testing framework

---

Reproducible Builds at FOSSY 2025 On Saturday 2nd August, Vagrant Cascadian and Chris Lamb will be presenting at this year s FOSSY 2025. Their talk, titled Never Mind the Checkboxes, Here s Reproducible Builds!, is being introduced as follows:

There are numerous policy compliance and regulatory processes being developed that target software development but do they solve actual problems? Does it improve the quality of software? Do Software Bill of Materials (SBOMs) actually give you the information necessary to verify how a given software artifact was built? What is the goal of all these compliance checklists anyways or more importantly, what should the goals be? If a software object is signed, who should be trusted to sign it, and can they be trusted forever?

The talk will introduce the audience to Reproducible Builds as a set of best practices which allow users and developers to verify that software artifacts were built from the source code, but also allows auditing for license compliance, providing security benefits, and removes the need to trust arbitrary software vendors. Hosted by the Software Freedom Conservancy and taking place in Portland, Oregon, USA, FOSSY aims to be a community-focused event: Whether you are a long time contributing member of a free software project, a recent graduate of a coding bootcamp or university, or just have an interest in the possibilities that free and open source software bring, FOSSY will have something for you . More information on the event is available on the FOSSY 2025 website, including the full programme schedule. Vagrant and Chris will also be staffing a table this year, where they will be available to answer any questions about Reproducible Builds and discuss collaborations with other projects.

---

Distribution work In Debian this month:

• Holger Levsen has discovered that it is now possible to bootstrap a minimal Debian trixie using 100% reproducible packages. This result can itself be reproduced, using the debian-repro-status tool and mmdebstrap s support for hooks:

    $ mmdebstrap --variant=apt --include=debian-repro-status \
         --chrooted-customize-hook=debian-repro-status \
         trixie /dev/null 2>&1   grep "Your system has"
     INFO  debian-repro-status > Your system has 100.00% been reproduced.
  

• On our mailing list this month, Helmut Grohne wrote an extensive message raising an issue related to Uploads with conflicting buildinfo filenames:

  Having several .buildinfo files for the same architecture is something that we plausibly want to have eventually. Imagine running two sets of buildds and assembling a single upload containing buildinfo files from both buildds in the same upload. In a similar vein, as a developer I may want to supply several .buildinfo files with my source upload (e.g. for multiple architectures). Doing any of this is incompatible with current incoming processing and with reprepro.

• 5 reviews of Debian packages were added, 4 were updated and 8 were removed this month adding to our ever-growing knowledge about identified issues.

In GNU Guix, Timothee Mathieu reported that a long-standing issue with reproducibility of shell containers across different host operating systems has been solved. In their message, Timothee mentions:

I discovered that pytorch (and maybe other dependencies) has a reproducibility problem of order 1e-5 when on AVX512 compared to AVX2. I first tried to solve the problem by disabling AVX512 at the level of pytorch, but it did not work. The dev of pytorch said that it may be because some components dispatch computation to MKL-DNN, I tried to disable AVX512 on MKL, and still the results were not reproducible, I also tried to deactivate in openmpi without success. I finally concluded that there was a problem with AVX512 somewhere in the dependencies graph but I gave up identifying where, as this seems very complicated.

The IzzyOnDroid Android APK repository made more progress in June. Not only have they just passed 48% reproducibility coverage, Ben started making their reproducible builds more visible, by offering rbtlog shields, a kind of badge that has been quickly picked up by many developers who are proud to present their applications reproducibility status.
Lastly, in openSUSE news, Bernhard M. Wiedemann posted another monthly update for their work there.

diffoscope diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 298, 299 and 300 to Debian:

• Add python3-defusedxml to the Build-Depends in order to include it in the Docker image. [ ]
• Handle the RPM format s HEADERSIGNATURES and HEADERIMMUTABLE as a special-case to avoid unnecessarily large diffs. Thanks to Daniel Duan for the report and suggestion. [ ][ ]
• Update copyright years. [ ]

In addition, @puer-robustus fixed a regression introduced in an earlier commit which resulted in some differences being lost. [ ][ ] Lastly, Vagrant Cascadian updated diffoscope in GNU Guix to version 299 [ ][ ] and 300 [ ][ ].

OSS Rebuild updates OSS Rebuild has added a new network analyzer that provides transparent HTTP(S) interception during builds, capturing all network traffic to monitor external dependencies and identify suspicious behavior, even in unmodified maintainer-controlled build processes. The text-based user interface now features automated failure clustering that can group similar rebuild failures and provides natural language failure summaries, making it easier to identify and understand patterns across large numbers of build failures. OSS Rebuild has also improved the local development experience with a unified interface for build execution strategies, allowing for more extensible environment setup for build execution. The team also designed a new website and logo.

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

• Arnaud Brousseau added Stage , a new Linux distribution, to our Tools page.
• Chris Lamb improved the docker instructions on the diffoscope website. [ ]

---

Upstream 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 appropriate. This month, we wrote a large number of such patches, including:

• Chris Riches:
  • rpm
• Bernhard M. Wiedemann:
  • arandr, curl, dpdk, dpdk, eww, gnucash, gramps, latex2html, llvm20, mp, nvidia-open-driver-G06-signed, obs, ovmf, pcre2, perl-XML-LibXML, perl, python-reportlab, python313, qt6-datavis3d, qt6-declarative, qt6-sensors, qt6-virtualkeyboard, rage-encryption, scummvm, timescaledb & zoxide.
  • Plus several issues with how rpmbuild expands the %jobs variable in the .src.rpm header, including: chromium, cmake, edk2, firefox-esr, gnome-keyring-sharp, gtk2-engine-aurora, gtk2-engine-cleanice, gtk2-engines, libqt5-qtlocation, libreoffice, luabind, lxmenu-data, mozc, MozillaThunderbird, perl-DateTime-Calendar-Mayan, perl-Getopt-ArgvFile, perl-MooseX-Meta-TypeConstraint-ForceCoercion, perl-XML-Entities, python-convertdate, suitesparse & webkit2gtk3
• Robin Candau:
  • gramps (use SOURCE_DATE_EPOCH when compressing man pages)
• Chris Lamb:
  • #1108273 filed against tree-puzzle.
  • #1108281 filed against cctools.
  • #1108532 filed against python-django-import-export.

---

Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In June, however, a number of changes were made by Holger Levsen, including:

• reproduce.debian.net-related:
  • Installed and deployed rebuilderd version 0.24 from Debian unstable in order to make use of the new compression feature added by Jarl Gullberg for the database. This resulted in massive decrease of the SQLite databases:
    • 79G 2.8G (all)
    • 84G 3.2G (amd64)
    • 75G 2.9G (arm64)
    • 45G 2.1G (armel)
    • 48G 2.2G (armhf)
    • 73G 2.8G (i386)
    • 72G 2.7G (ppc64el)
    • 45G 2.1G (riscv64)
    for a combined saving from 521G 20.8G. This naturally reduces the requirements to run an independent rebuilderd instance and will permit us to add more Debian suites as well.
  • During migration to the latest version of rebuilderd, make sure several services are not started. [ ]
  • Actually run rebuilderd from /usr/bin. [ ]
  • Raise temperatures for NVME devices on some riscv64 nodes that should be ignored. [ ][ ]
  • Use a 64KB kernel page size on the ppc64el architecture (see #1106757). [ ]
  • Improve ordering of some failed to reproduce statistics. [ ]
  • Detect a number of potential causes of build failures within the statistics. [ ][ ]
  • Add support for manually scheduling for the any architecture. [ ]
• Misc:
  • Update the Codethink nodes as there are now many kernels installed. [ ][ ]
  • Install linux-sysctl-defaults on Debian trixie systems as we need ping functionality. [ ]
  • Limit the fs.nr_open kernel turnable. [ ]
  • Stop submitting results to deprecated buildinfo.debian.net service. [ ][ ]

In addition, Jochen Sprickerhof greatly improved the statistics and the logging functionality, including adopting to the new database format of rebuilderd version 0.24.0 [ ] and temporarily increasing maximum log size in order to debug a nettlesome build [ ]. Jochen also dropped the CPUSchedulingPolicy=idle systemd flag on the workers. [ ]

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:

• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org

Off-and-on over the last several weeks, I've been spending time trying to learn/understand YubiKeys better, especially from the perspective of ECDSA and signing. I had a good mental model for how "slots" work (canonically referenced by their hexadecimal names such as 9C), but found that it had a gap related to "objects"; while closing that, I was annoyed that the main reference table for this gap lives primarily in either a PDF or inside several implementations, so I figured I should create the reference I want to see in the world, but that it would also be useful to write down some of my understanding for my own (and maybe others') future reference. So, to that end, I'm going to start with a bit ( ) of background information, with the heavy caveat that this only applies to "PIV" ("FIPS 201") usage of YubiKeys, and that I only actually care about ECDSA, although I've been reassured that it's the same for at least RSA (anything outside this is firmly Here Be Not Tianon; "gl hf dd"). (Incidentally, learning all this helped me actually appreciate the simplicity of cloud-based KMS solutions, which was an unexpected side effect. ) At a really high level, ECDSA is like many other (asymmetric) cryptographic solutions you've got a public key and a private key, the private key can be used to "sign" data (tiny amounts of data, in fact, like P-256 can only reasonably sign 256 bits of data, which is where cryptographic hashes like SHA256 come in as secure analogues for larger data in small bit sizes), and the public key can then be used to verify that the data was indeed signed by the private key, and only someone with the private key could've done so. There's some complex math and RNGs involved, but none of that's actually relevant to this post, so find that information elsewhere. Unfortunately, this is where things go off the rails: PIV is X.509 ("x509") heavy, and there's no X.509 in the na ve view of my use case. In a YubiKey (or any other PIV-signing-supporting smart card? do they actually have competitors in this specific niche? ), a given "slot" can hold one single private key. There are ~24 slots which can hold a private key and be used for signing, although "Slot 9c" is officially designated as the "Digital Signature" slot and is encouraged for signing purposes. One of the biggest gotchas is that with pure-PIV (and older YubiKey firmware ) the public key for a given slot is only available at the time the key is generated, and the whole point of the device in the first place is that the private key is never, ever available from it (all cryptographic operations happen inside the device), so if you don't save that public key when you first ask the device to generate a private key in a particular slot, the public key is lost forever (asterisk). With that background, now let's get to the second aspect of "slots" and how X.509 fits. For every aforementioned slot, there is a corresponding "object" (read: place to store arbitrary data) which is corresponding only by convention. For all these "key" slots the (again, by convention) corresponding "object" is explicitly supposed to be an X.509 certificate (see also the PDF reference linked above). It turns out this is a useful and topical place to store that public key we need to keep handy! It's also an interesting place to shove additional details about what the key in a given slot is being used for, if that's your thing. Converting the raw public key into a (likely self-signed) X.509 certificate is an exercise for the reader, but if you want to follow the conventions, you need some way to convert a given "slot" to the corresponding "object", and that is the lookup table I wish existed in more forms. So, without further ado, here is the anti-climax:

Slot	Object	Description
0x9A	0x5FC105	X.509 Certificate for PIV Authentication
0x9E	0x5FC101	X.509 Certificate for Card Authentication
0x9C	0x5FC10A	X.509 Certificate for Digital Signature
0x9D	0x5FC10B	X.509 Certificate for Key Management
0x82	0x5FC10D	Retired X.509 Certificate for Key Management 1
0x83	0x5FC10E	Retired X.509 Certificate for Key Management 2
0x84	0x5FC10F	Retired X.509 Certificate for Key Management 3
0x85	0x5FC110	Retired X.509 Certificate for Key Management 4
0x86	0x5FC111	Retired X.509 Certificate for Key Management 5
0x87	0x5FC112	Retired X.509 Certificate for Key Management 6
0x88	0x5FC113	Retired X.509 Certificate for Key Management 7
0x89	0x5FC114	Retired X.509 Certificate for Key Management 8
0x8A	0x5FC115	Retired X.509 Certificate for Key Management 9
0x8B	0x5FC116	Retired X.509 Certificate for Key Management 10
0x8C	0x5FC117	Retired X.509 Certificate for Key Management 11
0x8D	0x5FC118	Retired X.509 Certificate for Key Management 12
0x8E	0x5FC119	Retired X.509 Certificate for Key Management 13
0x8F	0x5FC11A	Retired X.509 Certificate for Key Management 14
0x90	0x5FC11B	Retired X.509 Certificate for Key Management 15
0x91	0x5FC11C	Retired X.509 Certificate for Key Management 16
0x92	0x5FC11D	Retired X.509 Certificate for Key Management 17
0x93	0x5FC11E	Retired X.509 Certificate for Key Management 18
0x94	0x5FC11F	Retired X.509 Certificate for Key Management 19
0x95	0x5FC120	Retired X.509 Certificate for Key Management 20

See also "piv-objects.json" for a machine-readable copy of this data. (Major thanks to paultag and jon gzip johnson for helping me learn and generally putting up with me, but especially dealing with my live-stream-of-thoughts while I stumble through the dark. )