Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.12RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.4.27RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
One of the core dependencies of syslog-ng is the ivykis library. We have a few FreeBSD specific fixes in our ivykis fork, however the syslog-ng port uses ivykis from ports instead of the bundled version. I am now working on making it selectable. Testing and help are welcome.
I tried running a Fedora 42 bootc image on a Raspberry Pi 5. It’s a partial success, but I got far enough to learn a lot. The Pi 5 boots and I can log in, but the stock kernel can’t see the Ethernet chip, the Wi-Fi chip, or most other drivers. Only the USB ports work.
How I Installed Fedora 42 bootc into RPi5?
Built an ARM64 disk.raw image with bootc-image-builder from Raspberry Pi 5 itself. (I know QEMU exists, but I couldn’t get it working due to my lack of knowledge with QEMU) *shrugs
Flashed it on an SD Card with dd.
Added the community EDK2 UEFI firmware (rpi5-uefi to the EFI partition, next to the existing EFI/ folder.
Booted the Pi5 and reached a Fedora 42 Login. (partially successful).
Last Sunday I spent my day at the third Audio Expo in Budapest. Yet again it was fantastic. And yet again, my favorite audio experience was in the NCS Audio room, even if I listened to lot more expensive systems.
TL;DR:
Made in Hungary audio rivals the rest of the world in quality, while often being available at a much more affordable price. My favorite of the show was the NCS Audio / Qualiton / Pixel cables room, all made in Hungary. 72 Audio was also perfect, as usual. Heed Audio Helikon with Zellaton speakers could fill the largest show room with lively sound. A pair of Popori Acoustics speakers sounded beautiful with a prototype Natural Distortion DAC and amp.
NCS Audio
This year I visited the Audio Expo with someone who prefers headphones. In her experience speakers cannot give you the level of dynamics and detail that a good pair of headphones can provide. In the NCS Audio / Qualiton / Pixel cables room this suddenly changed.
We listened to almost all the systems on the seven floors of the exhibition building. This was the one where we returned for a second round of listening. No matter the type of music we listened to, it had extreme clarity, even in the bass section. We were looking for where the band is hiding, as it sounded like an actual band was there, not just a pair of speakers.
Best of all: this was one of the most affordable systems at the expo, beating many more expensive systems in listening experience.
Last year 72 Audio presented my favorite music experience at the Audio Expo. This year they presented a lot more affordable system. Still, it was one of the best sounding ones. Or, if you ask my partner, it was the best.
Their products are still just a prototype, but they definitely sound fantastic. A miniature DAC and amp were driving a pair of huge Popori Acoustics speakers and provided one of the most detailed sound experiences at the expo.
We listened to some church organ music. The pedals sounded a bit weak, but for the rest I felt as if I was sitting in the church and was listening to the performance live. It is very rare that organs sound natural to me from speakers.
While Natural Distortion sounded perfectly natural, systems with room correction sounded completely distorted. One of the demo songs was organ music, and the presenter of the demo explained how all the hard work of DSPs ensures the perfect sound. There was more than enough bass, still the whole thing sounded to me a kind of unbalanced and processed. While listening, I did not have the illusion of sitting in the church at all.
I was looking forward listening to some of most hyped new devices developed here in Hungary. The DAC and active speakers sounded OK, but as the door of the listening room was wide open and fixed in that position, there was no chance to hear the details. Much of the music was lost in the noise coming from outside.
When it comes to music, size does not matter. There were quite a few huge speakers at the event, but most of them were just loud, without providing an enjoyable listening experience. Even my good old speakers at home provide a lot more detail than some of the giants at the event.
Some positive experiences
Talking about oversize speakers. This year the Visegrád room, the largest show room of the building, had a Heed Helikon as amp, and a pair of Zellaton speakers. In earlier years I was always disappointed in this room. Loud and slightly distorted music on a pair of very expensive speakers: not something for an extended listening session. This year the room was full of perfectly sounding music, and I only left because I wanted to visit each and every room before closing time. As an added bonus, we had Lucina Yue on site, talking about her latest album: https://tidal.com/album/450279864
Another setup on my favorites list was put together by Limar Audio. They used a pair of miniature bookshelf speakers from Paradigm, but they could fill the room with beautiful music.
Audio Expo 2026: Limar Audio
I prefer speakers, but as I was with someone preferring headphones, we also listened to some. We saw some odd-looking oversize headphones at a HydraSound stand in the hall. The HEDD headphones sounded fantastic, but obviously listening to an open back headphone in a busy environment is far from optimal. After a while we learned that the stand was actually about cables, the headphones were not for sale :-)
We also visited the MUZIX stand in the basement and listened to several Final Audio headphones. Navigating a Japanese tablet was a kind of a challenge. Luckily I use TIDAL enough to be able to search all different kinds of music for testing. Final Audio excelled with each of them.
Conclusion
Obviously, we did not have a chance to hear all systems with all the different types of music we listen to: everything from classical to metal, jazz, electronica, progrock and even some pop occasionally. So, all experience depended on not just the systems, but also on the music played at the time of visit. Still, I suspect that there would not have been major changes in my review if we had had a chance for more thorough listening.
Introducing TeamSBC Linux For the past few years I’ve been working on bootc based operating systems through my work on image-builder. Before that I worked on ostree based operating systems as well. All of this mostly in the Fedora Linux corner of distributions.
As you might’ve gathered from my previous blog post on Cohesive Linux I am also quite fond of the systemd approach to image-based Linux. This approach isn’t very common amongst Fedora derivatives (remixes) and thus issues with integrating that approach don’t get found as easily.
For decades, the Linux virtual console has relied on the kernel fbcon driver, to draw the framebuffer, to manage fonts, and to handle keyboard layout. Starting with Fedora 45, we’re switching to a userspace utility called kmscon. Depending on your usage of virtual console, this may impact your workflow.
If you’re not a developer or a system administrator, chances you probably never heard about fbcon or virtual terminal (VT), in this case you’re probably not impacted.
You can still read the rest if you’re curious about minimal text interfaces, and maybe you’ll start using it.
How to use the virtual console
Most of the graphic sessions runs in tty1 or tty2. So press Ctrl+Alt+F3 to switch to tty3, and you will get a login prompt. This is the virtual console we’re talking about. To go back to your graphic session, press Ctrl+Alt+F1 (or F2 or F7 depending on your desktop environment).
Why is kmscon replacing fbcon ?
The legacy fbcon driver runs directly in the kernel space, and has significant drawbacks:
Security: Each bug in fbcon can be exploited in the kernel directly, and each crash is a kernel panic.
Keyboard layout: The keyboard layouts supported by the kernel are different from what userspace is using. So when you choose the keyboard layout in the anaconda installer, it tries to find the kernel layout that is as close as possible to the chosen layout.
Fonts: fbcon only uses bitmap fonts, which look small on a High DPI display, and you can’t resize them at runtime. They have limited unicode support. Kmscon can use freetype, and render all monospace fonts.
Scrolling: fbcon does not support scrolling anymore, due to a CVE.
Mouse: fbcon does not have mouse support, it can be added with gpm, but is a bit clumsy. Kmscon uses a transparent hardware cursor when available, and has basic mouse support.
Fbdev: fbcon relies on the old fbdev interface, but all GPU drivers are now using drm. Switching to kmscon allows dropping the fbdev emulation layer in the kernel.
What this will change for users and administrators ?
Kmscon uses pseudo-tty (pts) devices. So when you run tty it returns /dev/pts/0 instead of /dev/tty1, like when you use a graphic terminal. So you will need to update all scripts or configuration that use this information.
Kmscon uses the exclusive drm interface to the GPU to draw the terminal. If you want to run a graphic session or a program that wants to use the GPU, it won’t work like it used to with fbcon. The reason is that fbcon runs in the kernel and can let any userspace application take the GPU. Kmscon can’t do that, so you have to tell it to release the GPU. This is done with a script called kmscon-launch-gui. For example, to start a graphic session you can run kmscon-launch-gui kmscube -c 100 or kmscon-launch-gui startx
Kernel messages: By default the kernel error/warning messages are visible in tty1. It can be annoying when it mixes with what you are typing. You can read the messages with dmesg -w, or have a dedicated tty that runs kmscon --vt=%I --no-switchvt --oneshot --login -- dmesg -w
Kernel fonts: The setfont command has no effect on kmscon. Kmscon uses the built-in unifont or freetype if it’s available. You can read below how to configure it. kmscon can also use psf fonts, if you want the exact same looking as fbcon.
Keyboard layout: The loadkeys command has no effect on kmscon. Instead, kmscon listens to localectl dbus, and updates the keyboard layout accordingly. So, to change layout, run localectl set-keymapus
Kmscon replaces the default console in F45, for tty1-6. If you want to keep a tty using fbcon, just in case, you can run sudo systemctl mask kmsconvt@tty5 && sudo systemctl enable --now getty@tty5 Then pressing Ctrl+Alt+F5 switches to your good old fbcon console.
Default kmscon shortcuts
Zoom in: Ctrl++, Ctrl+WheelUp
Zoom out: Ctr+-, Ctl+WheelDown
Rotate the terminal: Super++, Super+-
Scroll up: Shift+UpArrow, Shift+PageUp, Mouse Wheel Up
Scroll down: Shift+DownArrow, Shift+PageDown, Mouse Wheel Down
Copy/paste: select with the mouse, or select a word with double click, and MiddleClick to paste
Switch to ttyX: Ctrl+Alt+FX
Restart kmscon on ttyX: sudo systemctl restart kmsconvt@ttyX
To know on which VT you are using, echo $XDG_VTNR
How does it look ?
Previous experience, Fedora 45 with fbcon:
Fedora 45 with kmscon (unifont)
Fedora 45 with kmscon (freetype) and some customization (fish, Hack Nerd Font)
How to configure kmscon the way you like
Plugins
kmscon is split into multiple subpackages, so you have a minimal installation without graphic/font dependencies for servers, and optional packages for more features.
kmscon: main package, contains the unifont font, for good unicode support without additional dependencies.
kmscon-freetype: Use the freetype library to render the fonts.
kmscon-pango: Uses the pango library to render the fonts, it is deprecated in favor of kmscon-freetype.
kmscon-gl: This is an opengl renderer. This might be faster but also a bit blurry. You need to add hwaccel to your configuration file to actually use it.
Configuration file
The configuration file for kmscon is /etc/kmscon/kmscon.conf you can copy the example with this command: sudo cp /etc/kmscon/kmscon.conf.example /etc/kmscon/kmscon.conf
Here are the most common options to change:
verbose: enable more logs, if you have issues with kmscon. To get the logs, use journalctl -u kmsconvt*
font-engine: defaults to freetype (if available) or unifont (fallback). You can also use pango, or psf (the format used by the kernel fonts)
font-name: The name of the font (for pango, freetype, and psf). As kmscon runs as root, the font must be installed in /usr/share/fonts, not in your home directory. You can find the exact name to use with fc-list. You can install Cascadia fonts, that are good for non-latin languages with sudo dnf install cascadia-fonts-all If you want fancy icons, Nerd fonts are good, but not available in the default Fedora repository. For psf font, font-name is the path to the font file.
font-size: The font height in pixels. By default kmscon tries to scale the font to have about 120×40 characters.
multi-monitor: multi-monitor configuration, the terminal is the same on all monitor. The default is scaled which will scale the font to avoid too much black border. Other options are clone, which will center the terminal on each monitor, and largest which will only use the largest monitor.
dpms-timeout: The timeout (in second) after which the monitor will be turned off. default to 600 (10 minutes). 0 means disabled.
no-mouse: This disable the mouse support. It can be useful to disable touchpad on some laptops.
palette: Change the default color palette for your terminal. You can define each color if none of the provided default palette suits you.
Conclusion
We hope you will enjoy using kmscon in Fedora 45. You may use it occasionally, or use it as your main session for some specific usage, like Veronica Explains for a writerdeck https://www.youtube.com/watch?v=E7vFdy4BEAY.
If you encounter any bugs, have feature ideas, or want to contribute to development, the upstream repository is at https://github.com/kmscon/kmscon.
In the last couple of years, most companies have adopted some kind of AI.
Most of them have done so by buying API access from a small number of frontier labs.
This approach has the lowest barrier to entry and is often the preferred starting point, but it’s problematic because of the huge, unmanageable costs it creates, the shrinking, potentially useless gap in capabilities with open-weight models, and many sovereignty issues.
It’s October, and you know what that means…Its Hallow…. no… its the start of curling season!!!!!!!!!
Jef, what does this have to do with the scope of this blog? Well at the start of curling season, back in Alaska I’d always get together with my other sort of technology nerdy friend Jon and we’d nerdsnipe each other. We’d talk about cool little curling use case technology projects we’d like to try to build. I’m in the headspace right now thinking of small silly curling projects I could start ( I’m not promising to finish them) and in doing so learn more about the local language model as a technology.
Now the obvious thing to do isn’t even really LLM relevant, its vision machine learning. I’ve sort of already explored that topic when I was learning about machine vision so it’s not an interesting problem space for me right now. But if you want to know sort of the state of the art of DIY curling rock detection, check out the codetrick blog series. If I’m reading the blog correctly he’s making use of a variety of tools licensed under a mix AGPL BSD and Creative Commons. If you are interested in visual machine learning and not “chatbot” style LLMs, it's a really good read as a blog series.
I however am currently interested in learning LLMs, so I’m trying to figure out some curling related silliness that will let me explore the LLM inference technologies I can run locally. I’ve thought up some vibe coding projects that I can hopefully build a prompt for and compare the outputs of different models with. But I’m also interested to see if I can do any interesting boutique small language training with the small iron I have sitting under my desk. Can I describe curling games in a compact “language” similar to how chess games (hey they call curling chess on ice) and train a curling strategy bot and have it call strategy during a real game? I don’t expect it to be good. In fact I definitely want it to be not good…because it’ll be funnier. But I do want to understand the training process first hand and this fits my idiom.
What I don’t know how to do is create enough real world training material to sufficiently train such a thing. How many different curling games do I need to describe in a compact language of my own design? Can I simulate games using a simplistic Markov process and train with that? Can I train from real games? And how would I actually automate the transcript of games into my language? Which brings me back to the rock detection blog series I pointed out earlier. If I could point that vision system not at live games, but at the video recordings on youtube of all the livestream cameras from clubs that livestream their leagues and events and have it provide compact language descriptions of the evolution of the games… I might have a lot of low quality training data…to create my low quality strategy bot..and I can have a ton of fun with that during the wacky rules social spiel later in the season.
Anyways… like I said, it's that time of year when I think about stuff like this. First curling game of the season is Monday.
Thanks for reading JefFPL! Subscribe for free to receive new posts
It has been three months since we published our preprint, and it has now passed 500 downloads. That seems like a good occasion to write about how I ended up working on molecular simulations and scientific software after leaving a promising assistant professorship.
I have tried to write about that decision several times, but the drafts kept growing and none reached publication. There was always more to explain. This time, I will focus on what led to the decision and what came of it.
Hello again to any readers out there. Its been a bit.
Last week I was out going to a concert ( rush, they were great! )
and next week I am going to be out again ( visiting friends in New Mexico ).
So, today, lets go over a few things from the last two weeks and look ahead to
next week.
s390x tuning
A few weeks ago we managed to get in touch with some IBM folks who were
willing and eager to help us out with our s390x setup. The problem
is basically that we don't have enough resources to handle times when
there's a lot of larger builds happening at once.
We quickly divided up things: Short term, they would help with any
tuning that they could do to get things in a better place, then medium
term they would look for additional resources for us and finally of
course long term we would want to be in a place where we have all
the resources we need.
The last few weeks focused on the short term performance improvements.
I got them a ton of data (sysstat, sosreports) and explained how we
had setup our lpar and how things worked.
Out of all that:
They tuned the "cpu entitlement distribution" on our lpar.
My understanding is that this controlls how much of real cpus
the virtual cpus in the lpar get by priority.
I allocated more cpus to each guest. I had been conservative on
cpus as I was unsure what the effect of oversubscribing would be
but 1.25x oversubscription should apparently be fine.
This means that builders have 3 cpus where they had 2 before.
They added more memory. This allowed us to boot on new/latest/7.x
kernels. With the memory we had before, the lpar would boot on
newer kernels, but then OOM kill all the guests. This increased
memory allowed everything to boot up normally on the 7.x kernels.
It also allowed adding memory to all the guests.
I think this has had a real impact, but we will see over the coming weeks
exactly how much. Medium and Longer term efforts are ongoing.
Fedora 45 upgrades at home
I decided to upgrade my home servers to Fedora 45 (as I often do it in
the weeks before a release to catch any last minute things).
On one server this went completely smoothly. No problems at all.
The 1G fiber link made short work of the downloads too, so it was quite
fast and easy.
However, things did not go as well on my main server. It was cruising along
and applying updates and... it got a MCE and killed the update in the middle.
I'm not sure why it got the error. It's not had any before or since.
I sure hope it's not becoming unstable.
Luckily I was able to get in, remove some duplicate packages, reinstall
a few more, run some remove --duplicates and then distro-sync again.
In the middle of that I messed up and remove both the old and new dnf versions
and so I had to download packages and use rpm to install them back.
Finally everything in place and... for some reason it didn't activate
the lv's in my secondary raid. I am still trying to see why it didn't
do that, but in the mean time I activated them manually and everything
was back up and on f45.
It amazes me how messed up something can be and you can still cleanly
recover from it and go back to a good state.
Just a small one for myself (and anyone else looking to build the zellij terminal
multiplexer on Fedora 44).
During the build of zellij, cargo will try to build openssl-sys. I always end up adding
the required operating system packages one by one in a repeating trial and error to make
the build work. So for the next time I (or someone else) runs into this:
Fedora Linux 45 is almost here! Developers, packagers, and quality assurance engineers are hard at work putting the remaining polish on Fedora 45, which means it’s time for our Global Virtual Release Party! It is almost time to celebrate! If all goes according to plan, we will celebrate Fedora 45 just after its actual final release.
To mark the occasion, we are hosting the Fedora Linux 45 Virtual Release Party on Friday, October 30, 2026.
Regardless of the final calendar date of any Fedora Linux release, every release represents months of hard work, testing, and collaboration from our global community. Whether you are a long-time package maintainer, a dedicated documentation writer, a creative graphic artist, or a brand-new user, this release belongs to you.
Join us for a half-day of live sessions, recorded deep-dives, and community socialization. We’re busy filling the upcoming schedule with updates from the Fedora Project Leader and behind-the-scenes looks at new features.
How to Attend
The event is 100% free and open to everyone, but registration is required to access the virtual venue. We will continue using Element, our chat communication platform, as the virtual venue for the Global Virtual Release Parties. Thanks Element & Matrix.org for providing us the great tools to bring our global community together!
Don’t miss out on the chance to connect with the people who build Fedora. Grab your ticket, share the link with your friends, and get ready to celebrate Fedora Linux 45.
The trend is definitely going towards a smaller Engineering and a bigger AI section.
I don’t like that.
This week, have a look at John Cutler’s Feature Factory Retrospective and the No Man Is an Island post.
If you want a podcast and like engineering, check out “Building resilient systems”.
Quote of the Week
And that’s the deciding factor. We can’t win against obsession. They care, we don’t.
Epic just announced the upcoming version 2 of their Linux implementation of Easy Anti-Cheat. It’s based on using the Linux eBPF security module to monitor what’s happening, and then a bunch of extra infrastructure to make sure this can’t be bypassed. The core part of this is requiring secure boot be enabled (ensuring that modified kernels can’t be used), using measured boot to verify that secure boot is enabled and which keys are used (to prevent you from just signing your own modified kernel), and then doing remote attestation, a mechanism where the TPM generates a signed copy of the boot measurements and passes that off to a server which verifies it came from a real TPM, verifies that you have secure boot enabled and are using the right keys, and presumably then allows you into the game.
This is all fine as long as you can prove that the measurements provided are real, and that’s actually a lot harder than you might think. First, we can simply make up our own quote signed with our own key and say that it came from a TPM. This is avoided by every TPM having an Endorsement Key (or EK) and an associated certificate, with that certificate being signed by the TPM vendor. If you have a list of all the legitimate TPM vendors and their CA keys, you can verify that the measurements came from a real TPM. Easy enough. So we need to get the measurements from a real TPM, and the one on our motherboard contains the measurements that were generated by the firmware and bootloader, and we can’t reset those at runtime without resetting the TPM, which… oh huh there’s actually nothing stopping us from doing that at runtime, as long as we have access to the hardware. Many desktop boards have the TPM on a small plugin module with a standard pinout that includes a reset pin. Simply short that to ground briefly and the TPM is back in its initial state, and userland can write whatever measurements it wants to it. Boot a modified kernel which lies to the eBPF code? As long as you replay the expected log values from a boot with secure boot on and a trusted kernel, the TPM will still happily provide a legitimate set of measurements that’ll satisfy the checker.
What if the TPM is less accessible, either because it’s mounted directly to the motherboard or it’s inside the CPU or chipset? That’s going to be trickier. But here’s the thing. The quote needs to come from a TPM, but not necessarily the TPM on your motherboard. TPMs these days are usually connected via the Serial Peripheral Interface, usually referred to as SPI. Microchip make a USB to SPI bridge, and there’s a Linux driver. Wire one of those up with an appropriate header and you can plug in an easily available TPM module intended for plugging into a motherboard, and now we tell the kernel to ignore the motherboard TPM and make /dev/tpmrm0 point at the USB one and program it with a set of trusted measurements and once again everything is going to look just fine (yes obviously the eBPF code can look for this, but we’re running a modified kernel so we can just lie to the eBPF code).
Remote attestation on PCs just doesn’t work that well in environments where you can’t associate a specific TPM with a specific system, which is basically everywhere except enterprises. But maybe that doesn’t matter and cheaters wouldn’t be willing to spend the $20 or so it’d take to produce one of these things? That would seem somewhat surprising, but it’s not impossible. And obviously any server-side cheat detection that triggers could then block that specific TPM, meaning they’d need to go and get another TPM, and maybe that ends up being enough to discourage people from bothering. From a practical level, this may be sufficient. But at a technical level? It’s not great.
Today I learned more about fonts and found one great one to replace my current setup and pair with my colour palette.
Maple Mono is an excellent monospace font with a rounded design and smart ligatures. After testing it on terminal and my code editor (both using Catppuccin Mocha), it worked great together, the soft, rounded glyphs complement the pastel palette.
I’m adding this short note to my TIL section mainly as a personal reference for future use, I’ll probably write a full blog post about fonts, a topic I don’t know much and I found quite interesting.
The Fedora Project Leader is an interesting gig. The role puts me in conversations about topics that potentially have broad ecosystem impact that go far beyond Fedora as a project. I’m very grateful for the opportunity to inhabit this role because of that. But also I’m humbled by the access I’m afforded. I always approach these conversations with an eye on how these conversations can lead to something with positive ecosystem wide impact.
So the other day I got invited to jump on a call with some people from Epic Games, and I got foreknowledge concerning the new technical approach they wanted to take to implement anti-cheat on Linux based operating systems.
long story short, I’m supportive of their approach. It boils down to having a system where users choose to run their Linux system in specific ways that the anti-cheat system can verify before they are allowed to participate in the gaming platform. It makes use of secure boot, trusted signed vendor kernels ( including Fedora), and BPF code instead of any kernel modules.
I know a high school teacher back in Alaska who would have loved to be able to setup some linux gaming stations for the eSports teams he coached. Is coached the right word for eSports teams? I don’t know I’m an old.. I just remember having to run twisted pair networking to run LAN parties.
I don’t think they realized at the start of the conversation that I have as much experience with eBPF as I did. Disclosure: my previous gig as a developer advocate with Isovalent (now Cisco) working in the context of the Cilium open source CNCF project, put me into direct contact with eBPF workloads and I was forced to wrap my head around it to do my job. So when they asked me to read over a technical brief over their approach, I was ready to go pretty deep about the approach. But what I did instead was express my impression that their technical approach was probably the best approach I could imagine if I were going to implement something like an anti-cheat system. I also pointed them to the current Fedora Change Proposal that might be relevant to their approach.
But like I said, I always enter these opportunities with an intent to find the ecosystem wide impact. As we got to talking about possible concerns that might be raised with this approach, I offered myself to facilitate a panel discussion where we have some subject matter experts talk through specifics. For myself, even though I have more than a passing knowledge of eBPF, I’m not an expert in its use for this sort of workload, and I’d like to bring someone into a panel discussion with the Epic security team in a public setting to talk about it as a technology. This might be the first end-user desktop oriented use case for eBPF, There’s a lot of understanding about it in other contexts.. and I’d like to bring some of that understanding to a conversation in front of a Linux gaming enthusiast audience.
I also want to have someone from Bazzite on the panel. Because Bazzite, as a Fedora downstream, is lazer-focused on this particular use case. Fedora will hopefully be able to integrate some deeper open source changes that simplify the user experience in a broader context, but Bazzite is where I expect everything to come together to provide something seamlessly consumable. I want to make sure we include that perspective in the follow-up panel conversation… if not earlier. I definitely want to have Bazzite devs and this team at Epic talking asap. So I’m heading over to that downstream community as soon as I get this published to see how I can help put them in contact with the right people.
Thanks for reading JefFPL! Subscribe for free to receive new posts.
I’m going to be providing dispatches in blog form that detail my learning journey concerning LLMs. I’m going to be experimenting with fully open source inference that I can run locally on hardware I control. Local Language Models; the other LLM. What utility can I get without reaching for the frontier “as a service” models? Will I have fun? I don’t know yet. I’ve made a commitment to myself to learn, and the way I learn best is experiential. Yeah I was pretty good at textbook learning, but honestly I always enjoyed the homework more than the lectures or the text. So I’m giving myself homework. And I’ll be reporting back on my assignments to myself here as blog posts. I’ll figure out how to tag or label this so they stand apart as a set of dispatches so that this learning journey can be reviewed in a coherent fashion by future me.
But before I begin all of that, I just want to provide some more thought leadery thoughts to set the stage for why I’m even bothering. Why am I investing my free time in this? Future me, you may be wondering why am I not just studying more curling strategy right now? Good question future me. Let me explain.
Big picture thoughts
The topic of LLMs has been a weebit controversial for the entire open source ecosystem in a way that I’ve never seen in my personal 20 something year history as self-professed (because we don’t have an official business card I don’t think - there might be a secret handshake I'm not aware of though) open source enthusiast.
Over the years we’ve had very opinionated and sometimes heated discussions over disagreements in technology and some standards of practice.. that usually result in forking something; either code or a project community or both. Forking is the fundamental freedom of open source. Forking isn’t always the most efficient choice, but it’s how the ecosystem at large moves forward sometimes when there is a difference of opinion. It happens more often when its a technical difference in opinion. Forking the code bits is just sort of non-controversial. Our 20+ year old, now defacto standard, collaborative development tool, git, bakes the concept of ‘forking’ into its operational language. Technical forks are as common as air in the ecosystem now. But sometimes forks are about licensing, and that creates forks around entire project communities and that can be quite controversial when the project contribution community is more than that one person in Nebraska maintaining a codebase alone that we all rely on. Licensing forks tend to make the news. However, forks historically have been very seldomly about developer tool use. Though we did get quite close in the upstream kernel development community in the great bitkeeper use debate that resulted in the creation of git as an open source alternative to a proprietary tool. I find the history of bitkeeper/git instructive. When it comes to concerns over tool use, maybe the right answer is to build an open tool instead of forking a community. Maybe when we build the open tool, we end up unlocking something magically positive and transformative for the entire ecosystem. git was that.
I’m very sure forking in a way where some projects allow the use of this technology and some don’t is not going to work out well for us and our collective interests… that being to make sure users stay in control of their technology.
The hard discussion around the LLM flavor of AI goes much deeper and much wider than we are used to debating in the open source ecosystem. I don’t think forking our way out of the deep sense of conflict here does anything but depower our shared ability to control the future of this technology. Looking through the history this is probably nearly as significant a discussion as the very idea that software should be copyrightable under US law (instead of being treated merely as instructions.. like cooking recipes) I think the only way through this mess, this very hard discussion, is to stand up fully open versions of this technology.
I think the frontier LLM as a service business model is deeply problematic. I think the fallout from the irrational and unsustainable amount of investment in those “as a service” offerings that have dominated the discussion is unavoidable. A bad business model has poisoned our societal understanding of the utility of the technology. We are reacting to a bad business model that has somehow been allowed to grow beyond the bounds of expected VC risk/reward assessment guardrails. When the investment capital dries up, and these frontier companies can’t burn cash any longer, their failures will have global economic impact. I think it’s unavoidable at this point.
But I think the technology lives on past that, because the technology is not the business model. I believe all cash burning business model will fail. Its the fate of every start-up that relies on venture capital and can’t figure out how to reduce the marginal operating cost per customer as it scales its customer base. I’ve been in a few start-up environments. I actually like the hustle energy of a start-up. But at some point you have to transition from runway to revenue from mindshare to customers and you must be prepared to pivot business models to get there. You should expect the VC investors will come knocking on a return on investment far sooner than you want them to. And if you’re still in startup mode, while also tapping literally all the global investment venture capital liquidity on the planet, and your 10x return expectation to investors is literally more than the entire planet’s measurable economic output…. all you’ve proven is you have a really great pitch deck as a start up founder and you’ve tapped into some really deep irrational sentiment in the investment class. It’s crazy to me how crazy the VC culture has become. THIS IS CRAZY. Siri, play Crazy Train by Ozzy Osbourne to set the mood.
Thanks for reading JefFPL! Subscribe for free to receive new posts and support my work.
Preparing for the future
So yeah, I think we are in a bubble and it will pop. But I think the technology continues on in both proprietary and open implementations.. like most technologies do. I finally gave up on my cuecat QR reader and threw it away in the move from Alaska last year. The QR code stuff just never took off like I thought it would.
So I’m preparing for the post LLM business model bubble future. A future where open source takes front and center in how the technology evolves. And in order to do that I need to get hands on with what the state of the art of open source AI is and running it on local hardware (local hardware may mean cloud compute for some people). I finally got myself a new workstation, a Framework desktop with an AMD mainboard, my first personal desktop computer I’ve bought with personal money in well… to be honest I don’t really know. I haven’t had a desktop computer since living in Jersey.. I think I moved it to Alaska. My personal computing expenses has been smart phones (shout out to the other FirefoxOS phone owners!), pis, and microcontroller hardware, I’ve had the privilege of being able to transition work provided laptops into personal machines for years and years. I’ve kinda taken that for granted. Hey what can I say, startups don’t have mature technology asset management.. not something you think about until you get to a certain size.
Thinking globally and acting locally
I could have done a beefy workstation purchase months ago… but I waited until we got the solar power on the house..and that took way too long (thanks HOA rules). But HOA bureaucracy aside, why did I wait until I had solar on the house?
Because I have a very deep ethical problem with how much energy and water resources is going into training LLMs and I wanted to do what I could to offset that. If I’m going to lay hands on the technology at all I need to accept some responsibility for the impact as a user. I know that I can’t single-handedly undo the problem. But just like plastics recycling, I can’t undo the damage being done by plastics globally either. But I can act locally and mitigate as much as I can while participating in a flawed global system. And I can do that while advocating my geopolitical leadership at all levels to put rational policies in place to fix the systemic problems. I am at peace with how I’ve chosen to mitigate my own ethical concerns at the start of choice to start interacting with the technology.
I’m trying to figure out how I can go further and make sure my excess solar energy I produce every year can go to a good cause.. still trying to navigate the power company policies to see how I can take control of the excess power I generate so I can direct it to help non-profits instead of just being purchasable power by anyone (especially the data centers). I might not have a great solution for that. The best I can maybe do is get a power purchasing agreement so at the end of the year the power company cuts me a check for my excess power they sold on the open market at wholesale prices. I can then turn around and take that cash and give it to a non-profit. Its not as good as kwh for kwh credit transfer, because I only get wholesale pricing in a purchase agreement so I can’t offset the retail cost of electricity for a charity. And it won’t feel nearly as good as denying the data centers in Virginia (and there are a lot of them) from being able to use the power I’m generating. But I can, one way or the other, help a non-profit offset their increase in power with my excess; while at the same time lobbying for changes in the energy policy at the state level to make these data centers pay for the infrastructure investments instead of making residential utility customers share that cost.
So here is where I’m at today
I have a desktop capable of being used to do some local language model stuff. I have Fedora Linux running on it. I’ve followed the basic online instructions on setting up ollama and llama.cpp, using as much as I can from the Fedora Linux rpm package repositories. Thanks AI/ML and Heterogeneous Computing SIGs for the great packaging work that makes it possible for me to just scoop up some things as a user and have a working starting point. And a huge thanks for AMD making the investment to work with the linux upstream community and investing in open source userspace component libraries, so Fedora Linux can ship a working open source compute stack.
The one thing that is missing is Fedora Linux doesn’t yet offer a good selection of appropriately licensed models as part of the rpm package distribution. I needed to go to Hugging Face and navigate the complexity of choice there. That’s a little rough as a starting point. If we as a project can figure out some good, reasonable, models that we can distribute for local hardware inference that would be a good next step in order to get to a future where we can help simplify things for users. The licensing landscape for the model choices in Hugging Face is.. daunting. And I consider myself well versed as a layperson about the licensing difficulties we face as distributors and redistributors. For now I’ve downloaded some models and I’m gonna probably write up a comparison among them as part of this dispatch series. Are there Hugging Face models that could be useful and could be redistributed to form the basis of an opinionated Fedora Linux lab installable? I don’t know yet.
What’s next for me?
I’m looking into agent frameworks so that I can build agents that can run locally. I’m very partial to golang because I don’t want to get bogged down in the complexity of python runtime dependencies. Having spent some quality time working with golang in previous jobs, I like the golang src module model quite a lot. About 3 careers ago, I used python heavily as an academic. But now that I’ve experienced golang, I want to lean-in as much as I can there, even if it means letting go of python as a my preferred development and prototyping tool for my janky personal projects. Anything I can imagine being containerized now.. I’m going to try to do in golang. And my own little agents are definitely something I want to containerize.
Version 8.6.0 Release Candidate 2 has been released. It's now entering the stabilisation phase for the developers, and the test phase for the users.
RPMs are available in the php:remi-8.6 stream for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository (or remi for Fedora)
⚠️ The repository provides development versions which are not suitable for production usage.
There are only so many hours that one could rest for, so, of course, calling it a day early on the previous day led me to wake up early on 26th September 2026. I knew that waking up at 0600am Indian Standard Time would help me reach the venue four hours later with the swags inventory. Since Samyak Jain had arrived on the night before and was planning on joining me for the next couple of days, one of the first things we did was to take the inventory of Ceramic Branded Coffee Mugs and Round Magnet Pin Combos that we had delivered to his relative's house. Working closely with Rajan Shah, we were able to secure the best location for the Red Hat booth and the best schedules for Fedora Project's community presence. We knew from the beginning that we would very likely be the major draw at the booth since we had engaging activities and enticing swags to keep the booth visitors occupied.
Manifest B
Finishing off the breakfast at around 0800am Indian Standard Time, I finally met Samyak at the reception area when he was just returning from the temple. Luckily enough, he had already taken care of having the swag inventories delivered to SRS Springs And Spa Hotel and, alongside that, he had also gone ahead with ordering some stationery after consulting with me. As we did not necessarily have a talk or discussion planned for that day, we wanted to be sure that we had everything we needed for a successful community booth representation. One could not stress just how important supplies like cellophane tapes, marker pens, plastic scissors, thumb tacks, etc., could be in times like these, not just to us Fedora Project folks but also to the neighbouring communities sharing the booth with us, like Ansible, PyTorch, Tekton, Virtualization, and Containers, for the next couple of days of the event.
Manifest C
I was not happy with the incomplete breakfast on that morning, but I did not have the luxury of expressing my dissent at the time. Making do with Boiled Idli and Coconut Chutney, paired with some Onion Pakodas and Hot Tea, I joined Samyak at the hotel reception at around 0930am Indian Standard Time. With the delayed delivery of the swag inventory eating up most of our time, we decided to skip the preliminary accounting and instead haul the entire inventory on our Uber ride to the event venue, NIMHANS Convention Center Bengaluru. Thankfully, Rajan's cohort was able to reach the venue earlier to help set things up amidst the early event rush hours, where we were going to dive right in after some time. Thinking on our feet allowed us to prevent any further delays in reaching the event venue and to take advantage of the first period of the flagship hallway track experience.
Manifest D
With the help of the concierge, we loaded up the heavy units onto the back of our Uber ride, and in the next fifteen to twenty minutes, we found ourselves arriving at the NIMHANS Convention Center Bengaluru. Samyak and I took turns lugging the heavy boxes, weighing 30-40 kg, from the parking area to the registration desk, where we checked ourselves in. Thankfully, our booth was located on the ground floor, right near the entrance, which not only meant that we did not have to play porters for long, but also ensured us the maximum footfall. It was crazy to think just how occupied the venue was, judging by the fact that it had paid registration. With crowd densities comparable to those of free events like FOSDEM etc., this was an expression of just how enthusiastic Indians and people from adjacent regions were about free and open-source software and the folks who maintain it.
Manifest E
Getting to the Red Hat Community Booth was half the struggle – beyond which Samyak and I had to play it by ear to make it behind the already packed booth space. Samyak slowly made his way to the back of the community booth first, while I began unpacking our swag inventory on the desk. With him designing the poster for our community booth interaction activities using generative tooling, it helped us immensely in ensuring that we were able to make meaningful chats with our community of users and contributors at IndiaFOSS 2026 in our period. After a swift catch-up with the likes of Rajan, Deepesh Nair, Shivraj Patil, Veer Kumar Patil, and Gaurav Kamathe, I arranged the metallic Fedora Project-branded round magnet pin combos on the desk at around 1100am Indian Standard Time, which only led to the big crowd at the Red Hat Community Booth grow a whole lot more.
Manifest F
Both Samyak and I knew that we had to leverage the visitor footfall that we drew as the local Fedora Project ambassadors to channel visitors to our FOSS projects. As we were already at our capacity for handling visitors, we deferred handing out the rarer swags, such as Wooden Branded Pop Sockets and Ceramic Branded Coffee Mugs, until later, when the visitor crowd became manageable. Of course, that was a good problem to have, as not only Fedora Project but also the sister community projects could use the attention that we were bringing to the Red Hat Community Booth. Armed with the comparative study between Fedora Linux and other related GNU/Linux distributions, we helped the booth visitors understand the differences. We wanted to ensure that they had the knowledge before deciding on the one that they would want to settle on, instead of incessantly singing the praises of our own.
Manifest G
In the constantly fast-moving world of artificial intelligence, most booth visitors appreciated how Fedora Linux provided them with a curated collection of recent updates for the software applications they used. That, in turn, empowered them to architect solutions for the people of today and the future, instead of waiting much later for them. Being the general-purpose Linux distribution that Fedora Linux was, its appeal was universal among those people who wanted a middle-ground GNU/Linux distribution that was both stable and feature-rich. To our pleasant surprise, we met folks at the booth who learned about Fedora Project while using GNU/Linux distributions such as Bazzite and Ultramarine Linux. Among those questions, we also fielded misconceptions on the figurative death of CentOS Linux and misinformation around Red Hat Enterprise Linux becoming closed source.
Manifest H
Taking one unit of the Ceramic Branded Coffee Mugs at a time to keep the booth conversations going, we were surely able to draw visitors into an interactive task for which Samyak had created the poster. Being this close to our community of users and contributors at an in-person event allowed us to have a unique approach towards gathering feedback. While our questions were subjective in nature and we strictly made a point of not collecting personally identifiable info, we were curious about how this feedback could help shape the future of Fedora Linux. I got to meet various people from both technical and managerial backgrounds who had thoughts on an ideal Linux distribution. As a gesture of thanks, we handed out the limited-edition swag units, all while introducing some friendly competition every now and then whenever a group appeared to keep things lively at our community booth.
Manifest I
In hindsight, the change in our approach towards engaging visitors, from a more passive Google Form during DevConf.IN 2026 to a more active human interview at IndiaFOSS 2026, felt well-guided. While being joined by Sudhir Dharanendraiah, the PyTorch representative, I also got to catch up with him after having met him about six months back. Amidst engaging with the booth visitors, Samyak and I did not realize how we ended up spending most of our time at our community booth itself, even when the designated duty was for the first two hours alone. That was, of course, not a problem; as Rajan mentioned, it was extremely appreciated that we were going above and beyond in steering the crowd of nearby attendees at the venue entrance towards our community booth. The two of us did find ourselves at our energy's limits as we temporarily wrapped things up around the lunchtime.
Manifest J
After a brief run-in with some familiar faces from the Debian Project, namely Ananthu CV and Abhijit PA, and also with some FOSSUnited organizers who came to us for sponsor feedback, we left for the food place. Getting visibly frustrated by the long queue at the serving area, we briefly considered heading out for lunch, only for us to realize later that there were few good places nearby. The closest one was a couple of kilometers away, and we would not be able to return in time if we were to travel there through Bengaluru's traffic. Turning back to the event lunch by around 0130pm Indian Standard Time, we found that the previously huge queue had subsided greatly by then. With no place to sit and eat, we resorted to refuelling ourselves with some Boiled Rice, Mattar Paneer, Mixed Vegetable, Chilled Raita, Warm Chapatis, and Gulab Jamun while standing near the rear exit of the venue.
Manifest K
Finishing off our food by around 0200pm Indian Standard Time, we still had half an hour more to kill before heading back to the community booth. We used this time to explore other community booths that were located at the event venue. It would have been a waste not to interact with FOSS friends from various teams just because we were too occupied representing our own. There was learning to be had, not just from the enthusiastic visitors coming to our booth, but also from being one of the visitors to the neighbouring booths. That led me to having a lively chat with the folks representing F-Droid about the recent unfair restrictions introduced by Google on certified Android handheld devices. Leaving Samyak in a quiet hall on the first floor to recover, I continued by myself to explore the booths on the other side of the event venue, which were mostly about the embedded electronics.
Manifest L
With its majority portion conveniently hidden behind thick vegetation, NIMHANS Convention Center Bengaluru was a deceptively huge location. I could not have guessed that there was an entire second part of the floor being shared by the Red Hat Community Booth with others because of the impressive floor planning. In the hardware section, the couple of event booths that caught my attention exhibited low-profile, manually crafted ergonomic mechanical keyboards and various useful ESP32-based trinkets. It was quite the coincidence to run into another FOSS friend whom we met during FOSSAsia 2026, Anuvrat Parashar, with whom I caught up and shared a few clicks. At around 0245pm Indian Standard Time, it was time for me to head back to our community booth for the second half of the Fedora Project representation duty and connect with Samyak for his assistance while returning.
Manifest M
Manoj Kumar Gupta, who was representing the virtualization team, remarked on just how influential Fedora Project's presence was at the community booth, all while reflecting on how the activity nearly died down in both Samyak's and my absence. He was right, though, as swag collectibles can be conversation starters for a bunch of people who might arrive at the event booth for collectible trinkets but also stay back for the interesting conversations that we have to offer. With our swag units displayed on the booth desk again and Samyak started the discussions, I got the FOSSUnited tees for us that Rajan had kept aside for the event sponsors. Seeking coffee with Sudhir at around 0400pm Indian Standard Time led us to have a great catch-up with him at the dining area. On heading back, Veer Kumar even graciously offered his specialized audio recording device for our interviews.
Manifest N
Being super occupied at the community booth, I could not attend Rajan's bite at the 2026 FOSSUnited GB Elections: Meet The Candidates Session. For someone who had been supporting Fedora Project's local presence in India as well as in the APAC region, it felt important to support him. Anyway, we started packing up the community booth at around 0515pm Indian Standard Time after attending to the booth visitors who had missed us during lunchtime. Thanks to Shivraj's query to the FOSSUnited personnel, we did not have to return to the hotel with all the booth supplies, as we could securely store them at the booth area. To ensure that Samyak had what he needed to organize the Fedora Linux 45 Release Party at a local university in the following month, I ensured that I passed on the limited swag units to him so that they could be returned before being used up on the next day.
Manifest O
For an in-person FOSS conference where Fedora Project could not timely secure a separate community booth, I scarcely imagined just how much attention we would eventually end up getting. With the folks from Red Hat being mutually supportive, since even they utilized Fedora Linux-powered Corporate Standard Builds on their work devices, this had been an experience like none other. Nine times out of ten, when Fedora Project was a conversation starter at our community booth, it was endearing to observe how most folks stayed back to learn more about projects like Shipwright, PyTorch, Tekton, Confidential Computing, and Ansible, etc. With our evening plans still being tentative at the time, our little Red Hat group decided to have some coffee on our way out. At around 0530pm Indian Standard Time, Samyak was finally able to book a returning Uber ride to take us back to the hotel.
Manifest P
The Bengaluru traffic situation only drifted from bad to worse as the sun started going down, so it took us a while to make it to the other side of the road where the auto-rickshaw had been waiting for us. We headed out once more on Deepesh's invitation to Brooks And Bonds Brewery at around 0730pm Indian Standard Time. Even though I did not hear back from Samyak for a little while when I had booked an Uber ride for us, he was swiftly available in the lobby area after a couple of hours of resting. Moving through the evening Bengaluru traffic, we were able to make it just in time to see Rajan, Shivraj, Veer Kumar, Gaurav, and Deepesh on their way upstairs in the building's elevator. For a dining experience that had been overbooked on that weekend evening, Deepesh definitely made the right call in booking us a large table well in advance to ensure that we were able to secure one.
Manifest Q
It was a lovely evening catching up with the folks over some nice drinks and tasty bites. Partitioning the dining table to place ourselves based on dietary preferences, we stuck around to see if we could get ourselves a table outdoors. With Samyak briefly checking with one of their attendees and returning empty-handed, we stuck around with the table that we had. Looking back on it, I would not have necessarily advised an outing like this in the evening if one was to wake up early the next day. I still found myself hanging back with the folks till 0130am Indian Standard Time. As luck would have had it, it was down to me again to set things up at the Red Hat Community Booth the next morning. I was uncertain about the task being fulfilled, so I wasted no time in falling asleep and recouping energy once Samyak and I were finally able to get an Uber ride back to the hotel at 0230am Indian Standard Time.
Linux draws a distinction between code running in kernel (kernel space) and applications running in userland (user space). This is enforced at the hardware level - in x86-speak1, kernel space code runs in ring 0 and user space code runs in ring 32. If you’re running in ring 3 and you attempt to touch memory that’s only accessible in ring 0, the hardware will raise a fault. No matter how privileged your ring 3 code, you don’t get to touch ring 0.
Kind of. In theory. Traditionally this wasn’t well enforced. At the most basic level, since root can load kernel modules, you could just build a kernel module that performed any kernel modifications you wanted and then have root load it. Technically user space code wasn’t modifying kernel space code, but the difference was pretty semantic rather than useful. But it got worse - root could also map memory ranges belonging to PCI devices3, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel4. Or root could modify special CPU registers (“Model Specific Registers”, or MSRs) that alter CPU behaviour via the /dev/msr interface, and compromise the kernel boundary that way.
It turns out that there were a number of ways root was effectively equivalent to ring 0, and the boundary was more about reliability (ie, a process running as root that ends up misbehaving should still only be able to crash itself rather than taking down the kernel with it) than security. After all, if you were root you could just replace the on-disk kernel with a backdoored one and reboot. Going deeper, you could replace the bootloader with one that automatically injected backdoors into a legitimate kernel image. We didn’t have any way to prevent this sort of thing, so attempting to harden the root/kernel boundary wasn’t especially interesting.
In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed5 systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what’s the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards? What ended up as the Lockdown Linux Security Module provides the tooling for this, blocking userspace interfaces that can be used to modify the kernel and enforcing that any modules have a trusted signature.
But that comes at something of a cost. Most of the features that Lockdown blocks are fairly niche, so the direct impact of having it enabled is small. Except that it also blocks hibernation6, and it turns out some people were using that. The obvious question is “what does hibernation have to do with keeping root out of kernel space”, and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there’s a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it’s a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker’s image, giving the attacker control over what gets copied back into kernel space.
This is annoying, because normally when we think about attacks on swap we mitigate it by requiring an encrypted swap partition. But in this case, our attacker is root, and so already has access to the plaintext version of the swap partition. Disk encryption doesn’t save us here. We need some way to verify that the hibernation image was written out by the kernel, not by root. And thankfully we have some tools for that.
Trusted Platform Modules (TPMs) are cryptographic coprocessors7 capable of doing things like generating encryption keys and then encrypting things with them. You can ask a TPM to encrypt something with a key that’s tied to that specific TPM - the OS has no access to the decryption key, and nor does any other TPM. So we can have the kernel generate an encryption key, encrypt part of the hibernation image with it, and then have the TPM encrypt it. We store the encrypted copy of the key in the hibernation image as well. On resume, the kernel reads the encrypted copy of the key, passes it to the TPM, gets the decrypted copy back and is able to verify the hibernation image.
That’s great! Except root can do exactly the same thing. This tells us the hibernation image was generated on this machine, but doesn’t tell us that it was done by the kernel. We need some way to be able to differentiate between keys that were generated in kernel and ones that were generated in userland. TPMs have the concept of “localities” (effectively privilege levels) that would be perfect for this. Userland is only able to access locality 0, so the kernel could simply use locality 1 to encrypt the key. Unfortunately, localities are typically only available on systems that implement a Dynamic Root of Trust Measurement like Intel’s TXT, and most consumer systems have no support for this. So, we need another approach.
TPMs have a set of Platform Configuration Registers (PCRs), intended for keeping a record of system state. The OS isn’t able to modify the PCRs directly. Instead, the OS provides a cryptographic hash of some material to the TPM. The TPM takes the existing PCR value, appends the new hash to that, and then stores the hash of the combination in the PCR - a process called “extension”. This means that the new value of the TPM depends not only on the value of the new data, it depends on the previous value of the PCR - and, in turn, that previous value depended on its previous value, and so on. The only way to get to a specific PCR value is to either (a) break the hash algorithm, or (b) perform exactly the same sequence of writes. On system reset the PCRs go back to a known value, and the entire process starts again.
Some PCRs are different. PCR 23, for example, can be reset back to its original value without resetting the system. We can make use of that. The first thing we need to do is to prevent userland from being able to reset or extend PCR 23 itself. All TPM accesses go through the kernel, so this is a simple matter of parsing the write before it’s sent to the TPM and returning an error if it’s a sensitive command that would touch PCR 23. We now know that any change in PCR 23’s state will be restricted to the kernel.
When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.
Unfortunately it turns out that some people actually make use of PCR 23, and
restricting it to the kernel makes them sad. There are other resettable PCRs, but only in non-0 localities, so (a) we can’t reset them on most systems and (b) we’ll just find someone who uses them anyway and run into the same problem. We need a different approach.
Thankfully TPMs have a small chunk of non-volatile RAM that can be used for storing things, and by “storing” I mean they can be used in a range of different ways. One of these is effectively as additional PCRs. These values can be configured such that they work the same way as PCRs, with the only way to modify them being to append a new hash to their existing value and update the new value to the hash of that merged value. We can allocate one of these for in-kernel use and reject any access from userspace, and also there are officially allocated ranges (so people shouldn’t be using random values) and the namespace is large enough anyway that w eshouldn’t collide with anyone, so we can carve one of those out and use it for this purpose.
Unfortunately, though, these NV indexes aren’t included in the creation data we get when we create a key, so we need another approach. TPMs have the concept of sessions, a series of commands executed in sequence. A flag allows these sessions to be “audited”, with the TPM keeping a running track of the hash of the commands executed and the results returned. At the end of the session you can ask for a signed copy of this hash, and if you’ve kept a log of all the commands then you can verify that they match that signed hash and know that this log represents a real communication with the TPM. If we read the NV index and generate the key inside the same session, we can verify that the key we’re looking at was created while the NV index had a specific value, and if only the kernel can set that value then we know that the key was generated by the kernel.
Or, well, can we? Only new kernels would impose the restriction on modifying that NV index. An attacker could boot an old kernel, generate a key there in userland, sign a hibernation image with it, and then reboot into a new kernel. The new kernel would see a valid signature with a valid NV index associated with it and have no way to know it was generated from userland rather than the kernel. We need to be able to tell the difference between kernels that implement this feature and ones that don’t, and we need to do that without being able to go back in time to change old kernel behaviour. We can extend a PCR to indicate we implement the new functionality, but so can an attacker running an old kernel.
The normal approach to determining whether an event occurred in a specific phase of the boot process is to “cap” the PCRs - extend them with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can’t fake the same PCR value afterwards. If Linux capped the PCRs before userland started running, we’d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the NV index restrictions there, and we’d be fine.
Unfortunately Linux doesn’t currently do this, and adding support for doing so doesn’t fix the problem - if an attacker boots a kernel that doesn’t cap a PCR, they can just cap it themselves from userland. So, we’re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this requires a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.
Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to NV indexes into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware’s out of spec then I don’t think there’s any real expectation of it being secure enough for any of this to buy you anything anyway.
That’s what this patchset does. Review feedback so far seems positive, although James Bottomley suggested a design improvement. My approach of using an NV index as a PCR and generating a signing key made sense as a consequence of my original approach involving PCR 23, which had been to use the key creation data and not use audit sessions at all. But the goal isn’t to use a key - it’s to prove that hibernation occurred in-kernel, and while signing is one way of doing that, there are others. His suggestion is to simply record the hash of the hibernation image into the NV index and then read that back as part of the audit session. On resume we verify the audit session log is legitimate, read the hibernation image, and compare the hash of the hibernation image against the hash in the log. If it matches, and if the PCR 5 value matches, we know the audit session happened in kernel and that the hibernation image hasn’t been modified.
It still seems like we’re missing something, though. If we’re not storing a key anywhere, how do we verify the audit session? To explain this we’re going to need to go into some details about how TPM keys work in the first place. TPMs can produce a special kind of key called an Attestation Key, or AK. Attestation keys are used to sign attestation statements from the TPM, such as PCR quotes or audit logs. We need a separate key type for this in order to prove that the signature was generated as part of an attestation - normal TPM signing keys are fundamentally designed to sign arbitrary material, and so can be used by userland to sign something that looks identical to an attestation record. By being able to distinguish the types of key the TPM uses, we can prove that a signature was generated using an AK, and so know that it’s a real TPM attestation (because nothing other than the TPM can sign stuff with an AK).
But even beyond this distinction, TPMs have different key types. Ordinary keys are generated using an RNG and will be unique. Primary keys are generated using a seed that is used as an input into a key derivation function. For a given TPM, using the same seed to generate the same type of primary key will always generate the same primary key8. We can have the kernel deterministically generate an AK during suspend in order to sign the audit log, and then generate the same key again on resume to validate it. This means we don’t need any other form of trusted storage for the AK - the TPM already provides that functionality.
This is all rather complicated but I’ve been thinking about this for some time now and I haven’t come up with a cleaner solution. The only real open issue is the degree to which machines actually perform the PCR 5 extension. If it turns out there’s a bunch that don’t we’ll need to come up with some alternative approach to identifying whether the kernel supports this functionality, but the design is such that that should be invisible to userspace so adding alternatives later shouldn’t be an issue. Filtering accesses to the NV index is also not super clean, and depends on there not being alternative mechanisms to get at the TPM by sending raw commands. Again, this is intended to be opaque to userland and can be improved if we come up with something better later on (such as a secure way to pass a secret to the kernel on boot that can be used as an auth value for acess to the NV index).
Anyway. Time to go and fix the next thing.
Other architectures use different terminology here, such as “supervisor” and “user” mode, but it’s broadly equivalent ↩︎
In theory rings 1 and 2 would allow you to run drivers with privileges somewhere between full kernel access and userland applications, but in reality we just don’t talk about them in polite company ↩︎
This is how graphics worked in Linux before kernel modesetting turned up. XFree86 would just map your GPU’s registers into userland and poke them directly. This was not a huge win for stability ↩︎
IOMMUs can help you here, by restricting the memory PCI devices can DMA to or from. The kernel then gets to allocate ranges for device buffers and configure the IOMMU such that the device can’t DMA to anything else. Except that region of memory may still contain sensitive material such as function pointers, and attacks like this can still cause you problems as a result. ↩︎
This describes why I’m using “allowed” rather than “required” here ↩︎
Saving the system state to disk and powering down the platform entirely - significantly slower than suspending the system while keeping state in RAM, but also resilient against the system losing power. ↩︎
With some handwaving around “coprocessor”. TPMs can’t be part of the OS or the system firmware, but they don’t technically need to be an independent component. Intel have a TPM implementation that runs on the Management Engine, a separate processor built into the motherboard chipset. AMD have one that runs on the Platform Security Processor, a small ARM core built into their CPU. Various ARM implementations run a TPM in Trustzone, a special CPU mode that (in theory) is able to access resources that are entirely blocked off from anything running in the OS, kernel or otherwise. ↩︎
Unless the TPM is cleared, in which case it’ll generate a new internal seed and now the keys will be different to before the clear ↩︎
Py (daughter) is still struggling to read Bengali text, as she was not reading it everyday. And on top of that Bengali script has many complex Bangla (Bengali) conjuncts (ক্ষ, জ্ঞ, ষ্ণ, ঙ্ক), and Py could not remember all the characters and had to go back and find them.
So now I am using https://ektubangla.org where anyone (a teacher/ parent) can click to "Create a session" and type in any Bengali text, and the students/readers can see the reader board where each word is broken into letters, so that the new reader can easily pick up what those letters are.
The conjuncts are also colored differently in the text and broken into letters properly. Py is super happy to use to read much longer texts. I hope this will be helpful for more parents/teachers.
LinuxDays 2026, the largest open-source event in Czechia, took place on the first weekend of October, and we had a Fedora & CentOS booth there again. This time, we got a smaller table and our booth equipment was more modest because no one traveled from Brno by car—we only had what we could carry on the train. However, we had quite a few nice stickers and one Framework laptop, which generated a lot of attention again.
I was happy that I didn’t have to staff the booth alone; I was accompanied by Vojtěch Trefny, a long-time Fedora contributor.
Even though CentOS Stream has existed for seven years now, we still received questions like: “Oh, CentOS is still alive? I thought Red Hat killed it a long time ago.” This was typically the starting point for a conversation about the differences between the original CentOS and CentOS Stream, as well as their relation to Red Hat Enterprise Linux.
Most questions about Fedora were related to Framework, which didn’t come as a surprise given that we were showcasing Fedora Linux 45 on a Framework Laptop 16. People asked whether there is any cooperation between Fedora and Framework, whether Fedora Linux is a good OS for Framework hardware, and whether Framework is a good laptop option for Fedora Linux. To all of that, we had very positive answers.
It was an exhausting weekend because we had dozens of conversations, but it was also refreshing to meet Fedora and CentOS users and hear feedback directly from them. I’d like to thank Fedora for sponsoring my trip and Vojtěch for helping me with the booth.
No single person can know everything happening in Fedora at any given time.
I say this often in our community, half as a warning and half for comfort.
For a while, I did not really believe it applied to me.
I wanted to know everything.
I joined new teams, participated in tickets, and either participated or led meetings across the project.
Surprisingly, as a young university student, I held a vast amount of it in my head.
But Fedora does not stand still long enough for that to last.
Eventually, I was spread thin across more teams than I could realistically track.
As my academic load increased or I began an internship, promises I made quietly fell off my radar.
It was not because I did not care.
It was because the systems I used to track them could not keep up with the sprawl, when my available time to contribute changed.
However, as I reentered the Fedora community as a Red Hat employee, the same systems I used as a student were challenged.
As I get going with my new role, I am rethinking how I can rebalance my bandwidth sustainably.
So, this post is about how I started managing multiple Git repos with AI agents to claw back some of that bandwidth.
It is not really a story about a remarkable tool.
It is an argument that in a project this sprawling, protecting your attention is the real win.
I will cover two moments when things fell through the cracks, the workflow I built to catch them, a real example of it working, and an honest take on trusting AI when it sometimes gets things wrong.
Why managing multiple Git repos gets hard at Fedora’s scale 🔗
Fedora is sprawling.
Fedora’s distribution Git (dist-git), the home for package sources, holds something like 20,000 packages.
Add the team and SIG repositories that coordinate the people behind those packages on Fedora Forge, and the number of places where decisions get made is enormous.
Yet, most contributors only touch a handful of them.
However, even a handful is often scattered across different platforms, with no single view of all of it.
Before this workflow, it felt like pure chaos, and I have the scars to prove it.
Fedora runs on mailing lists, Fedora Discussion topics, Matrix chat rooms, and Fedora Forge issues/tickets.
Furthermore, all of these are spread across dozens of teams, Working Groups (WGs), and Special Interest Groups (SIGs).
In short, there are a lot of different places to follow a lot of different things.
For a long stretch, the Fedora Marketing Team had a backlog of tickets.
In a few cases, contributors asked for talks and presentations to be uploaded to the Fedora YouTube channel.
I had the access to do it and other YouTube maintainers were no longer active, so therefore, it was quietly mine to own.
I saw the tickets at least once, but I was overworked and busy with higher-priority work.
The YouTube videos slid off my list.
A new volunteer eventually picked them up months or even a year later.
Additionally, Fedora also runs meetings well… on paper.
Fedora holds virtual text meetings in Matrix chat rooms with a bot that logs everything.
Each meeting has a clear start, a clear end, and annotated topics.
But a faithful log is not the same as follow-through.
For example, in AI/ML SIG meetings, we discuss a decision or someone takes an action item, and it gets logged.
But it does not always make it back into the relevant ticket or discussion post.
The record exists, but it does not connect itself to the places that need updating.
Patterns like this repeat themselves.
The examples above are merely specific examples of where things fall through the cracks.
However, there are things like this that happen everyday in different corners of the community too.
So, here is the workflow I use now.
It does not get rid of all the chaos, but it helps me manage it much better.
First, I point an LLM-gen-AI agent at a directory holding several cloned Git repositories.
For example, the AI/ML SIG docs repository, AI/ML SIG tickets repository, and Agent Skills library.
Then I ask it to analyze across all of them.
I also feed it meeting logs or summaries.
I ask it to cross-check them against open tickets and Fedora Discussion topics:
Did we document the decisions?
Did we track the action items?
Is anyone still waiting on a reply?
Critically, I do not want it reading only files from my local git clones.
I want it to query the remotes too: the Fedora Forge API, issues, discussions, and more.
The underlying Forgejo API is enormous.
It lets the agent track the actual cadence a team works at, not just a snapshot.
I have to be honest here: the agent sometimes gets things wrong.
It will occasionally misread a thread or hallucinate a detail.
However, I do not think that disqualifies it.
Humans get things wrong too.
I would rather have slightly imperfect visibility into tens, hundreds, or even thousands of repositories than none at all.
Ultimately, the question is not whether the agent is ever wrong.
The question is what level of risk you are willing to accept for the visibility you gain.
A real example: Reviewer guidelines across three repos 🔗
Our Fedora Agent Skills Library needed reviewer guidelines.
Laura Barcziová (@lbarczio), on our reviewer team, wrote a solid REVIEWING.md in the ai-ml/skills-library repo.
But our separate ai-ml/docs repository only had a page on creating a skill, and nothing on reviewing one.
I used an agent in OpenCode to pull discussion context from Fedora Forge issues about our reviewer process.
It helped me reconcile that context with Laura’s draft.
Then I orchestrated multiple Pull Requests across the repositories at once.
This brought the AI/ML SIG docs site in line with what the team had actually decided.
In conclusion, the payoff is that it hands me back the capacity to zoom out.
In a project where nobody can hold it all in their head, something should watch dozens of repositories.
It surfaces what changed and what needs to catch up.
That means I can engage with people’s feedback instead of just surviving the volume of it.
When someone takes the time to review my Pull Request, I want the bandwidth to genuinely consider what they said.
I do not want to just clear my queue.
I hope this overview of my flow and process is insightful.
As of yet, I do not have a commenting feature on my blog, although I am looking into this.
Tag me in a LinkedIn post and we can continue the conversation there.
Original photo by DM David on Unsplash.
Modified by Justin Wheeler.
Modified cover photo exclusively distributed under CC BY-SA 4.0.
This year’s edition of International Calligraphy Festival Keralam was yet another great experience, consisting of workshops, demonstrations and talks surrounding calligraphy & typography, much like the last time. Eminent calligraphers of about a dozen scripts shared their expertise and experience.
Pictures of a sample collection of the calligraphy works at the exhibition below.
For my talk, I presented the historical evolution of Malayalam script from rock inscriptions to the digital age, and how the vigilant volunteer community reclaimed the script with its rich conjuncts and conjoined reph/matra shapes, and made all the foundational digital technologies openly available for public good.
Many type designers, companies and enthusiasts were also at the 4-day programme, enabling lot of productive hallway talks as well. A recurring question was the usage of Open Font License, which I hope to have helped to clarify.
The most useful feedback after the talk came from a good friend, who pointed that my slides didn’t do enough justice to the body of work we’ve done (particularly as open-source); and helped me walk through some possible improvements. I did make some of those changes, and the slides (created using TeX) are made available.
I started with API keys and tokens leaking into agent context, went through CLAUDE.md rules and fetching secrets on demand from 1Password, and ended up at sandboxed agents, MCP servers that hold the credentials, and one-hour GitHub and GitLab tokens on a dedicated identity.
Découvrez les nouveautés de SeedboxSync v4.3 : migration vers Bootstrap, refonte du dashboard et des statistiques, rendu CLI modernisé avec rich.table, ajout d'un widget pour Homepage et correction d'un bug critique sur les arborescences profondes.
Retour d'expérience sur ma migration vers Fedora 45 bêta sur mon laptop Asus : mise à jour fluide, déplacement des fichiers de configuration des dépôts vers /usr/share/dnf5/repos.d, migration de mes paquets Copr, bascule de mes Flatpaks du système vers le profil utilisateur et sélection de quelques indispensables.
Marking the second Indian FOSS event for me, day zero of IndiaFOSS 2026 by FOSSUnited Organization had the Maintainer Summit planned for it. This had a separate registration apart from the main conference and hence had a smaller footfall at Samagata Foundation. As the invitation email required us attendees to be at the venue at 0900am Indian Standard Time sharp, I decided to get a head start to beat the Bengaluru traffic on Friday, 25th September 2026. As I had my hotel check-in later on that day, I also had to make a brief stop at SRS Springs And Spa Hotel to leave my luggage before finally making it to the event venue. Leaving on an Uber ride at around 0730am Indian Standard Time from Yelahanka Crossing, I surprisingly witnessed much lighter morning traffic than I expected while heading from the outskirts into the metaphoric heart of Bengaluru city.
Simply put, I seemed to have greatly overestimated the traffic situation. Or maybe it was the Friday morning doing wonders. I was able to reach the first stop by around 0815am Indian Standard Time, giving me roughly 45 minutes to cover the next distance. Leaving my check-in luggage with the trusty receptionist of SRS Springs and Spa Hotel, I chatted with the fellow members on the event's official Telegram group until I reached my stop. I was almost certain that I was one of the first folks to make it to Samagata Foundation, after being helped by Ansh Arora in navigating the sprawling center. While Rajan Shah assured me of his availability, he also mentioned that he would join later with Veer Kumar Patil, Shivraj Patil, Deepesh Nair, and Gaurav Kamathe. That not only meant that I was on my own there but also that I had a great opportunity to make some new Fedora friends too!
Manifest A
With the attendees slowly rolling in and leaving their stickers on the swag desk, I made it a point to hand out the Fedora Project round badge / magnet combo to folks I had conversations with. This helped me manage the limited swag inventory wisely while keeping me on my toes to seek out new conversations to be a part of. Many of these FOSS friends were either already aware of the Fedora Project and or were using Fedora Linux, which made it a lot easier for me to seek out possible contributors among the prolific crowd of FOSS maintainers. One such chat that made a lasting, mutually beneficial impact was with the Tangled Project members, who wanted to learn about my progress with the migration from Pagure to Forgejo within the Fedora Project community. We shared our frustrations with the various Git hosting services while we waited for the event organizers to arrive there.
While Forgejo was a fork of Gitea, which itself was a fork of Gogs, Tangled seemed to be built from the ground up and was an interesting external case study to learn features from as we were contributing to the Forgejo upstream. With various other chats on knowledge, localization, programming and community with maintainers, I also ran into people who recognized me instantly from my previous adventures earlier that year in DevConf.IN 2026 and FOSSAsia 2026. As an elected Fedora Mindshare representative who was also a part of the Fedora Council then, this sign meant that our efforts with establishing regional community presence in the APAC region were clearly working. All we had to do was continue doing just that in order to help the adoption of Fedora Linux among users and awareness of the Fedora Project among enthusiasts in a region which was largely ignored until 2025–2026.
Manifest B
Ansh kicked off the unconference-styled Maintainer Summit's event proceedings with his opening note as we gathered at the whiteboard with our sticky notes to propose things that we wanted to discuss. We had varying degrees of success with the instruments like the sticky notes and markers, but it was hilarious to see just how many maintainers it took to redo the entire board with thumbtacks and a stick board. After proposing Contributor Retention in FOSS Communities, I decided to hang back and help out the fellow organizers. In our passing chats, I could not help but notice a healthy skepticism about using generative tooling along with an overriding enthusiasm for where the technology was headed. I, however, did find myself being psychologically alienated from chats that were bordering on virtue signaling about the general utilization of artificial intelligence-based technologies.
In the times when conversations on artificial intelligence were just unavoidable, I wanted to spend more effort exploring how the technology could be evolved more instead of debating its usage prescriptions. I loved just how the event attendees were a healthy mix of technical individuals and non-technical enthusiasts, both of them desiring to understand the core requirements of the other persona. For the first part, I decided to join the contemporary Git Hosting discussion chaired by the Tangled Project contributing maintainers, along with Veer Kumar and Gaurav, who had arrived at the event venue by then. It felt great to meet up with them at yet another APAC conference, along with Rajan, Deepesh and Shivraj, after our last meetings at DevConf.IN 2026 and FOSSAsia 2026, especially with Rajan also standing for the FOSSUnited Organization governing body elections at that time.
Manifest C
Joining in the maintainer discussions around semantic diffs in various Git hosting services and the general need for workflow evolution, I was genuinely surprised to see just how other maintainers faced the same problems that the Fedora Project had been facing for many years. We passed around a smartphone (to act as a mic) in our small groups as we took turns with what we had to say. As the review system had more or less remained the same for a decade now, I stressed how crucial it had become for the various Git hosting services to use generative tooling to provide semantic diffs in order to help streamline collaboration among maintainers and contributors. We reflected upon and agreed on how the wider accessibility of generative tooling had already made it increasingly difficult for fellow maintainers to review large volumes of codebase changes within reasonable turnaround times.
As time passed by, I was surprised to see just how much my proposed topic on Contributor Retention in FOSS Communities amassed supporting sticky notes. All the support my topic ended up getting moved us from a corner area to the center of the conference. Since it was scheduled for 1200pm Indian Standard Time, Rajan and I briefly joined the discussion on India's Digital Personal Data Protection Act and how it compared with Europe's General Data Protection Regulation Act. Apart from the comparisons, we also delved deeper into the maintainer's responsibilities with data protection and how the policy required general awareness for effective enforcement. Touching on the related topics of Europe's Cyber Resilience Act and the United States' Federal Risk and Authorization Management Program, we also distinguished between the roles of software authors and service administrators.
Manifest D
Exploring the frequent Aadhaar data leaks, we reflected on just how important it is for citizens to hold the policymakers accountable for these. While a CRA analogue for India would take a while to come into being, we discussed the best practices for FOSS maintainers to ensure preliminary data safety at their ends on an architectural level. Various case studies were brought up where data security and policy validation were seen as a chore rather than a fundamental responsibility—an observation that I vocally protested about, as a similar attitude towards privacy is what empowers bad actors to discover loopholes in a security policy. Finishing off with this discussion paved the way for the one added by me, and I soon found myself arranging the chairs while preparing for the attendees to arrive. Even when we started off with just five folks, we quickly ballooned to over twenty in no time.
With almost one-third of the unconference population at our discussion, I started off the discussion at around 1215pm Indian Standard Time. We went around the attendees—both technical and managerial in nature—to explore their onboarding experiences from their communities. I was interested to know how the interactions with first-time newcoming contributors went and what made them feel like staying back in a community after their first contribution activity was completed. Gaurav gracefully allowed his iPhone to be used as a mic, and amidst various experiences, I shared a demo of how we incentivized contributions in the Fedora Project with the use of the Fedora Badges platform. As a solution that scaled pretty well across various-sized FOSS communities, they appreciated how this solution could help immensely when shipping swag or attending events could be very difficult.
Manifest E
I appreciated how grounded the conversation was, with people realizing that most of the time, people simply appreciate it if their activities are reviewed in time and not left in a metaphoric limbo. While artificial intelligence-based generative tools ensured that the entry barrier was lowered, to the point that even bad actors went on with spamming activities, we also reflected on just how it was hurting the fellow maintainers. Even Ansh could not help joining in on the chat with his experiences while we were waiting for lunch, and at around 0115pm Indian Standard Time, we were finally done with the first half of the day. Joining a queue a little later with my Red Hat friends, I got myself some plain and simple Indian meal with chapatis, pulses, rice, vegetables and sweets. I loved how the healthy lunch represented the Indian hospitality of the unconference event, much akin to FOSSAsia 2026's food.
Hanging out with the likes of Darsh Shah and Shrirang Kahale during lunch, Deepesh showcased his solar-powered self-hosting homelab. We were pleasantly surprised to learn how Shrirang ran eight GNU/Linux mirrors across the country, all while being in his second year of engineering study. With the Red Hat friends leaving at around 0230pm Indian Standard Time after the mealtime discussions, I hung back to see which chats I wanted to be a part of. After briefly joining the one run by the FOSS maintainers from the Wikimedia Foundation, I had a fairly good and engaging discussion around the usage of artificial intelligence for the starter template before ensuring a human review. My analogue to the healthy skepticism was to utilize generative tooling to fill metaphoric potholes on a figurative road created by humans, and avoid doing things the other way around, if possible.
Manifest F
Plagued by the experiences of LLMs basing their output on citations and resources that most likely do not exist, we reflected on the potential stress on reviewers using human time and effort on them. Observing the growing virtue-signaling around artificial intelligence technologies again, I silently resigned myself to calling it a day at around 0400pm Indian Standard Time. Shrirang and I had some Samosas, and after bidding farewell to Poruri Sai Rahul and Ansh, we decided to depart on an Uber ride waiting for us. As much as I wanted to stay back until the evening for the full-course Maintainer Summit event experience, I knew I had other important things to take care of. Not only did I have to check into the hotel after collecting my luggage from the reception, but I also had to prepare for the first day of IndiaFOSS 2026 to represent the Fedora Project alongside our fellow Red Hat associates.
The third quarter of 2026 is over, and so in this post we'd like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn't be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify … Continue reading Heroes of Fedora Quality for Q3 2026→
Attending the Agentic AI for Science workshop at MPCDF in Garching got me thinking about the platforms we are starting to build our scientific workflows around. The workshop programme brings together hands-on work with agents, examples from scientific software development and materials simulations, and perspectives from industry. For someone interested in free and open-source software, this raises some familiar questions: who controls those platforms, what can we change ourselves, and how much of our work can we take elsewhere?
What interests me here is the software around the model. An agent harness gives the model tools, supplies context, and controls what it can do. The flagship GPT, Claude, and Gemini models are proprietary, but the software using them does not have to be (and often isn't). We can use the same model through different harnesses, with different licenses, tools, and restrictions. Choosing the model, deciding where it runs, and choosing the harness are separate decisions, even when a product offering bundles them together.
A few harnesses and development environments for programming, scientific workflows, and other tasks illustrate these differences. This is only part of the picture: agents embedded in enterprise applications bring their own integrations and dependencies.
This led me to a somewhat loose comparison: Claude Code reminds me of Windows, Codex CLI of BSD, OpenCode and the like of Linux, and Antigravity of the Macintosh. Each comparison emphasizes something different: compatibility, permissive reuse, independence from suppliers, or the appeal of an integrated experience.
If you have used Claude Code in a terminal, the first part probably sounds wrong already. How does a program that reads files, invokes shell tools, and fits into a Unix workflow resemble Windows? Bear with me. The resemblance is in how people build tools and workflows around the software, rather than how its interface looks.
The Podman and Fedora Quality teams are organizing a test week from Monday, October 12, through Sunday, October 18, 2026. We want your help testing conmon v3, the Rust-based container monitor used with Podman. If you use Podman, try the same containers and commands with conmon v3 and report any differences.
Why we’re testing conmon v3
Conmon is the small process that keeps watching a container after the Podman command that started it has finished. Podman uses an OCI runtime such as crun or runc to start the container; conmon attaches to its input and output, provides the connection for podman attach, collects logs, and records its exit status.
Conmon v3 replaces the C implementation with a Rust version. This helps prevent common memory errors in safe code. It also gives the logging backends a shared interface, making them easier to extend and test.
We already run Podman’s system tests against conmon v3. Now we’d like help checking development containers, interactive sessions, and Quadlet services on other people’s setups.
Getting started
We’ve prepared a test week wiki page with setup instructions, links to the test cases, and information on reporting results. Start there to check the Fedora and package requirements, then use a test machine or VM with no important data.
Install the new monitor with this command:
sudo dnf install conmon-v3
To select it system-wide, create /etc/containers/containers.conf.d/99-conmon-v3.conf with the following content:
[engine] conmon_path = ["/usr/bin/conmon-v3"]
Run podman info and check that the conmon path is /usr/bin/conmon-v3 and its version starts with 3. If you use both rootless and rootful Podman, check sudo podman info as well. User configuration can override the system setting.
Start new test containers after making this change. Containers that are already running retain their existing monitor.
To switch back after testing, remove the drop-in. New containers will then use your previous configuration.
What to test
Here are the areas we’d particularly like you to check:
Open an interactive shell, resize the terminal, and detach and attach again.
Run podman exec, including interactive commands, and check the output and exit status.
Check file and journald logs with large output and lines without a final newline.
Start, stop, and restart containers, including services managed by Quadlet or systemd.
Try rootless or rootful Podman, and crun or runc where available.
Watch for hangs, missing output, incorrect exit statuses, unexpected CPU usage, or behaviour that differs from conmon v2. The wiki links to the test cases, which include the conmon-specific checks.
Results and help
Record your results in the test day application. Please record successful tests too. They tell us which setups have been checked.
Report conmon problems in the conmon v3 issue tracker. For other Podman issues, follow the bug-reporting instructions on the wiki page. Include your Fedora version, relevant package versions, reproduction steps, relevant logs, and the output of this command:
podman info --debug
Link the bug report when submitting your test result.
This article was co-written by Petr Sklenar and Jan Kaluza.
Note about AI usage: : The core technical content and claims are completely our own. Claude (Anthropic) was used only as an editing tool to enhance grammar and readability.
Does syslog-ng support the latest OpenSearch version? I suspected that the answer was yes, but I gave it a try anyway. And as expected, starting to use OpenSearch 3.9 with syslog-ng is a smooth experience. My only problem? Finding a password complex enough for OpenSearch.
Après 12 ans, ma balance Withings a rendu l'âme. L'occasion idéale pour abandonner MyFitnessPal, auto-héberger la synchronisation de mes données de poids vers Garmin et automatiser le flux vers Strava via n8n.
A bit late with the weekly recap this week, possible due to lower energy
from getting my flu and covid boosters friday, but lets go...
Mass update/reboot
The mass update reboot cycle went pretty well. We also applied firmware to
all the machines that had updates, which always takes a while, but probibly
is worth it.
Database server upgrades
Also, as part of the outage on thursday to do the outage causing hosts updates
and reboots, we moved all our database servers over to postgresql 18, rhel10,
and the latest timescaledb (in the case of db-datanommer).
That also went reasonably well, and we shouldn't have to do that
again for a while.
Fedora 45 infrastructure freeze coming up
This coming tuesday is the start of the infrastructure freeze for fedora 45
final release.
Out next weekend
I'm out next friday through sunday, heading to seattle for a rust concert.
I'm planning on taking the train, so that should be fun, but there will
not really be a recap next weekend. :)
I have begun adding git repositories on my GitHub instance with code samples in a variety of programming languages. These languages are C, C++, Java and others as time passes. These samples may help people in their learning of coding, but it also is fun for me to write basic programs in varying languages and keep my hand in.
Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.
There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.
Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.
Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)
AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.
That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.
Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.
Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.
We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.
When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.
Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.
Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.
Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.
The CVE Wave Hits GNOME
The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:
Year
GNOME CVEs
GNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt
2021
21
14
2022
14
6
2023
13
4
2024
37
28
2025
97
49
2026 Year-to-date (2026-09-30)
141
74
2026 Normalized
188 (141 * 4 / 3)
99 (74 * 4 / 3)
The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.
(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)
Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.
CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.
There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.
I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.
Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program
My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)
The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.
I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:
Year
Reports Submitted
Reports Accepted
2024
26
14
2025
150
33
2026
122
24
Total
298
71
Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.
After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.
At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.
Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.
Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.
Lessons from the Bug Bounty Program
Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.
I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.
I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.
A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.
Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.
Red Hat Scans GLib
Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.
Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.
I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.
It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.
Humans Still Useful
In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in criticalfindings.
Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.
Humanity Still Desired
Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.
We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.
Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:
Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.
Maintain Perspective
Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.
I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.
Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.
Rust
Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.
Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
To Be Continued…
I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.
Some like myself change many settings in whichever Operating System (OS) we are using. Under MacOS I change the naming for screenshots. On the commandline it can be accomplished with the command below.
defaults write com.apple.screencapture name "YourCustomName"
This weekend has become the one where I have setup my new Elegoo Neptune Pro 3 3D printer. We will be testing and getting used to the device and working towards building some useful projects.
One of the first projects is to print cases for my Arduino UNO R3 devices.
Watch this space for future projects that incorporate 3D printed elements.
As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).
Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:
Hi, I request a CVE for:
Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:
Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.
GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.
Quick one this week.
I really liked the sustainability post by Etsy. They are about measuring stuff and advocating for change in the industry.
Quote of the Week
How does a manager motivate his subordinates? For most of us, the word implies doing something to another person. But I don’t think that can happen, because motivation has to come from within somebody. Accordingly, all a manager can do is create an environment in which motivated people can flourish.
Fedora Infrastructure team will be applying updates to servers and rebooting them.
Many services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to firmware upgrades.
There will be a Fedora Copr outage while we upgrade infrastructure
machines to the latest Copr packages.
The build queue processing will be stopped during the outage, and the
Frontend/Web-UI will be down most of the time (no new tasks accepted).
The DNF packages and repositories (hosted on copr-backend …
I felt left out whenever I saw a new version with new hacks being released.
Recently I stumbled over retrosaver by c-premus. It is basically a workaround to run the hacks on GNOME Wayland. It doesn’t lock the screen and leaves that to GNOME, so it isn’t really a replacement for XScreenSaver. At home, this is probably good enough.
If your project has a domain, you may accept inbound email. And if you accept inbound email, you may offer email addresses to contributors. And this can get complicated.
In 2026, you are almost certainly not running a full-fledged mail service for your project. By which I mean you don’t provide accounts that can send, receive, and store email from a server that you run. Because we cannot behave ourselves, the email industry has attempted to adopt stronger security practices. The end result of which is that if you’re running your own email server, a lot of the mail you send gets send to the recipient’s spam folder (or worse: dropped by the server). This is 100% not a valuable use of time for an open source project. But just because you’re not running a full email system, that doesn’t mean you can’t give your contributors aliases that point to their real inboxes.
Why would you do this? Well, it can be a (basically) free way to reward regular contributors. Giving them a project email address is a form of recognition. It’s a status symbol that they can take pride in. Plus, it has some practical advantages. They can use it as a filtering tool: mail sent to bcotton@coolfossproject.example.org may end up in the same account as all of my other email, but I can filter anything sent to that address to my “Cool FOSS Project” folder. It’s also a signal to others that I am doing work on behalf of the project.
Unfortunately, the asymmetry of email services makes this (particularly the last time) less effective than it once was. A lot of people, myself included, would use the project email alias in a “send as” setup so that we could not only receive email using the alias, but (appear to) send it, as well. A big chunk of the world uses GMail for email, and GMail will no longer support sending from third-party addresses beginning in January 2027.
So should you still provide project emails? I wouldn’t go out of the way to at this point. But if you have the pieces in place for other reasons, it’s a nice thing to offer your contributors.
It has been a while since my last post. I am still recovering from a serious illness and major operation. I will be posting more now I am better and truly on the mend.
Coming up will be some new projects using Single Board Computers (SBCs) and also some robotics work.
