Around a decade ago, I was happy to learn about bcache a Linux block cache system that implements tiered storage (like a pool of hard disks with SSDs for cache) on Linux. At that stage, ZFS on Linux was nowhere close to where it is today, so any progress on gaining more ZFS features in general Linux systems was very welcome. These days we care a bit less about tiered storage, since any cost benefit in using anything else than nvme tends to quickly evaporate compared to time you eventually lose on it. In 2015, it was announced that bcache would grow into its own filesystem. This was particularly exciting and it caused quite a buzz in the Linux community, because it brought along with it more features that compare with ZFS (and also btrfs), including built-in compression, built-in encryption, check-summing and RAID implementations. Unlike ZFS, it didn t have a dkms module, so if you wanted to test bcachefs back then, you d have to pull the entire upstream bcachefs kernel source tree and compile it. Not ideal, but for a promise of a new, shiny, full-featured filesystem, it was worth it. In 2019, it seemed that the time has come for bcachefs to be merged into Linux, so I thought that it s about time we have the userspace tools (bcachefs-tools) packaged in Debian. Even if the Debian kernel wouldn t have it yet by the time the bullseye (Debian 11) release happened, it might still have been useful for a future backported kernel or users who roll their own. By total coincidence, the first git snapshot that I got into Debian (version 0.1+git20190829.aa2a42b) was committed exactly 5 years ago today. It was quite easy to package it, since it was written in C and shipped with a makefile that just worked, and it made it past NEW into unstable in 19 January 2020, just as I was about to head off to FOSDEM as the pandemic started, but that s of course a whole other story. Fast-forwarding towards the end of 2023, version 1.2 shipped with some utilities written in Rust, this caused a little delay, since I wasn t at all familiar with Rust packaging yet, so I shipped an update that didn t yet include those utilities, and saw this as an opportunity to learn more about how the Rust eco-system worked and Rust in Debian. So, back in April the Rust dependencies for bcachefs-tools in Debian didn t at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66. I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although I m personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust). With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they can t. Fedora and other distributions with stable releases take a similar approach to what we ve done in Debian, while distributions with much more relaxed policies (like Arch) include all the dependencies as they are vendored upstream. As it stands now, bcachefs-tools is impossible to maintain in Debian stable. While my primary concerns when packaging, are for Debian unstable and the next stable release, I also keep in mind people who have to support these packages long after I stopped caring about them (like Freexian who does LTS support for Debian or Canonical who has long-term Ubuntu support, and probably other organisations that I ve never even heard of yet). And of course, if bcachfs-tools don t have any usable stable releases, it doesn t have any LTS releases either, so anyone who needs to support bcachefs-tools long-term has to carry the support burden on their own, and if they bundle it s dependencies, then those as well. I ll admit that I don t have any solution for fixing this. I suppose if I were upstream I might look into the possibility of at least supporting a larger range of recent dependencies (usually easy enough if you don t hop onto the newest features right away) so that distributions with stable releases only need to concern themselves with providing some minimum recent versions, but even if that could work, the upstream author is 100% against any solution other than vendoring all its dependencies with the utility and insisting that it must only be built using these bundled dependencies. I ve made 6 uploads for this package so far this year, but still I constantly get complaints that it s out of date and that it s ancient. If a piece of software is considered so old that it s useless by the time it s been published for two or three months, then there s no way it can survive even a usual stable release cycle, nevermind any kind of long-term support. With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done. I made an upload to experimental so that it s still available if someone wants to work on it (without having to go through NEW again), it s been removed from unstable so that it doesn t migrate to testing, and the ancient (especially by bcachefs-tools standards) versions that are in stable and oldstable will be removed too, since they are very likely to cause damage with any recent kernel versions that support bcachefs. And so, my adventure with bcachefs-tools comes to an end. I d advise that if you consider using bcachefs for any kind of production use in the near future, you first consider how supportable it is long-term, and whether there s really anyone at all that is succeeding in providing stable support for it.

A few weeks ago Tiziano Bacocco started a small project to implement a (golang) proxy that allows to store proxmox backups on S3 compatible storage: pmoxs3backuproxy, a feature which the current backup server does not have. I wanted to have a look at the Proxmox Backup Server implementation for a while, so i jumped on the wagon and helped with adding most of the API endpoints required to seamlessly use it as drop-in replacement in PVE. The current version can be configured as storage backend in PVE. You can then schedule your backups to the S3 storage likewise. It now supports both the Fixed index format required to create virtual machine backups and the Dynamic index format, used by the regular proxmox-backup-client for file and container backups. (full and incremental) The other endpoints like adding notes, removing or protecting backups, mounting images using the PVE frontend (or proxmox-backup-client) work too. It comes with a garbage collector that does prune the backup storage if snapshots expire and runs integrity checks on the data. You can also configure it as so called remote storage in the Proxmox Backup server itself and pull back complete buckets using proxmox-backup-manager pull , if your local datastore crashes. I think it will become more interesting if future proxmox versions will allow to push backups to other stores, too.

Review: Dark Horse, by Michelle Diener

Series:	Class 5 #1
Publisher:	Eclipse
Copyright:	June 2015
ISBN:	0-9924559-3-6
Format:	Kindle
Pages:	366

Dark Horse is a science fiction romance novel, the first of a five book series as of this writing. It is self-published, although it is sufficiently well-edited and packaged that I had to do some searching to confirm that. Rose was abducted by aliens. The Tecrans picked her up along with a selection of Earth animals, kept her in a cell in their starship, and experimented on her. As the book opens, she has managed to make her escape with the aid of an AI named Sazo who was also imprisoned on the Tecran ship. Sazo dealt with the Tecrans, dropped the ship in the middle of Grih territory, and then got Rose and most of the animals on shuttles to a nearby planet. Dav Jallan is the commander of the ship the Grih sent to investigate the unexplained appearance of a Class 5 Tecran warship in the middle of their territory. The Grih and the Tecran, along with three other species, are members of the United Council, which means in theory they're all at peace. With the Tecran, that theory is often strained. Dav is not going to turn down one of their highly-advanced Class 5 warships delivered to him on a silver platter. There is only the matter of the unexpected cargo, the first orange dots (indicating unknown life forms) that most of the Grih have ever seen. There is a romance. That romance did not work for me. I thought it was highly unprofessional on Dav's part and a bit too obviously constructed on the author's part. It also leans on the subgenre convention that aliens can be remarkably physically similar and sexually compatible, which always causes problems for my suspension of disbelief even though I know it's no less plausible than faster-than-light travel. Despite that, I had so much fun with this book! It was absolutely delightful and weirdly grabby in a way that caught me by surprise. I was skimming some parts of it to write this review and found myself re-reading multiple pages before I dragged myself back on task. I think the most charming part of this book is that the United Council has a law called the Sentient Beings Agreement that makes what the Tecran were doing extremely illegal, and the Grih and the other non-Tecran aliens take this very seriously and with a refreshing lack of cynicism. Rose has a typical human reaction to ending up in a place where she doesn't know the rules and isn't entirely an expected guest. She almost reflexively smoothes over miscommunications and tensions, trying to adapt to their expectations. And then, repeatedly, the Grih realize how much work she's doing to adapt to them, feel enraged at the Tecran and upset that they didn't understand or properly explain something, and find some way to make Rose feel more comfortable. It's surprisingly soothing and comforting to read. It occurred to me in several places that Dark Horse could be read as a wish-fulfillment fantasy of what life as a woman could be like if men took their fair share of the mental load. (This concept is usually applied to housework, but I think it generalizes to other social and communication contexts.) I suspect this was not an accident. There is a lot of wish fulfillment in this book. The Grih are very human-like but hunky, which is convenient for the romance subplot. They struggle to sing, value music exceptionally highly, and consider Rose's speaking voice beautifully musical. Her typical human habit of singing to herself is a source of immediate and almost overwhelming fascination. The supplies Rose takes from the Tecran ship when she flees just happen to be absurdly expensive scented shampoo and equally expensive luxury adaptable clothing. The world she lands on, and the Grih ship, are low-gravity compared to Earth, so Rose is unusually strong for her size. Grih military camouflage has no effect on her human vision. The book is set up to make Rose special. If that type of wish fulfillment is going to grate, wait on this book until you're more in the mood for it. But I like wish fulfillment books when they're done well. Part of why I like to read is to imagine a better world. And Rose isn't doted on; despite their hospitality, she's constantly underestimated by the Grih. Even with their deep belief in the Sentient Beings Agreement, they find it hard to believe that an unknown sentient, even an advanced sentient, is really their equal. Their concern at the start is somewhat patronizing, so watching Rose constantly surprise them delighted the part of my brain that likes both competence porn and deserved reversals, even though the competence here is often due to accidents of biology. It helps that Diener tells the story in alternating perspectives, so the reader first watches Rose do something practical and straightforward from her perspective and then gets to enjoy the profound surprise and chagrin of the aliens. There is a plot beneath this first contact story, and beyond the political problem of figuring out what to do with Rose and the Tecran. Sazo, Rose's AI friend, does not want the Grih to know he exists. He has a history that Rose does not know about and may not be entirely safe. As the political situation with the Tecran escalates, Sazo is pursuing goals of his own, and Rose has a firm opinion about where her loyalties should lie. The resolution is nothing ground-breaking as far as SF goes, but I thought it was satisfyingly tense and complex. Dark Horse leaves obvious room for a sequel, but it comes to a satisfying conclusion. The writing is serviceable, particularly once you get into the story. I would not call it great, and it's not going to win any literary awards, but it didn't interfere with my enjoyment of the story. This is not the sort of book that will make anyone's award list, but it is easily in the top five of books I had the most fun reading this year. Maybe save it for when you're looking for something light and wholesome and don't mind some rather obvious tropes, but if you're in the mood for imagining people who take laws seriously and sincerely try to help other people, I found this an utterly delightful way to pass the time. I immediately bought the sequel. Recommended. Followed by Dark Deeds. Rating: 8 out of 10

GNOME is one of the most widely used free and open-source desktop environments! Your native language is Marathi and you are using GNOME as your desktop environment? Then me as the coordinator for the Marathi translation team in GNOME is excited to invite you to become part of the team who is working on translating the GNOME Desktop into Marathi! By this and contributing to the translation of GNOME into Marathi you would be a member of an important project and you can help to make it more accessible to Marathi speakers worldwide and help also to keep our language alive in the open source world.

Why Should You Contribute?

• Promote Your Language By translating GNOME into Marathi, you help to preserve and promote our beautiful language in the digital world.
• Learn and Grow Contributing to open-source projects like GNOME is a great way to improve your language and technical skills, network with like-minded individuals, and gain recognition in the global open-source community.
• Give Back to the Community This is an opportunity to contribute to a project that has a significant impact on users around the world. Your work will enable Marathi speakers to use technology in their native language.

Who Can Contribute? You don t need to be a professional translator to join us! If you are fluent in Marathi and have a basic understanding of English, your contributions will be invaluable. Whether you re a student, a professional, or just someone passionate about your language, your help is needed and really appreciated!

How To Start Translating? Once you re familiar with the tools, you can easily begin translating. We have a list of untranslated strings waiting for your contribution!

How To Join The Team? Follow these steps to join the Marathi translation team for GNOME and start contributing:

• Step 1: Visit our GNOME Translation Team Page.
• Step 2: If you re a new user, click on the Create Account option to sign up.
• Step 3: Once you ve created your account, log in with your credentials.
• Step 4: After logging in, click the Join button to become a translator for the Marathi team.
• Step 5: You ll now see a list of different modules that need translation. Choose one of the files that interests you and download it to your computer.
• Step 6: Translate the content locally on your computer. Once you re done, return to the website, click Browse, and submit your translated file.

---

Get Familiar with the Additional Tools

Varnam If you re not used to typing in Marathi, you can still contribute using the Varnam website, a free and open-source tool that converts English text into Marathi. Here s how you can get started:

• Step 1: Visit the Varnam website.
• Step 2: Click on the Try Now button on the website.
• Step 3: In the language selection menu, choose Marathi as your desired language.
• Step 4: Now you can start typing in English, and Varnam will automatically convert your text into Marathi. If you need more guidance, there s a help window available on the site that you can explore for additional support.

Need Help Or You Have Questions? If you have any doubts or need further assistance how you get started with translating GNOME into Marathi, don t hesitate to reach out. I m here to help you on every step of the way! You can connect with me directly at kalyaniknkr@gmail.com Whether you need technical support, guidance on using the tools, or just want to discuss the project, feel free to get in touch. Let s work together to make GNOME accessible to Marathi speakers around the world. Your contributions are always invaluable, and I look forward to welcoming you to our team! Thank you for your interest and support!

It's clear that Twitter has been circling the drain for years, but things have been especially bad in recent times. I haven't quit (I have some sympathy with the viewpoint don't cede territory to fascists) but I try to read it much less, and I certainly post much less. Especially at the moment, I really appreciate distractions. Last time I wrote about Mastodon (by which I meant the Fediverse¹), I was looking for a new instance to try. I settled on Debian's social instance². I'm now trying to put any energy I might spend engaging on Twitter, into engaging in the Fediverse instead. (You can follow me via the handle @jon@dow.land, I think, which should repoint to my actual handle, @jmtd@pleroma.debian.social.) There are other potential successors to Twitter: two big ones are Bluesky and Facebook-owned Threads. They are effectively cookie-cutter copies of the Twitter model, and so, we will repeat the same mistakes there. Sadly I see the majority of communities and sub-cultures I follow are migrating to one or the other of these. The Fediverse (or the Mastodon-ish bits of it) should avoid the fate of Twitter. JWZ puts it better and more succinctly than I can. The Fedi experience is, sadly, pretty clunky. So I want to try and write a bit from time to time with tips and tricks that might improve people's experiences. First up, something I discovered only today about Mastodon instances. As JWZ noted, If you are worried about picking the "right" Mastodon instance, don't. Just spin the wheel.. You can spend too much time trying to guess a good answer to this. Better to just get started. At the same time, individual instances are supposed to cater to specific niches. So it could be useful to sample the public posts from an entire instance. For example, to find people to follow, or decide to hop over to that instance yourself. You can't (I think) follow an entire instance from within yours, but, they usually have a public page which shows you the latest traffic. For example, the infosec-themed instance infosec.exchange has one here: https://infosec.exchange/public/local These pages don't provide RSS or Atom feeds³, sadly. I hope that's on the software's roadmap, and hasn't been spurned for ideological reasons. For now at least, OpenRSS provide RSS/Atom feeds for many Mastodon instances. For example, an RSS/Atom feed of the above: https://openrss.org/infosec.exchange/public/local One can add these feeds to your Feed reader and over time get a flavour for the kind of discourse that takes place on given instances. I think the OpenRSS have to manually add Mastodon instances to their service. I tried three instances and only one (infosec.exchange) worked. I'm not sure but I think trying an instance that doesn't work automatically puts it on OpenRSS's backlog.

I am looking into getting a Wifi mesh network. The aim is to use it for providing access to devices through my home especially for devices on the congested 2.4GHz frequency. Ideally I want 6GHz Wifi6E for the communication between mesh nodes as well as for talking to the few devices that are new enough to support it (I like buying cheap second hand devices). 2.5Gbit ethernet connections on all mesh nodes would be good too. Wifi 7 is semi-released, you can buy devices even though the specs aren t entirely finalised. I expect that next year when Wifi 7 devices are more common the second hand prices of Wifi 6E will drop. Currently Wifi 6E devices are somewhat expensive. One major problem at the moment is cloud configuration . Here is a 41 page forum thread of TP-Link customers asking in vain for non-cloud configuration [1]. The problems with cloud configuration are that it doesn t allow configuration without Internet access (so no fixing things when internet breaks and no use for a private network without Internet), it relies on a proprietary phone app (so a problem with your phone breaks everything), and it adds a dependency on an unpaid service that TP-Link might decide to turn off at some future time. The TP -Link Deco X55 AX3000 looks like a good set of devices, it currently costs $328 for a set of three Wifi 6 (not 6E) devices is a good deal, pity that the poor software options let it down. TP-Link also seems to be scanning web traffic and sending the analysis to an external site [2], it seems to be operating as malware. The TP-Link software seems to be most accurately described as malware. There is the OpenWrt project for open firmware on Wifi APs which is a great project [3] but it doesn t seem to support any Wifi 6 mesh systems yet. If most Wifi hardware requires malware for operation it seems that running a VPN over Wifi is the way to go. A hostile party being able to sniff your home network is much worse than a hostile party sniffing public Internet traffic. The Google Nest mesh devices have good specs and price, $359 for a three node Wifi 6E mesh that has 2.5Gbit ethernet. But they can only be configured with a Google app for Android or iOS and require a Gmail account. Giving Google the ability to shut down all my stuff by deleting my gmail account is not acceptable. Also Google is well known for cancelling services [4]. A mitigating factor is that there should be enough of those devices sold to make them a good target for an OpenWRT port. As an aside it looks like the TailScale mesh VPN system could be a solution to the security issues related to malware on Wifi APs problem [5]. There is also HeadScale which is the fully open source variant of that [6]. Even when the vendor isn t overtly hostile they can make mistakes so encryption is good. Kogan is selling an own-brand Wifi 6 mesh network package that comes with 1/2/3 devices for $70/$120/$140. It doesn t do Wifi 6E but supports the better encoding methods of Wifi 6 over Wifi 5 and will be good for bridging a LAN in one part of a house to a Wifi 2.4GHz or Ethernet connected device in another part. They also support up to 7 nodes so you could buy two of the 3 device packages and run one network with 2 and another with 4. The pricing is very competitive and they support web based administration! I ve just ordered the $140 Wifi 6 pack from Kogan. If it doesn t do what I want then I can find someone else who will be happy with whatever functionality it gives and $140 is an amount I can risk without concern. If it works well then I might upgrade to Wifi 6E or Wifi 7 next year and deploy the Wifi 6 one for a relative. It seems that for my needs a cheap and OK Wifi 6 device is better than an expensive Wifi 6E device.

• [1] https://community.tp-link.com/en/home/forum/topic/531350
• [2] https://tinyurl.com/y84skkdp
• [3] https://openwrt.org/supported_devices
• [4] https://killedbygoogle.com/
• [5] https://en.wikipedia.org/wiki/Tailscale
• [6] https://headscale.net/

With news like this one cited by Bruce Schneier [1] people are asking whether it s worth using Secure Boot. Regarding the specific news article, this is always a risk with distributed public key encryption systems. Lose control of one private key and attackers can do bad things. That doesn t make it bad it just makes it less valuable. If you want to setup a system for a government agency, bank, or other high value target then it s quite reasonable to expect an adversary to purchase systems of the same make and model to verify that their attacks will work. If you want to make your home PC a little harder to attack then you can expect that the likely adversaries won t bother with such things. You don t need security to be perfect, making a particular attack slightly more difficult than other potential attacks gives a large part of the benefit. The purpose of Secure Boot is to verify the boot loader with a public key signature and then have the boot loader verify the kernel. Microsoft signs the shim that is used by each Linux distribution to load GRUB (or another boot loader). So when I configure a Debian system with Secure Boot enabled that doesn t stop anyone from booting Ubuntu. From the signatures on the boot loader etc there is no difference from my Debian installation and a rescue image from Debian, Ubuntu, or another distribution booted by a hostile party to do things against my interests. The difference between the legitimate OS image and malware is a matter of who boots it and the reason for booting it. It is possible to deconfigure Microsoft keys from UEFI to only boot from your own key, this document describes what is necessary to do that [2]. Basically if you boot without using any option ROMs (which among other things means the ROM from your video card) then you can disable the MS keys. If it s impossible to disable the MS keys that doesn t make it impossible to gain a benefit from the Secure Boot process. You can use a block device decryption process that involves a signature of the kernel and the BIOS being used as part of the decryption for the device. So if a system is booted with the wrong kernel and the user doesn t recognise it then they will find that they can t unlock the device with the password. I think it s possible on some systems to run the Secure Boot functionality in a non-enforcing mode such that it will use a bootloader without a valid signature but still use the hash for TPM calculations, that appears impossible on my Thinkpad Yoga Gen3 which only has enabled and disabled as options but should work on Dell laptops which have an option to run Secure Boot in permissive mode. I believe that the way of the future is to use something like EFIStub [3] to create unified kernel images with a signed kernel, initrd, and command-line parameters in a single bundle which can be loaded directly by the UEFI BIOS. From the perspective of a distribution developer it s good to have many people using the current standard functionality of shim and GRUB for EFI as a step towards that goal. CloudFlare has a good blog post about Linux kernel hardening [4]. In that post they cover the benefits of a full secure boot setup (which is difficult at the current time) and the way that secure boot enables the lockdown module for kernel integrity. When Secure Boot is detected by the kernel it automatically enables lockdown=integrity functionality (see this blog post for an explanation of lockdown [5]). It is possible to enable this by putting lockdown=integrity on the kernel command line or lockdown=confidentiality if you want even more protection, but it happens by default with Secure Boot. Secure Boot is something you can set to get a selection of security features enabled and get a known minimum level of integrity even if the signatures aren t used for anything useful, restricting a system to only boot kernels from MS, Debian, Ubuntu, Red Hat, etc is not useful. For most users I think that Secure Boot is a small increase in security but testing it on a large number of systems allows increasing the overall security of operating systems which benefits the world. Also I think that having features like EFIStub usable for a large portion of the users (possibly the majority of users) is something that can be expected to happen in the lifetime of hardware being purchased now. So ensuring that Secure Boot works with GRUB now will facilitate using EFIStub etc in future years. The Secure Boot page on the Debian wiki is worth reading, and also worth updating for people who want to contribute [6].

• [1] https://tinyurl.com/264thnky
• [2] https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
• [3] https://wiki.debian.org/EFIStub
• [4] https://blog.cloudflare.com/de-de/linux-kernel-hardening
• [5] https://mjg59.dreamwidth.org/55105.html
• [6] https://wiki.debian.org/SecureBoot

During Debconf, Edward Betts and myself started packaging Home Assistant for Debian. It consists of hundreds of Python packages. So far, we counted at least 675 packages. That s a lot, though most packages are just libraries to talk with some IoT devices and some APIs. It s fairly easy to create a new package: it takes me about 15 to 20 minutes, probably half that time to Edward. And it s a lot of fun. So far in one month of time, we managed to package about 1 third of the list (probably 200+ Python packages already). Once we ve done all the dependencies, we may start to have fun with the core of the application! At the current speed, hopefully we ll be done before the end of the year. Edward and myself have swear to make at least one package a day, which I ve been doing so far, and Edward did a way more We also received contributions from Silton0506, Tianyu, piotr, EiPi Fun, sourabhtk37, and Count-Dracula, as per the very bottom of the TODO list in the wiki (see link below). If you have a bit of free time, we d love to have more contributors. Here s were to get the needed information: We created a team in Salsa: https://salsa.debian.org/homeassistant-team/ Our TODO list: https://wiki.debian.org/Python/HomeAssistant Our DDPO Q/A page: https://qa.debian.org/developer.php?login=team%2Bhomeassistant%40tracker.debian.org Feel free to join us on IRC: #debian-homeassistant Discussing with a lot of people about it, I realized that A LOT of DDs are actually using Home Assistant. Wouldn t you like it better if it was just a apt install away ? Any DD can simply take a package in the wiki, open an ITP, upload it s debianized source on Salsa, and upload to the Debian archive. Most are very easy simple packages to make.

Diego wrote about his dislike for Advent of Code and that reminded me I hadn t written up my experience from 2023. Mostly because, spoiler, I never actually completed it and always intended to do so and then write it up. I think it s time to accept I m not going to do that, and write down some thoughts before I forget all of them. These are somewhat vague, given the time that s elapsed, but I think still relevant. You might also find Roger s problem write up interesting. I ve tried AoC a couple of times before; I think I had a very brief attempt back in 2021, and I got 4 days in for 2022. For Advent of Code 2023 I tried much harder to actually complete the challenges, and got most of the way there. I didn t allow myself to move on to the next day until fully completing the previous day, and didn t end up doing the second half of December 24th, or any of December 25th.

Rust First I want to talk about Rust, which is the language I chose to use for the problems. I ve dabbled a little in it, but I d like more familiarity with the basic language, and some programming problems seemed like a good way to get that. It s a language I want to like; I ve spent a lot of my career writing C, do more in Go these days, and generally think Rust promises a low level, run-time light environment like C but with the rough edges taken off. I set myself the challenge of using just bare Rust; no external crates, no use of cargo. I was accused of playing on hard mode by doing this, but it really wasn t the intention - I figured that I should be able to do what I needed without recourse to anything outside the core language, and didn t want what seemed like the extra complexity of dealing with cargo. That caused problems, however. I m used to by-default generic error handling in Go through the error type, but Rust seems to have much more tightly typed errors. I was pointed at anyhow as the right way to do this in Rust. I still find this surprising; I ended up using unwrap() a lot when I think with more generic error handling I could have used ?. The other thing I discovered is that by default rustc is heavy on the debug output. I got significantly better results on some of the solutions with rustc -O -C target-cpu=native source.rs. I probably shouldn t be surprised by this, but worth noting. Rust, to me, has a syntax only a C++ programmer could love. I am not a C++ programmer. Coming from C I found Go to be a nice, simple syntax to learn. Rust has not been the same. There s a lot more punctuation, and it s not always clear to me what it s doing. This applies more when reading other people s code than when writing it myself, obviously, but I see a lot of Rust code that could give Perl a run for its money in terms of looking like line noise. The borrow checker didn t bug me too much, but did add overhead to my thinking. The Rust compiler is generally very good at outputting helpful error messages when the programmer is an idiot. I ended up having to use a RefCell for one solution, and using .iter() for loops rather than explicit iterators (why, why is this different?). I also kept forgetting to explicitly mark variables as mutable when declaring them. Things I liked? There s a rich set of first class data types. Look, I m a C programmer, I m easily pleased. You give me some sort of hash array and I ll be happy. Rust manages that, tuples, strings, all the standard bits any modern language can provide. The whole impl thing for adding methods to structures I like as a way of providing some abstraction, though I think Go has a nicer syntax for it. The compiler, as mentioned, is great at spitting out useful errors for the most part. Also although I wasn t using external crates for AoC I do appreciate there s a decent ecosystem there now (though that brings up another gripe: rust seems to still be a fairly fast moving target, to the extent I can no longer rely on the compiler in Debian stable to be able to compile random projects I find).

Advent of Code Let s talk about the advent of code bit now. Hopefully it s long enough since it came out that this won t be spoilers for anyone, but if you haven t attempted the 2023 AoC and might, you might want to stop reading here. First, a refresher on the format for those who might not be aware of it. Problems are posted daily from December 1st until the 25th. Each is in 2 parts; the second part is not viewable until you have provided the correct answer for the first part. There s a whole leaderboard thing going on, but the puzzle opens at midnight UTC-5 so generally by the time I wake up and have time to look the problem has been solved many times over; no chance of getting listed. Credit to AoC creator, Eric Wastl, for writing up the set of problems in an entertaining fashion. I quite enjoyed seeing how the puzzle would be phrased each day, and the whole thing obviously brings a lot of joy to folk I know. I always start AoC thinking it ll be a fun set of puzzles to solve. Then something happens and I miss a day or two, and all of a sudden I ve a bunch of catching up to do and it s all a bit more of a chore. I hit that at some points this time, but made a concerted effort to try and power through it. That perseverance was required up front, because I found the second part of Day 1 to be ill specified, and had to iterate a few times to actually calculate the desired solution (IIRC, issues about whether sevenone at the end of a line ended up as 7 or 1 really tripped me up). I don t recall any other problems that bit me as hard on the specification as this one, but it happening up front was unfortunate. The short example input doesn t always help with this either; either it s not enough to be able to extrapolate patterns, or it doesn t show all the variations you need to account for (that aren t fully specified in the text), or in a few cases it turned out I needed to understand the shape of the actual data to produce a solution that could actually complete in a reasonable time. Which brings me to another matter, sometimes brute force doesn t actually work. This is fine, but the second part of the day s problem can change the approach you d take. So sometimes I got lucky in the way I handled the first half, and doing the second half was a simple 5 minute tweak, and sometimes I had to entirely change the way I was storing data. You might claim that if I was a better programmer I d have always produced a first half solution that was amenable to extension for the second half. First, I dispute that; I think there are always situations where the problem domain can change in enough directions that you can t handle all of them without a lot of effort. Secondly, I didn t find AoC an environment that encouraged me to optimise for generic solutions. Maybe some of the puzzles in isolation would allow for that, but a month of daily problems to solve while still engaging in regular life meant I hacked things up, took short cuts based on the knowledge I had of the input data, etc, etc. Overall I can see the appeal, but the sheer quantity and the fact I write code as part of my day job just made it feel too much like a chore, rather than a fun mental exercise. I did wonder how they d look as a set of interview puzzles (obviously a subset, rather than all of them), but I m not sure how you d actually use them for that - I wouldn t want anyone to have to solve them in a live interview. So, in case it s not obvious, I m not planning to engage in AoC again this yet. But I m continuing to persevere with Rust (though most of my work stuff is thankfully still Go).

Short version: Secure Boot Advanced Targeting and if that's enough for you you can skip the rest you're welcome.

Long version: When UEFI Secure Boot was specified, everyone involved was, well, a touch naive. The basic security model of Secure Boot is that all the code that ends up running in a kernel-level privileged environment should be validated before execution - the firmware verifies the bootloader, the bootloader verifies the kernel, the kernel verifies any additional runtime loaded kernel code, and now we have a trusted environment to impose any other security policy we want. Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash even if it's signed with a trusted key.

Unfortunately, as it turns out, scale. Every Linux distribution that works in the Secure Boot ecosystem generates their own bootloader binaries, and each of them has a different hash. If there's a vulnerability identified in the source code for said bootloader, there's a large number of different binaries that need to be revoked. And, well, the storage available to store the variable containing all these hashes is limited. There's simply not enough space to add a new set of hashes every time it turns out that grub (a bootloader initially written for a simpler time when there was no boot security and which has several separate image parsers and also a font parser and look you know where this is going) has another mechanism for a hostile actor to cause it to execute arbitrary code, so another solution was needed.

And that solution is SBAT. The general concept behind SBAT is pretty straightforward. Every important component in the boot chain declares a security generation that's incorporated into the signed binary. When a vulnerability is identified and fixed, that generation is incremented. An update can then be pushed that defines a minimum generation - boot components will look at the next item in the chain, compare its name and generation number to the ones stored in a firmware variable, and decide whether or not to execute it based on that. Instead of having to revoke a large number of individual hashes, it becomes possible to push one update that simply says "Any version of grub with a security generation below this number is considered untrustworthy".

So why is this suddenly relevant? SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we've seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.

(An aside: the "Something has gone seriously wrong" message that's associated with people having a bad time as a result of this update? That's a message from shim, not any Microsoft code. Shim pays attention to SBAT updates in order to avoid violating the security assumptions made by other bootloaders on the system, so even though it was Microsoft that pushed the SBAT update, it's the Linux bootloader that refuses to run old versions of grub as a result. This is absolutely working as intended)

The problem we've ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it's worth noting that grub is signed by individual distributions, not Microsoft, so there's no externally introduced lag here). Microsoft's stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn't work as intended and at least some dual-boot setups applied the update and that distribution's Shim refused to boot that distribution's grub.

What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems. The distribution-provided Shim first-stage bootloader read this variable, read the SBAT section from the installed copy of grub, realised these conflicted, and refused to boot grub with the "Something has gone seriously wrong" message. This update was not supposed to apply to dual-boot systems, but did anyway. Basically:

1) Microsoft applied an update to systems where that update shouldn't have been applied
2) Some Linux distros failed to update their grub code and SBAT security generation when exploitable security vulnerabilities were identified in grub

The outcome is that some people can't boot their systems. I think there's plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they're updating those and updating the security generation to match, because otherwise they're shipping a vector that can be used to attack other operating systems and that's kind of a violation of the social contract around all of this.

It's unfortunate that the victims here are largely end users faced with a system that suddenly refuses to boot the OS they want to boot. That should never happen. I don't think asking arbitrary end users whether they want secure boot updates is likely to result in good outcomes, and while I vaguely tend towards UEFI Secure Boot not being something that benefits most end users it's also a thing you really don't want to discover you want after the fact so I have sympathy for it being default on, so I do sympathise with Microsoft's choices here, other than the failed attempt to avoid the update on dual boot systems.

Anyway. I was extremely involved in the implementation of this for Linux back in 2012 and wrote the first prototype of Shim (which is now a massively better bootloader maintained by a wider set of people and that I haven't touched in years), so if you want to blame an individual please do feel free to blame me. This is something that shouldn't have happened, and unless you're either Microsoft or a Linux distribution it's not your fault. I'm sorry.

comments

Review: These Burning Stars, by Bethany Jacobs

Series:	Kindom Trilogy #1
Publisher:	Orbit
Copyright:	October 2023
ISBN:	0-316-46342-6
Format:	Kindle
Pages:	430

These Burning Stars is a science fiction thriller with cyberpunk vibes. It is Bethany Jacobs's first novel and the first of an expected trilogy, and won the 2024 Philip K. Dick Award for the best SF paperback original published in the US. Generation starships brought humanity to the three star systems of the Treble, where they've built a new and thriving culture of billions. The Treble is ruled by the Kindom, a tripartite government structure built around the worship of six gods and the aristocratic power of the First Families. The Clerisy handle religion, the Secretaries run the bureaucracy, and the Cloaksaan enforce the decisions of the other branches. The Nightfoots are one of the First Families. They control sevite, the propellant required to move between the systems of the Treble now that the moon Jeve and the sole source of natural jevite has been destroyed. Esek Nightfoot is a cleric, theoretically following the rules of the Clerisy, but she has made a career of training cloaksaan. She is is mercurial, powerful, ruthless, ambitious, politically well-connected, and greatly feared. She is also obsessed with a person named Six: an orphan she first encountered at a training school who was too young to have a gender or a name but who was already one of the best fighters in the school. In the sort of manipulative challenge typical of Esek, she dangled the offer of a place as a student and challenged the child to learn enough to do something impressive. The subsequent twenty years of elusive taunts and mysterious gifts from the impossible-to-locate Six have driven Esek wild. Cleric Chono was beside Esek for much of that time. One of Six's classmates and another of Esek's rescues, Chono is the rare student who became a cleric rather than a cloaksaan. She is pious, cautious, and careful, the opposite of Esek's mercurial rage, but it's impossible to spend that much time around the woman and not be affected and manipulated by her. As this story opens, Chono is summoned by the First Cleric to join Esek on an assignment: recover a data coin that was stolen from a pirate raid on the Nightfoot compound. He refuses to tell them what data is on it, only saying that he believes it could be used to undermine public trust in the Nightfoot family. Jun is a hacker with considerably fewer connections to power or government and no desire to meet any of these people. She and her partner Liis make a dubiously legal living from smaller, quieter jobs. Buying a collection of stolen data coins for an archivist consortium is riskier than she prefers, but she's been tracking down rumors of this coin for months. The deal is worth a lot of money, enough to make a huge difference for her family. This is the second book I've read recently with strong cyberpunk vibes, although These Burning Stars mixes them with political thriller. This is a messy world with complicated political and religious systems, a lot of contentious history, and vast inequality. The story is told in two interleaved time sequences: the present-day fight over the data coin and the information that it contains, and a sequence of flashbacks telling the history of Esek's relationship with Six and Chono. Jun's story is the most cyberpunk and the one I found the most enjoyable to read, but Chono is a good viewpoint character for Esek's vicious energy and abusive charisma. Six is not a viewpoint character. For most of the book, they're present mostly in shadows, glimpses, and consequences, but they're the strongest character of the book. Both Esek and Six are larger than life, creatures of legend stuffed into mundane politics but too full of strong emotions, both good and bad, to play by any of the rules. Esek has the power base and access to the levers of government, but Six's quiet competence and mercilessly targeted morality may make them the more dangerous of the pair. I found the twisty political thriller part of this book engrossing and very difficult to put down, but it was also a bit too much drama for me in places. Jacobs has some surprises in store, one of which I did not expect at all, and they're set up beautifully and well-done within the story, but Esek and Six become an emotional star that the other characters orbit around and are in danger of getting pulled into. Chono is an accomplished and powerful character in her own right, but she's also an abuse victim, and while those parts are realistic, I didn't entirely enjoy reading them. There is quiet competence here alongside the drama, but I think I wanted the balance of emotion to tip a bit more towards the competence. There is one thing that Jacobs does with the end of the book that greatly impressed me. Unfortunately I can't even hint at it for fear of spoilers, but the ending is unsettling in a way that I found surprising and thought-provoking. I think what I can say is that this book respects the intelligence and skill of secondary characters in a way that I think is rare in a story with such overwhelming protagonists. I'm still thinking about that, and it's going to pull me right into the sequel. This is not going to be to everyone's taste. Esek is a viewpoint character and she can be very nasty. There's a lot of violence and abuse, including one rather graphic fight scene that I thought dragged on much longer than it needed to. But it's a satisfying, complex story with a true variety of characters and some real surprises. I'm glad I read it. Followed by On Vicious Worlds, not yet published as I write this. Content warnings: emotional and physical abuse, graphic violence, off-screen rape and sexual abuse of minors. Rating: 7 out of 10

por Andrew Gon alves O Debian Day em Santa Maria - RS 2024 foi realizado ap s 5 anos de hiato, foi feito durante a manh do dia 16/08/2024 no Sal o Azul da Universidade Franciscana (UFN) com apoio da comunidade Debian e do Laborat rio de Pr ticas da Computa o da UFN. O evento contou com alunos de todos os semestres dos cursos de Ci ncia da Computa o, Jogos Digitais e Sistemas de Informa o, fizemos um coffee break onde tivemos a oportunidade de conversar com os participantes. Cerca de 60 alunos prestigiaram uma palestra de introdu o ao Software Livre e de C digo Aberto, Linux e foram introduzidos ao projeto Debian, tanto sobre a filosofia do projeto, at como ele acontece na pr tica e oportunidades que se abriram para participantes do projeto por fazerem parte do Debian. Ap s a palestra foi feita uma demonstra o de empacotamento pelo DD local Francisco Vilmar, que demonstrou na pr tica como funciona o empacotamento de software no Debian. Gostaria de agradecer a todas as pessoas que nos ajudaram:

• Projeto Debian
• Professora Ana Paula Canal (UFN)
• Professor Sylvio Andr Garcia
• Laborat rio de Pr ticas da Computa o
• Francisco Vilmar (DD local)

E um muito obrigado a todos os participantes que nos prestigiaram neste evento fazendo perguntas intrigantes e se interessando pelo mundo do Software Livre. Algumas fotos:

(The issues described in this post have been fixed, I have not exhaustively researched whether any other issues exist)

Feeld is a dating app aimed largely at alternative relationship communities (think "classier Fetlife" for the most part), so unsurprisingly it's fairly popular in San Francisco. Their website makes the claim:

Can people see what or who I'm looking for?
No. You're the only person who can see which genders or sexualities you're looking for. Your curiosity and privacy are always protected.

which is based on you being able to restrict searches to people of specific genders, sexualities, or relationship situations. This sort of claim is one of those things that just sits in the back of my head worrying me, so I checked it out.

First step was to grab a copy of the Android APK (there are multiple sites that scrape them from the Play Store) and run it through apk-mitm - Android apps by default don't trust any additional certificates in the device certificate store, and also frequently implement certificate pinning. apk-mitm pulls apart the apk, looks for known http libraries, disables pinning, and sets the appropriate manifest options for the app to trust additional certificates. Then I set up mitmproxy, installed the cert on a test phone, and installed the app. Now I was ready to start.

What became immediately clear was that the app was using graphql to query. What was a little more surprising is that it appears to have been implemented such that there's no server state - when browsing profiles, the client requests a batch of profiles along with a list of profiles that the client has already seen. This has the advantage that the server doesn't need to keep track of a session, but also means that queries just keep getting larger and larger the more you swipe. I'm not a web developer, I have absolutely no idea what the tradeoffs are here, so I point this out as a point of interest rather than anything else.

Anyway. For people unfamiliar with graphql, it's basically a way to query a database and define the set of fields you want returned. Let's take the example of requesting a user's profile. You'd provide the profile ID in question, and request their bio, age, rough distance, status, photos, and other bits of data that the client should show. So far so good. But what happens if we request other data?

graphql supports introspection to request a copy of the database schema, but this feature is optional and was disabled in this case. Could I find this data anywhere else? Pulling apart the apk revealed that it's a React Native app, so effectively a framework for allowing writing of native apps in Javascript. Sometimes you'll be lucky and find the actual Javascript source there, but these days it's more common to find Hermes blobs. Fortunately hermes-dec exists and does a decent job of recovering something that approximates the original input, and from this I was able to find various lists of database fields.

So, remember that original FAQ statement, that your desires would never be shown to anyone else? One of the fields mentioned in the app was "lookingFor", a field that wasn't present in the default profile query. What happens if we perform the incredibly complicated hack of exporting a profile query as a curl statement, add "lookingFor" into the set of requested fields, and run it?

Oops.

So, point 1 is that you can't simply protect data by having your client not ask for it - private data must never be released. But there was a whole separate class of issue that was an even more obvious issue.

Looking more closely at the profile data returned, I noticed that there were fields there that weren't being displayed in the UI. Those included things like "ageRange", the range of ages that the profile owner was interested in, and also whether the profile owner had already "liked" or "disliked" your profile (which means a bunch of the profiles you see may already have turned you down, but the app simply didn't show that). This isn't ideal, but what was more concerning was that profiles that were flagged as hidden were still being sent to the app and then just not displayed to the user. Another example of this is that the app supports associating your profile with profiles belonging to partners - if one of those profiles was then hidden, the app would stop showing the partnership, but was still providing the profile ID in the query response and querying that ID would still show the hidden profile contents.

Reporting this was inconvenient. There was no security contact listed on the website or in the app. I ended up finding Feeld's head of trust and safety on Linkedin, paying for a month of Linkedin Pro, and messaging them that way. I was then directed towards a HackerOne program with a link to terms and conditions that 404ed, and it took a while to convince them I was uninterested in signing up to a program without explicit terms and conditions. Finally I was just asked to email security@, and successfully got in touch. I heard nothing back, but after prompting was told that the issues were fixed - I then looked some more, found another example of the same sort of issue, and eventually that was fixed as well. I've now been informed that work has been done to ensure that this entire class of issue has been dealt with, but I haven't done any significant amount of work to ensure that that's the case.

You can't trust clients. You can't give them information and assume they'll never show it to anyone. You can't put private data in a database with no additional acls and just rely on nobody ever asking for it. You also can't find a single instance of this sort of issue and fix it without verifying that there aren't other examples of the same class. I'm glad that Feeld engaged with me earnestly and fixed these issues, and I really do hope that this has altered their development model such that it's not something that comes up again in future.

(Edit to add: as far as I can tell, pictures tagged as "private" which are only supposed to be visible if there's a match were appropriately protected, and while there is a "location" field that contains latitude and longitude this appears to only return 0 rather than leaking precise location. I also saw no evidence that email addresses, real names, or any billing data was leaked in any way)

comments

For many years, I have been using the dlvr.it service to echo my online activity to where more people can follow it. Namely, I write in the following sources:

• My blog (where this content is being posted to) RSS
• Mostly academic publications I send to my university s repository (including conference presentations and the like) RSS
• Videos posted to my YouTube channel (mostly my classes but some other material as well) RSS

Via dlvr.it s services, all those posts are echoed to Gwolfwolf in X (Twitter) and to the Gunnarwolfi page in Facebook. I use neither platform as a human (that is, I never log in there). Anyway, dlvr.it sent me a mail stating they would be soon (as in, the next few weeks) cutting their free tier. And, although I value their services and am thankfulfor their value so far, I am not going to pay for my personal stuff to be reposted to social media. So, this post s mission is twofold:

1. If you follow me via any of those media, you will soon not be following me anymore
2. If you know of any service that would fill the space left by dlvr.it, I will be very grateful. Extra gratefulness points if the option you suggest is able to post to accounts in less-propietary media (i.e. the Fediverse). Please tell me by mail (gwolf@gwolf.org).

Oh! Forgot to mention: Of course, my blog will continue to be appear in Planet Debian, Blograf a, and any decent aggregator that consumes my RSS.

por Thiago Pezzo e Giovani Ferreira As celebra es locais do Dia do Debian 2024 tamb m aconteceram em Pouso Alegre, MG, Brasil. Neste ano conseguimos organizar dois dias de palestras! No dia 14 de agosto de 2024, quarta-feira pela manh , estivemos no campus Pouso Alegre do Instituto Federal de Educa o, Ci ncia e Tecnologia do Sul de Minas Gerais (IFSULDEMINAS). Fizemos a apresenta o introdut ria do Projeto Debian, sistema operacional e comunidade, para os tr s anos do Curso T cnico de Ensino M dio em Inform tica. O evento foi fechado para o IFSULDEMINAS e estiveram presentes por volta de 60 estudantes. J no dia 17 de agosto de 2024, um s bado pela manh , realizamos o evento aberto comunidade na Universidade do Vale do Sapuca (Univ s), com apoio institucional do Curso de Sistemas de Informa o. Falamos sobre o Projeto Debian com Giovani Ferreira (Debian Developer); sobre a equipe de tradu o Debian pt_BR com Thiago Pezzo; sobre experi ncias no dia a dia com uso de softwares livres com Virg nia Cardoso; e sobre como configurar um ambiente de desenvolvimento pronto para produ o usando Debian e Docker com Marcos Ant nio dos Santos. Encerradas as palestras, foram servidos salgadinhos, caf e bolo, enquanto os/as participantes conversavam, tiravam d vidas e partilhavam experi ncias. Gostar amos de agradecer a todas as pessoas que nos ajudaram:

• Michelle Nery (IFSULDEMINAS) e Andr Martins (UNIV S) pelo aux lio na organiza o local
• Paulo Santana (Debian Brasil) pela organiza o geral
• Virg nia Cardoso, Giovani Ferreira, Marco Ant nio e Thiago Pezzo pelas palestras
• E um agradecimento especial a todas e todos que participaram da nossa comemora o!

Algumas fotos:

So a common theme on the Internet about Debian is so old. And right, I am getting close to the stage that I feel a little laggy: I am using a bunch of backports for packages I need, and I'm missing a bunch of other packages that just landed in unstable and didn't make it to backports for various reasons. I disagree that "old" is a bad thing: we definitely run Debian stable on a fleet of about 100 servers and can barely keep up, I would make it older. And "old" is a good thing: (port) wine and (any) beer needs time to age properly, and so do humans, although some humans never seem to grow old enough to find wisdom. But at this point, on my laptop, I am feeling like I'm missing out. This page, therefore, is an evolving document that is a twist on the classic NewIn game. Last time I played seems to be #newinwheezy (2013!), so really, I'm due for an update. (To be fair to myself, I do keep tabs on upgrades quite well at home and work, which do have their share of "new in", just after the fact.)

New packages to explore Those tools are shiny new things available in unstable or perhaps Trixie (testing) already that I am not using yet, but I find interesting enough to list here.

• backdown: clever file deduplicator
• codesearch: search all of Debian's source code (tens of thousands of packages) from the commandline! (see also dcs-cli, not in Debian)
• dasel: JSON/YML/XML/CSV parser, similar to jq, but different syntax, not sure I'd grow into it, but often need to parse YML like JSON and failing
• fyi: notify-send replacement
• git-subrepo: git-submodule replacement I am considering
• gtklock: swaylock replacement with bells and whistles, particularly interested in showing time, battery and so on
• hyprland: possible Sway replacement, but there are rumors of a toxic community (rebuttal, I haven't reviewed either in detail), so approach carefully)
• kooha: simple screen recorder with audio support, currently using wf-recorder which is a more.. minimalist option
• linescroll: rate graphs on live logs, mostly useful on servers though
• ruff: faster Python formatter and linter, flake8/black/isort replacement, alas not mypy/LSP unfortunately, designed to be ran alongside such a tool, which is not possible in Emacs eglot right now, but is possible in lsp-mode
• sfwbar: pretty status bar, may replace waybar, which i am somewhat unhappy with (my UTC clock disappears randomly)
• spytrap-adb: cool spy gear

New packages I won't use Those are packages that I have tested because I found them interesting, but ended up not using, but I think people could find interesting anyways.

• kew: surprisingly fast music player, parsed my entire library (which is huge) instantaneously and just started playing (I still use Supersonic, for which I maintain a flatpak on my Navidrome server)
• mdformat: good markdown formatter, think black or gofmt but for markdown), but it didn't actually do what I needed, and it's not quite as opinionated as it should (or could) be)

Backports already in use Those are packages I already use regularly, which have backports or that can just be installed from unstable:

• asn: IP address forensics
• markdownlint: markdown linter, I use that a lot
• poweralertd: pops up "your battery is almost empty" messages
• sway-notification-center: used as part of my status bar, yet another status bar basically, a little noisy, stuck in a libc dep update
• tailspin: used to color logs

Out of date packages Those are packages that are in Debian stable (Bookworm) already, but that are somewhat lacking and could benefit from an upgrade.

• firmware-iwlwifi: out of date, can install from unstable
• fuzzel / foot: log level noises A, B, fuzzel fix not in debian yet, and if we get to 1.11, my scripts in ~/bin should be patched to use --cache
• nomacs: non-trivial backport, out of date version in sid
• pandoc: 3.0 is ridiculously huge, but particularly remove spaces after list marker
• podman: better systemd integration
• pubpaste: out of date, can install from unstable
• tremotesf: out of date backport
• undertime: out of date, can install from unstable
• yt-dlp: out of date, can install from unstable

Last words If you know of cool things I'm missing out of, then by all means let me know! That said, overall, this is a pretty short list! I have most of what I need in stable right now, and if I wasn't a Debian developer, I don't think I'd be doing the jump now. But considering how easier it is to develop Debian (and how important it is to test the next release!), I'll probably upgrade soon. Previously, I was running Debian testing (which why the slug on that article is why-trixie), but now I'm actually considering just running unstable on my laptop directly anyways. It's been a long time since we had any significant instability there, and I can typically deal with whatever happens, except maybe when I'm traveling, and then it's easy to prepare for that (just pin testing).

Electric Car A while ago I got my hands on an electric car - after not having owned a car for most of my life (there really is not much need here). It wasn t planned nor a goal of mine, but it kind of came out of talks with my boss , so now it s there. Due to some special rules in the german tax system it turns out really cheap for me - it comes from the company, which allows personal use. So I have to pay taxes on the value of it plus whichever amount of kilometers I have to drive to work. And the latter is what is good for me - I have homeoffice in my contract, so no drive to work, except maybe once a year for something. So no regular trip to calculate, only if I ever really have to do a trip to the office. And it being an electric car, running costs are also cheap. Way below the outdated tech that needs gas to run, is annoyingly loud and stinks.

The car In the past I used either car sharing or renting a car when I needed one, depending on what I actually needed. Last times renting I already tried electric variants, so I could compare this with. What I have now is a Citroen e-Berlingo XL from 2023 (so not the latest change from 2024), which is on the huge size for space, but small for battery. It has 7 seats (though I have the last 2 currently taken out, no daily need) and more storage space than I need even on a vacation trip. The engine (or well, it s battery) is on the small side - a capacity of 50 kWh means it only has 278km reach according to WLTP. That actually is a good bit less - as usual, those numbers are lying for the producer. Turns out that on highways in a more realistic mode than WLTP (read: real driving) it s somewhat around 120km before one wants a charger again. But, looking around, at least in Germany that is not a big problem, there are more than enough chargers available.

Driving Actually driving experience is good. It sure is a huge car (4.7m long, 1.85m high/wide) and feels more like driving a (small) bus, but it is easy to handle. Maximum speed is limited (or the small battery would suck even more) to 135km/h, but that is more than enough. Even on german highways. Did my vacation trip with cruise control set to 115km/h and very few times only went above that manually. Real relaxed driving that was.

Vacation trip So we had a vacation just recently, and instead of renting a car for the trip we, of course, wanted to take the e-Berlingo. Distance was about double what the car can (realistically!) do, so one charging stop in the middle somewhere was a must. Not having had to charge on highways yet - and entirely new with this car - that made for a bit of nervousness, but it all turned out really good. There are really nice tools like ABRP to plan your trip including charging, which can take live data of availability of charging points into the planning. And it turned out nice - we reached our planned charging point and found a long queue of cars waiting. But turns out it was all those poor folks that need actual gasoline for their outdated combustion engines. The charging points for EV cars still had enough free space, so we could bypass the queue and directly start charging. We also did not need to repark the car after just a few minutes, we could directly start our break. With a charging time of approx. 30 minutes using the fast charger, such a break is long enough to get enough energy for the next part of the trip and short enough to not be annoying.

Charging prices At home it depends. If one has some photovoltaic system to get power, charging is basically free. If not it depends on whichever contract one has, costs will be somewhat between 0 and ~30cent per kWh. Not much, and way below gasoline costs. Outside, using a fast charger, prices vary depending on where you charge - and with what charging card. Prices between 40 and 70cent / kWh, and the same charging point can vary, just from the card one uses. That is a thing that the EU could actually go and better regulate, similar to the phone regulations it took. Still, the costs are still way below gasoline.

Charging cards There is a huge amount of different providers available, and all do their own things in pricing and how one can use them. They do have standards (say, the plugs are standardized, by now the way to start charging also), and that enables roaming (use a charging card of one provider at a charging point of another), but other than that, it seems to be random. That is - if you use card A on a charging point of Provider B you may pay 0.49cents, if you use card C on the same point, it may charge you 0.79cents. And card D isn t taken at all. Some (the newer ones) you can pay directly by credit card, many you can t. Some may allow paypal or Google/Apple Pay. So in the end you need more than just one charging card - I collected 8 free ones by now - just to be sure you can find a combination that isn t hugely overpriced.

I m happy to announce that Netplan version 1.1 is now available on GitHub and is soon to be deployed into a Debian and/or Ubuntu installation near you! Six months and 120 commits after the previous version (including one patch release v1.0.1), this release is brought to you by 17 free software contributors from around the globe. Kudos to everybody involved!

Highlights

• Custom systemd-networkd-wait-online logic override to wait for link-local and routable interfaces. (#456, #482)
• Modification of the embedded-switch-mode setting without virtual-function (VF) definitions on SR-IOV devices (#454)
• Parser flag to ignore individual, broken configurations, instead of not generating any backend configuration (#412)
• Fixes for @ProtonVPN (#495) and @microsoft Azure Linux (#445), contributed by those companies

Releasing v1.1

• CI: adopt autopkgtest for 1.0-1 on 22.04 by @slyon in #446
• tools/keyfile_to_yaml: display the generated YAML by @daniloegea in #452
• tests: import the config fuzzing tests by @daniloegea in #453
• ATTN: parse/bonds: handle same primary in multiple bonds by @daniloegea in #451
• sriov: accept setting the eswitch mode without VFs (LP#2020409) by @daniloegea in #454
• Custom systemd-networkd-wait-online override to wait on interfaces. (Closes: #1008995) (LP#2060311) by @slyon in #456
• Ignore bad NetDefs and files via parser flags by @daniloegea in #412
• networkd:apply: Drop handling of legacy wpa@ instance units by @slyon in #471
• migrate: support aliases by @Kristof0127 in #473
• networkd: add ipv6 ra overrides (LP#1973222) by @KhooHaoYit in #461
• netplan status diff fixes and improvements by @daniloegea in #466
• apply: make sure that networkd is restarted when needed by @alfonsosanchezbeato in #449
• Don t escape certain non-ascii characters by @daniloegea in #486
• networkd: make s-n-wait-online wait for at least one routable interface by @slyon in #482
• networkd: Implement ipv6-address-generation: stable-privacy by @tatokis in #480
• Implementing advmss ip route option by @barvius in #489
• meson: Add testing option by @slyon in #493
• Add a scheduled workflow to run TICS by @daniloegea in #498
• ci: migrate to Ubuntu 24.04 by @daniloegea in #465
• Prepare Netplan v1.1 by @slyon in #504

Documentation

• Fix wrong syntax in example by @fzakfeld in #459
• Tutorial improvements by @rkratky in #458
• added guide for contributing to the netplan documentation by @ade555 in #457
• Add initial SECURITY.md policy by @slyon in #478
• Create single-nic-vm-host.md by @ilvipero in #475
• Create single-nic-vm-host-with-vlans.md by @ilvipero in #476
• Create multi-nic-vm-host-with-bonds-and-vlans.md by @ilvipero in #477
• bullet point removal by @shirleyherox in #483
• Add netplan try to netplan tutorial by @davidekete in #494
• Update the docs checks runner to ubuntu-latest by @rkratky in #500
• Add spelling exceptions by @rkratky in #499

Bug fixes

• Fix logging setup when python-rich is not present by @frhuelsz in #445
• parse-nm: add a workaround for the DoT DNS option (LP#2055148) by @daniloegea in #447
• parse: don t remove datalist items during iteration by @daniloegea in #450
• parse: fix redefinition of gateway(4 6) by @daniloegea in #460
• python: elements of all must be strings by @daniloegea in #464
• CI: Fix DebCI check, using newer meson from unstable by @slyon in #467
• tests: fix diff test with iproute2 6.8 by @daniloegea in #469
• cli/generate: skip daemon_reload with mapping by @daniloegea in #470
• CI: fork spread to get snapcore/spread#179 fixes by @slyon in #472
• ctests: fix a memory leak in a unit test by @daniloegea in #474
• nm/nd: fix a couple of crashes by @daniloegea in #468
• test:integration: Try to improve test flakyness (Closes: #1069871) by @slyon in #481
• Security fixes (CVE-2022-4968) by @daniloegea in #484
• emitter: allow unicode characters in the emitter (LP#2071652) by @daniloegea in #485
• CLI:apply: call udevadm trigger, using action=move (Closes: #1071220) (LP#2066344, LP#2071363) by @slyon in #479
• CI: fix CodeQL permissions by @slyon in #491
• ci: run meson tests with unbuffer by @daniloegea in #501
• ci/tics: install expect as a dependency by @daniloegea in #502
• generate: avoid calling udevadm control reload (LP#1999178) by @slyon in #488
• netplan ignores NetworkManager ipv4.route-metric (LP#2076172) by @calexandru2018 in #495
• Change default umask when creating dirctories (LP#2076319) by @rmalz-c in #497

New Contributors

• @frhuelsz made their first contribution in #445
• @fzakfeld made their first contribution in #459
• @Kristof0127 made their first contribution in #473
• @ade555 made their first contribution in #457
• @KhooHaoYit made their first contribution in #461
• @ilvipero made their first contribution in #475
• @shirleyherox made their first contribution in #483
• @tatokis made their first contribution in #480
• @barvius made their first contribution in #489
• @davidekete made their first contribution in #494
• @calexandru2018 made their first contribution in #495
• @rmalz-c made their first contribution in #497

Full Changelog: 1.0 1.1

Another loss last week of a friend. I am staying strong and working through it. A big thank you to all of you that have donated to my car fund, I still have a long way to go. I am not above getting a cheap old car, but we live in sand dunes so it must be a cheap old car with 4 4 to get to my property. A vehicle is necessary as we are 50 miles away from staples such as food and water. We also have 2 funerals to attend. Please consider a donation if my work is useful to you. https://gofund.me/1e784e74 All of my work is currently unpaid work, as I am between contracts. Thank you for your consideration. Now onto the good stuff, last weeks work. It was another very busy week with Qt6 packaging in Debian/Kubuntu and KDE snaps. I also have many SRUs for Kubuntu Noble .1 release that needs their verification done. Kubuntu:

• See Debian for the qt6 Plasma / applications work.
• Many SRUs in verification stage, please help test these: https://wiki.ubuntu.com/StableReleaseUpdates#Verification
• https://bugs.launchpad.net/ubuntu/+source/tellico/+bug/2065915 needs testing on ARM and there are many packages in that bug.
• https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/2065465 Fix systray icons for third party apps like spotify
• https://bugs.launchpad.net/ubuntu/+source/plasma-workspace/+bug/1629543 Lightdm login manager crash when plasma selected.
• https://bugs.launchpad.net/ubuntu/+source/ark/+bug/2068491 Opening 7zip files in ark.
• https://bugs.launchpad.net/ubuntu/+source/merkuro/+bug/2063936 Merkuro fails to start. Verification done, but more testers welcome.
• https://bugs.launchpad.net/bugs/2066275 SDDM fails to boot after second boot. This SRU has been released!
• https://bugs.launchpad.net/ubuntu/+source/neochat/+bug/2061116 Neochat fails to start.

Debian: Starting the salvage process for kdsoap which is blocking a long line of packages, notably kio-extras.

• qtmpv in NEW
• arianna in NEW
• xwaylandvideobridge NEW
• futuresql NEW
• kpat WIP failing tests
• kdegraphics-thumbnailers (WIP)
• khelpcenter experimental
• kde-inotify-survey experimental
• ffmpegthumbs experimental
• kdialog experimental
• kwalletmanager experimental
• libkdegames pushed some fixes experimental
• Tokodon Done, but needs qtmpv to pass NEW
• Gwenview WIP needs kio-extras (blocked)

KDE Snaps: Please note: Please help test the edge snaps so I can promote them to stable.

• Arianna stable https://snapcraft.io/arianna
• Kfind stable https://snapcraft.io/kfind
• Kclock edge https://snapcraft.io/kclock
• Kigo edge https://snapcraft.io/kigo
• Kimagemapeditor edge https://snapcraft.io/kimagemapeditor
• Kspacedual edge https://snapcraft.io/kspaceduel
• Picmi edge https://snapcraft.io/picmi
• lskat edge https://snapcraft.io/lskat
• Ksudoku edge https://snapcraft.io/ksudoku
• Ksquares edge https://snapcraft.io/ksquares
• Juk edge https://snapcraft.io/juk
• Kalgebra edge https://snapcraft.io/kalgebra
• Ktuberling edge https://snapcraft.io/ktuberling
• Ruqola edge https://snapcraft.io/ruqola

WIP Snaps or MR s made

• Kirigami-gallery ( building )
• Kiriki (building)
• Kiten (building)
• kjournald (Building)
• Kdevelop (WIP)
• Kdenlive (building)
• KHangman (WIP)
• Kubrick (WIP)
• Palapeli (Manual review in store dbus)
• Kanagram (WIP)
• Labplot (WIP)
• Kjumpingcube (MR)
• Klettres (MR)
• Kajongg edge (Broken, problem with pyqt)
• Dragon edge ( Broken, dbus fails)
• Ghostwriter edge ( Broken, need to workout Qt webengine obscure way of handling hunspell dictionaries.)
• Kasts edge ( Broken, portal failure, testing some plugs)
• Kbackup edge ( Needs auto-connect udisks2, added home plug)
• Kdebugsettings edge ( Added missing personal-files plug, will need approval)
• KDiamond edge ( sound issues )
• Angelfish edge https://snapcraft.io/angelfish ( Crashes on first run, but runs fine after that.. looking into it)
• Qrca edge ( needs snap connect qrca:camera camera until auto-connect approved, will remain in edge until official release)

Thanks for stopping by.

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

autopkgtest/Incus build streamlining, by Colin Watson Colin contributed a change to allow maintaining Incus container and VM images in parallel. Both of these are useful (containers are faster, but some tests need full machine isolation), and the build tools previously didn t handle that very well. This isn t yet in unstable, but once it is, keeping both flavours of unstable images up to date will be a simple matter of running this regularly:

RELEASE=sid autopkgtest-build-incus images:debian/trixie
RELEASE=sid autopkgtest-build-incus --vm images:debian/trixie

Linux live-patching, by Santiago Ruano Rinc n In collaboration with Emmanuel Arias, Santiago continued the work on the support for applying security fixes to the Linux kernel in Debian, without the need to reboot the machine. As mentioned in the previous month report, kpatch 0.9.9-1 (and 0.9.9-2 afterwards) was uploaded to unstable in July, closing the Intent to Salvage (ITS) bug. With this upload, the remaining RC bugs were solved, and kpatch was able to transition to Debian testing recently. Kpatch is expected to be an important component in the live-patching support, since it makes it easy to build a patch as a kernel module. Emmanuel and Santiago continued to work on the design for Linux live-patching and presented the current status in the DebConf24 presentation.

Salsa CI, by Santiago Ruano Rinc n To be able to add RISC-V support and to avoid using tools not packaged in Debian (See #331), the Salsa CI pipeline first needed to move away from kaniko to build the images used by the pipeline. Santiago created a merge request to use buildah instead, and it was merged last month. Santiago also prepared a couple of more MRs related to how the images are built: initial RISC-V support, that should be merged after improving how built images are tested. The switch to buildah introduced a regression in the work-in-progress MR that adds new build image so the build job can run sbuild. Santiago hopes to address this regression and continue with the sbuild-related MRs in August. Additionally, Santiago also contributed to the install docker-cli instead of docker.io in the piuparts image MR, and reviewed others such as reprotest: Add append-build-command option, fix failure at manual pipeline run when leaving RELEASE variable empty and Fix image not found error on image building stage.

Python 3.13 Betas, by Stefano Rivera As Python 3.13 is approaching the first release, Stefano has been uploading the beta releases to Debian unstable. Most of these have uncovered small bugs that needed to be investigated and fixed. Stefano also took the time to review the current patch set against cPython in Debian. Python 3.13 isn t marked as a supported Python release in Debian s Python tooling, yet, so nothing has been built against it, yet. Now that the Python 3.12 transition has completed, the next task will be to start trying to build Debian s Python module packages against Python 3.13, to estimate the work required to transition to 3.13 in unstable.

Miscellaneous contributions

• Carles Pina updated the packages python-asyncclick, python-pyaarlo and prepared updates for python-ring-doorbell and simplemonitor.
• Carles Pina updated (reviewing or translating) Catalan translations for adduser, apt-listchanges, debconf and shadow.
• Colin merged OpenSSH 9.8, and prepared a corresponding release note for DSA support now being disabled. This version included some substantial changes to split the server into a listener binary and a per-session binary, and those required some corresponding changes in the GSS-API key exchange patch. Sorting out the details of this and getting it to work again took some time.
• Colin upgraded 11 Python packages to new upstream versions, and modernized the build process and/or added non-superficial autopkgtests to several more.
• Rapha l Hertzog tweaked tracker.debian.org s debci task to work around changes in the JSON output. He also improved tracker.debian.org s ability to detect bounces due to spam to avoid unsubscribing emails that are not broken, but that are better than Debian at rejecting spam.
• Helmut Grohne monitored the /usr-move transition with few incidents. A notable one is that some systems have ended up with aliasing links that don t match the ones installed by base-files which could lead to an unpack error from dpkg. This is now prevented by having base-files.preinst error out.
• Helmut investigated toolchain bootstrap failures with gcc-14 in rebootstrap but would only discover the cause in August.
• Helmut sent a MR for the cross-exe-wrapper requested by Simon McVittie for gobject-introspection. It is a way of conditionally requesting qemu-user when emulation is required for execution during cross compilation.
• Helmut sent three patches for cross build failures.
• Thorsten Alteholz uploaded packages lprint and magicfilter to fix RC-bugs that appeared due to the introduction of gcc-14.
• Santiago continued to work on activities related to the DebConf24 Content Team, including reviewing the schedule and handling updates on it.
• Santiago worked on preparations for the DebConf25, to be held in Brest, France, next year. A video of the BoF presented during DebConf24 can be found here.
• Stefano worked on preparations for DebConf24, and helped to run the event.