Yesterday I tagged a new version of onak, my OpenPGP compatible keyserver. I’d spent a bit of time during DebConf doing some minor cleanups, in particular an annoying systemd socket activation issue I’d been seeing. That turned out to be due completely failing to compile in the systemd support, even when it was detected. There was also a signature verification issue with certain Ed225519 signatures (thanks Antoine Beaupré for making me dig into that one), along with various code cleanups.

I also worked on Stateless OpenPGP CLI support, which is something I talked about when I released 0.6.2. It isn’t something that’s suitable for release, but it is sufficient to allow running the OpenPGP interoperability test suite verification tests, which I’m pleased to say all now pass.

For the next release I’m hoping the OpenPGP crypto refresh process will have completed, which at the very least will mean adding support for v6 packet types and fingerprints. The PostgreSQL DB backend could also use some love, and I might see if performance with SQLite3 has improved any.

Anyway. Available locally or via GitHub.

0.6.3 - 26th September 2023

• Fix systemd detection + socket activation
• Add CMake checking for Berkeley DB
• Minor improvements to keyd logging
• Fix decoding of signature creation time
• Relax version check on parsing signature + key packets
• Improve HTML escaping
• Handle failed database initialisation more gracefully
• Fix bug with EDDSA signatures with top 8+ bits unset

(I wrote this up for an internal work post, but I figure it’s worth sharing more publicly too.)

I spent last week at DebConf23, this years instance of the annual Debian conference, which was held in Kochi, India. As usual, DebConf provides a good reason to see a new part of the world; I’ve been going since 2004 (Porto Alegre, Brazil), and while I’ve missed a few (Mexico, Bosnia, and Switzerland) I’ve still managed to make it to instances on 5 continents.

This has absolutely nothing to do with work, so I went on my own time + dime, but I figured a brief write-up might prove of interest. I first installed Debian back in 1999 as a machine that was being co-located to operate as a web server / email host. I was attracted by the promise of easy online upgrades (or, at least, upgrades that could be performed without the need to be physically present at the machine, even if they naturally required a reboot at some point). It has mostly delivered on this over the years, and I’ve never found a compelling reason to move away. I became a Debian Developer in 2000. As a massively distributed volunteer project DebConf provides an opportunity to find out what’s happening in other areas of the project, catch up with team mates, and generally feel more involved and energised to work on Debian stuff. Also, by this point in time, a lot of Debian folk are good friends and it’s always nice to catch up with them.

On that point, I felt that this year the hallway track was not quite the same as usual. For a number of reasons (COVID, climate change, travel time, we’re all getting older) I think fewer core teams are achieving critical mass at DebConf - I was the only member physically present from 2 teams I’m involved in, and I’d have appreciated the opportunity to sit down with both of them for some in-person discussions. It also means it’s harder to use DebConf as a venue for advancing major changes; previously having all the decision makers in the same space for a week has meant it’s possible to iron out the major discussion points, smoothing remote implementation after the conference. I’m told the mini DebConfs are where it’s at for these sorts of meetings now, so perhaps I’ll try to attend at least one of those next year.

Of course, I also went to a bunch of talks. I have differing levels of comment about each of them, but I’ve written up some brief notes below about the ones I remember something about. The comment was made that we perhaps had a lower level of deep technical talks, which is perhaps true but I still think there were a number of high level technical talks that served to pique ones interest about the topic.

Finally, this DebConf was the first I’m aware of that was accompanied by tragedy; as part of the day trip Abraham Raji, a project member and member of the local team, was involved in a fatal accident.

Talks (videos not yet up for all, but should appear for most)

• Opening Ceremony
  Not much to say here; welcome to DebConf!

• Continuous Key-Signing Party introduction
  I ended up running this, as Gunnar couldn’t make it. Debian makes heavy use of the OpenPGP web of trust (no mass ability to send out Yubikeys + perform appropriate levels of identity verification), so making sure we’re appropriately cross-signed, and linked to local conference organisers, is a dull but important part of the conference. We use a modified keysigning approach where identity verification + fingerprint confirmation happens over the course of the conference, so this session was just to explain how that works and confirm we were all working from the same fingerprint list.

• State of Stateless - A Talk about Immutability and Reproducibility in Debian
  Stateless OSes seem to be gaining popularity, so I went along to this to see if there was anything of note. It was interesting, but nothing earth shattering - very high level.

• What’s missing so that Debian is finally reproducible?
  Reproducible builds are something I’ve been keeping an eye on for a long time, and I continue to be impressed by the work folks are putting into this - both for Debian, and other projects. From a security standpoint reproducible builds provide confidence against trojaned builds, and from a developer standpoint knowing you can build reproducibly helps with not having to keep a whole bunch of binary artefacts around.

• Hello from keyring-maint
  In the distant past the process of getting your OpenPGP key into the Debian keyring (which is used to authenticate uploads + votes, amongst other things) was a clunky process that was often stalled. This hasn’t been the case for at least the past 10 years, but there’s still a residual piece of project memory that thinks keyring is a blocker. So as a team we say hi and talk about the fact we do monthly updates and generally are fairly responsive these days.

• A declarative approach to Linux networking with Netplan
  Debian’s /etc/network/interfaces is a fairly basic (if powerful) mechanism for configuring network interfaces. NetworkManager is a better bet for dynamic hosts (i.e. clients), and systemd-network seems to be a good choice for servers (I’m gradually moving machines over to it). Netplan tries to provide a unified mechanism for configuring both with a single configuration language. A noble aim, but I don’t see a lot of benefit for anything I use - my NetworkManager hosts are highly dynamic (so no need to push shared config) and systemd-network (or /etc/network/interfaces) works just fine on the other hosts. I’m told Netplan has more use with more complicated setups, e.g. when OpenVSwitch is involved.

• Quick peek at ZFS, A too good to be true file system and volume manager.
  People who use ZFS rave about it. I’m naturally suspicious of any file system that doesn’t come as part of my mainline kernel. But, as a longtime cautious mdraid+lvm+ext4 user I appreciate that there have been advances in the file system space that maybe I should look at, and I’ve been trying out btrfs on more machines over the past couple of years. I can’t deny ZFS has a bunch of interesting features, but nothing I need/want that I can’t get from an mdraid+lvm+btrfs stack (in particular data checksumming + reflinks for dedupe were strong reasons to move to btrfs over ext4).

• Bits from the DPL
  Exactly what it says on the tin; some bits from the DPL.

• Adulting
  Enrico is always worth hearing talk; Adulting was no exception. Main takeaway is that we need to avoid trying to run the project on martyrs and instead make sure we build a sustainable project. I’ve been trying really hard to accept I just don’t have time to take on additional responsibilities, no matter how interesting or relevant they might seem, so this resonated.

• My life in git, after subversion, after CVS.
  Putting all of your home directory in revision control. I’ve never made this leap; I’ve got some Ansible playbooks that push out my core pieces of configuration, which is held in git, but I don’t actually check this out directly on hosts I have accounts on. Interesting, but not for me.

• EU Legislation BoF - Cyber Resilience Act, Product Liability Directive and CSAM Regulation
  The CRA seems to be a piece of ill informed legislation that I’m going to have to find time to read properly. Discussion was a bit more alarmist than I personally feel is warranted, but it was a short session, had a bunch of folk in it, and even when I removed my mask it was hard to make myself understood.

• What’s new in the Linux kernel (and what’s missing in Debian)
  An update from Ben about new kernel features. I’m paying less attention to such things these days, so nice to get a quick overview of it all.

• Intro to SecureDrop, a sort-of Linux distro
  Actually based on Ubuntu, but lots of overlap with Debian as a result, and highly customised anyway. Notable, to me, for using OpenPGP as some of the backend crypto support. I managed to talk to Kunal separately about some of the pain points around that, which was an interesting discussion - they’re trying to move from GnuPG to Sequoia, primarily because of the much easier integration and lack of requirement for the more complicated GnuPG features that sometimes get in the way.

• The Docker(.io) ecosystem in Debian
  I hate Docker. I’m sure it’s fine if you accept it wants to take over the host machine entirely, but when I’ve played around with it that’s not been the case. This talk was more about the difficulty of trying to keep a fast moving upstream with lots of external dependencies properly up to date in a stable release. Vendoring the deps and trying to get a stable release exception seems like the least bad solution, but it’s a problem that affects a growing number of projects.

• Chiselled containers
  This was kinda of interesting, but I think I missed the piece about why more granular packaging wasn’t an option. The premise is you can take an existing .deb and “chisel” it into smaller components, which then helps separate out dependencies rather than pulling in as much as the original .deb would. This was touted as being useful, in particular, for building targeted containers. Definitely appealing over custom built userspaces for containers, but in an ideal world I think we’d want the information in the main packaging and it becomes a lot of work.

• Debian Contributors shake-up
  Debian Contributors is a great site for massaging your ego around contributions to Debian; it’s also a useful point of reference from a data protection viewpoint in terms of information the project holds about contributors - everything is already public, but the Contributors website provides folk with an easy way to find their own information (with various configurable options about whether that’s made public or not). Tássia is working on improving the various data feeds into the site, but realistically this is the responsibility of every Debian service owner.

• New Member BOF
  I’m part of the teams that help get new folk into Debian - primarily as a member of the New Member Front Desk, but also as a mostly inactive Application Manager. It’s been a while since we did one of these sessions so the Front Desk/Debian Account Managers that were present did a panel session. Nothing earth shattering came out of it; like keyring-maint this is a team that has historically had problems, but is currently running smoothly.

I’ve just finalised the OpenPGP key list for the DebConf 23 Keysigning party. This will follow the “new style” approach of being a continuous keysigning throughout the course of the conference, with an introduction session up front to confirm no one’s fingerprint is corrupted and that we all calculated the same hash of the file. Participants will then verify each other’s identities over the conference week, hopefully being able to build up a better level of verification than a one shot key signing session.

Those paying attention will note that my key details have changed this year; I am finally make a concerted effort to migrate to an elliptic curve based key. I managed to bootstrap it sufficiently at OMGWTFBBQ, but I’m keen to ensure it’s well integrated into the web of trust, so please do come talk to me at DebConf so we can exchange fingerprints!

pub   ed25519 2023-08-19 [C] [expires: 2025-08-18]
      419F B4B6 567E 6EF7 DEAF  80A0 9026 108F B942 BEA4
uid           [ultimate] Jonathan McDowell <noodles@earth.li>

(I’ve no reason to suspect problems with my old key and will be making a graceful changeover in the Debian keyring at some point in October after I’ve performed the September keyring update; that’ll give things a couple of months to catch up before it’s my turn to do an update again.)

As is traditional for the UK August Bank Holiday weekend I made my way to Cambridge for the Debian UK BBQ. As was pointed out we’ve been doing this for more than 20 years now, and it’s always good to catch up with old friends and meet new folk.

Thanks to Collabora, Codethink, and Andy for sponsoring a bunch of tasty refreshments. And, of course, thanks to Steve for hosting us all.

One of the annoyances I had when I upgraded from Buster to Bullseye (yes, I’m talking about an upgrade I did at the end of 2021) is that I ended up moving from Mailman 2 to Mailman 3. Which is fine, I guess, but it meant I could no longer use listadmin to deal with messages held for moderation. At the time I looked around, couldn’t find anything, shrugged, and became incredibly bad at performing my list moderation duties.

Last week I finally accepted what I should have done at least a year ago and wrote some hopefully not too bad Python to web scrape the Mailman 3 admin interface. It then presents a list of subscribers and held messages that might need approved or discarded. It’s heavily inspired by listadmin, but not a faithful copy (partly because it’s been so long since I used it that I’m no longer familiar with its interface). Despite that I’ve called it listadmin3.

It currently meets the bar of “extremely useful to me” so I’ve tagged v0.1. You can get it on Github. I’d be interested in knowing if it actually works for / is useful to anyone else (I suspect it won’t be happy with interfaces configured to not be in English, but that should be solvable). Comment here or reply to my Fediverse announcement.

Example usage, cribbed directly from the README:

$ listadmin3
fetching data for partypeople@example.org ... 200 messages
(1/200) 5303: omgitsspam@example.org / March 31, 2023, 6:39 a.m.:
  The message is not from a list member: TOP PICK
(a)ccept, (d)iscard, (b)ody, (h)eaders, (s)kip, (q)uit? q
Moving on...
fetching data for admins@example.org ... 1 subscription requests
(1/1) "The New Admin" <newadmin@example.org>
(a)ccept, (d)iscard, (r)eject, (s)kip, (q)uit? a
1 messages
(1/1) 6560: anastyspamer@example.org / Aug. 13, 2023, 3:15 p.m.:
  The message is not from a list member: Buy my stuff!
(a)ccept, (d)iscard, (b)ody, (h)eaders, (s)kip, (q)uit? d
0 to accept, 1 to discard, proceed? (y/n) y
fetching data for announce@example.org ... nothing in queue
$

There’s Debian packaging in the repository (dpkg-buildpackage -uc -us -b will spit you out a .deb) but I’m holding off on filing an ITP + actually uploading until I know if it’s useful enough for others before doing so. You only really need the listadmin3 file and to ensure you have Python3 + MechanicalSoup installed.

(Yes, I still run mailing lists. Hell, I still run a Usenet server.)