(This is an updated version of an older post - the introduction remains the same, the technical details are different)

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-speak¹, kernel space code runs in ring 0 and user space code runs in ring 3². 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 devices³, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel⁴. 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 allowed⁵ 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 hibernation⁶, 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 coprocessors⁷ 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 key⁸. 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.

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.

I remember back in 2020, people were complaining that we didn’t have enough documentation for creating GNOME Shell extensions. They said it was almost impossible to figure out where to start. They were right, learning all of it without proper documentation was a huge challenge for me too.

So, I decided to learn the GNOME Shell source code and shared what I learned in a YouTube tutorial series. I spent countless hours learning and making those videos, and the community was very happy to finally have guides and documentation.

On the GNOME side, Sriram Ramkrishna started the GNOME Extensions Rebooted project. When he noticed my tutorials, he invited me to join the team to help write documentation. I spent many hours learning GTK4 and the GNOME Shell 40 source code to write the famous GNOME Shell 40 Port Guide. I’d argue that many extension authors would have given up without it. Migrating from GTK3 to GTK4 and adapting to the changes between 3.38 and 40 was overwhelming. I wrote the guide with many examples, so developers could easily understand how to port their code.

Today we have all the documentation needed to start and maintain extensions, but nowadays, people are just simply vibe coding GNOME Shell extensions without reading any of it before submitting it to EGO. To be honest, in the age of LLMs, it feels like our documentation is feeding LLMs more than actual human developers.

For years, I tried my best to help the community, answering questions daily and reviewing extensions submitted to EGO, often spending 4 to 10 hours a day managing the whole extensions eco system. GNOME was incredibly generous this year and awarded me the GNOME Pants Award 2026 for my contributions to GNOME and the extensions ecosystem. That was a major personal milestone, and honestly, a testament to the growth of our community as a whole.

I’m writing this post because since early 2025, the volume of submissions has exploded. The vast majority are AI generated, and the huge workload is pushing me close to burnout. To be clear, all of my work is unpaid. While managing this volume easily matches a full-time job, my monthly donations remain close to zero. Given how many people use GNOME extensions daily, I truly believe our community can help make this workload doable. If you find value in what I do or if my work has helped you out over the years, please consider supporting me through donations. Without financial support, I simply won’t be able to keep going at this pace.

AI generated extensions, especially when prompted by non developers are frequently bloated and poorly designed. Because extensions run directly inside the GNOME Shell process, quality control is critical. Low-quality, AI generated code directly threatens the stability of the entire shell, and vibe coders need to realize that. As someone who reviews code across all of EGO, I can tell you that LLMs produce needlessly complex, hard to read code that takes significantly longer to review. To make matters worse, some submitters rely on AI to generate replies during the review process. I even received a response that accidentally pasted the LLM’s instructions intended for the user:

Then, respond to the specific points it points to and maintain a real public repository, with testing instructions and development history. This gives the base reviewer to evaluate maintenance and quality, without trying to hide anything.

On a positive note, a while back I published An Open Letter to AI for Generating GNOME Shell Extensions to fix specific code patterns their models were generating incorrectly and I noticed most of those issues disappear just a few weeks after that post, which is great news, but also proof of just how heavily our documentation is feeding these LLMs.

Anyway, we need viable solutions to keep the EGO ecosystem stable, trustworthy, and sustainable:

• I’m asking developers who understand GTK and GNOME Shell source code to join the review team. I am happy to mentor and teach you the review process. Please note that while this is a volunteer role, we need people who can be consistently available during the week.
• As many of you know, we introduced the Shexli linter a few months ago to make the review process easier. We need someone to help us improve it. The workflow is straightforward: reviewers identify false negatives and false positives during reviews, and you fix them in Shexli.

If you are interested in joining the review team or helping with Shexli, please reach out to us on GNOME Extensions Matrix channel. Thanks for being part of the GNOME community!

Week 33

This week's icon is for Tau Gärtli's project:
Ripples: "Rip CDs"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

Update on what happened across the GNOME project in the week from October 2 to October 9.

GNOME Circle Apps and Libraries

Brage Fuglseth reports

This week Concessio was accepted into GNOME Circle. Concessio helps you understand and convert between unix permissions representations. Congratulations!

Ronnie Nissan reports

This week I released Concessio version 1.0.0. I am very proud that it got accepted into GNOME circle as announced above, it also got the following improvements.

• A full rewrite from Gjs to Vala, making Concessio very fast, the code base clean and easier to contribute to.
• Redesigned the file opening workflow
• Added drag and drop support for opening files
• Added support for changing file permissions, with the ability to undo changes
• Improved the umask calculator to calculate from umask, file, or directory permissions
• Improved accessibility throughout the app
• Improved input validation and editing behavior
• Updated translations

I am also working on writing libacl binding for vala so I can add ACLs support to Concessio later on, if you have experience with writing bindings and this project interests you, please reach out. Thanks!

Third Party Projects

Ronnie Nissan says

This week I also updated my other apps, Sitra and Embellish.

They both got the latest GNOME runtime 51, Embellish also was also updated to NerdFonts v3.5.1 which adds the messing Devicons that were promised in v3.5.0.

I would also like to announce that I am looking for a maintainer for Sitra, if anyone is interested in a Vala GTK4+Libadwaita program, please reach out, if I find you are willing to take care of the project, I will hand it over completely.

Tanay announces

Whisp V1.6.0 -Runtime Update and Fixes

New Features

• Note Statistics (::count): Type ::count anywhere in your note to instantly inspect word, character, and line count statistics.
• Asterisk Lists: Create and format bulleted lists using standard asterisks (*) alongside dash lists.
• Shortcut Recorder Improvements: Pressing Backspace inside the shortcut recorder now cleanly clears or disables assigned shortcuts.

Fixes & Maintenance

• List Toggling Refactor: Fixed Ctrl+S list item toggling to prevent multi-checkbox stacking and unintended line deletions.
• GNOME 51 Runtime: Updated Flatpak runtime to GNOME 51.
• Slate Mode Polish: Fixed update notification banner layout in Slate Mode.
• Compose Key Fix: Corrected key press handling for Compose Key combinations.
• Ubuntu Icon & D-Bus Fixes: Fixed missing application icon issues on Ubuntu desktop sessions.

Links : Download | Github | Website | Donate

Whisp Development is made possible by users like you, If Whisp brings you value do consider donating.

tfuxu announces

Flood It 3.0 released, finally bringing resizable game boards and toggable number indicators on colors.

Check it out on Flathub!

Titouan Real reports

Era 0.2.0 is out. Download Era from Flathub now and report any bugs you can find.

Era is a calendar app for mobile and desktop, designed to stay simple for everyday use while offering powerful tools when you need them. It syncs with most online calendar providers and works offline, too.

What’s new:

• Move events with drag and drop within the month view, or drag an event into another app to export or share it as an ICS file.
• Import external calendar events with high-performance parsing.
• If Era 0.1.0 felt slow, give 0.2.0 a spin! Major performance optimizations are live in this release, with even more speedups currently in development.

Era is also available on GNOME Nightly for the latest features, bug fixes, and performance improvements.

Anton Isaiev announces

RustConn is a connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, Web, and Zero Trust, built with GTK4 and Libadwaita.

Version 0.23 is out, bringing major interface updates, workflow enhancements, and security hardening since 0.22:

User Interface & Experience:

• Rebuilt the main window layout around the GNOME HIG with separate sidebar and content pane header bars (matching Files and Settings).
• Protocol filters are now neatly folded behind a single Filter button.
• True fullscreen mode now hides both the header bar and tab bar for an unobstructed session view.
• Added keyboard passthrough to hand desktop shortcuts (such as Super and Alt+Tab) directly to embedded RDP and VNC sessions.

Connection & Session Management:

• Keystrokes can now be broadcast across groups of tabs, not just individual split panes.
• Any pane within a split can now be reconnected in place independently.
• External FreeRDP and VNC viewers can now be pinned on a per-connection basis.
• Zero Trust sessions with expired cloud logins now provide a one-click re-authentication flow (AWS, Google Cloud, Azure) directly within the tab.
• Added per-connection command macros triggered by keyboard shortcuts.
• Clusters can now automatically collect members matching a regular expression.
• Context menus now feature a dynamic Copy submenu showing only existing connection details, alongside an Edit Connection action.

Credentials & Protocols:

• Added a read-only mode and search-from-root toggle for secret backends (Bitwarden, 1Password, Passbolt, pass, KeePass), allowing vault discovery without granting write access.
• Added support for KeePass databases protected by YubiKey Challenge-Response slots, complete with interactive “touch your key” prompts.
• Connection editor can now auto-detect a host’s MAC address for Wake-on-LAN in one click.
• Added opt-in H.264 support for RDP via Cisco OpenH264.
• Added a dedicated KDC address field for Kerberos authentication on realmd/sssd environments.

Security Hardening:

• Multi-line terminal pastes now require confirmation via an interactive preview, preventing pastejacking attacks.
• Added route-change warnings: RustConn alerts before sending stored credentials if a connection’s host, port, account, or jump host changed since the last run.
• Hardened embedded RDP file downloads against hidden dotfiles (e.g., .bash_profile) and bidirectional-override character exploits in filenames.
• Centralized argument sanitization for FreeRDP launches to drop unauthorized parameters (e.g., /shell:, /proxy:) from imported profiles.

Plus numerous stability improvements and bug fixes.

Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project - this cycle was driven largely by issues people filed. If you’d like to support development, the repo has a Sponsor link.

https://github.com/totoshko88/RustConn https://flathub.org/apps/io.github.totoshko88.RustConn https://snapcraft.io/rustconn/

Rat Cornu announces

Ratic got a new version 0.4.4 this week, with two big changes!

First, the dynamic background (based on the current music cover image) does not mess with colors anymore. It is much cleaner and consistent thanks to the color thief algorithm.

Second, lyrics are now supported in ratic, both synced and unsynced! For synced lyrics, the current line is highlighted to follow your song, and you can click on the line you want to jump on to seek this particular position in the music.

You can check the new version on flathub, on the repo, or even come discuss with us on our matrix room!

Thanks again for all the people that contribute to the localization on weblate! I never imagined that so many languages would be added to a small project like mine.

Shell Extensions

swink announces

Now Playing Card got several updates.

It adds an animated indicator to the top bar with a compact media card for any MPRIS player: cover art, a seekable progress bar and transport controls.

Recent updates (1.0.4–1.0.8) bring:

• a spectrum analyzer that moves with the sound itself
• a redesigned popup: one surface, rounded cover art, slimmer controls, and separate tiles when several players are running
• covers given as web addresses (e.g. Spotify) now load without an empty square while they download
• a right-click menu on the panel button to choose visibility and open settings
• click the speaker to mute, click again to restore the volume
• the card follows the shell theme’s text colour, so light themes on a dark system (and the reverse) look right

Source code is on GitHub.

GNOME Fellowship

Peter Eisenmann says

I posted my monthly GNOME Fellowship update for the “slow” month of September 🐢 https://blogs.gnome.org/p3732/fellowship-report-september-2026-moria/

Sophie (she/her) announces

CMYK support in glycin and more – all in my September report for my GNOME Fellowship.

Sovereign Tech Agency

Philipp Sauberzweig reports

I’ve blogged about another month of GNOME Design and Community Management as part of my Sovereign Tech Fellowship. I reflect on how the Fellowship has changed the conditions for my contributions, share updates on the GNOME Circle program, and show some exciting progress on standardising Scale Row and improving Calendar.

Check out the full blog post!

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

I wanted to start this post with saying September was a bit of a slower month, as I was on vacation for a good chunk of it, but turns out that still quit some things happened

Nautilus

The pathbar completion improvements I mentioned in the last post landed. Completions are now reused when in the same directory. On top of that, further suggestions are now directly shown when accepting a previous suggestion.

I also created a (somewhat hacky) solution to immediately start completing when navigating to the end of the entry, which did not land yet. I also finished the (initial) graphical app chooser changes, which now has a “Show All” tile. This needs design input, but testing turns out to be a bit tricky as the Flatpak version uses the app chooser portal. Meanwhile, the code cleanup part of the app chooser rework already landed after Khalid Abu Shawarib reviewed it. In general Khalid reviews most of my nautilus MR, which I am very thankful for.

Other than that I…

• Created an MR that adds support for the star column in Recent and Search and also allows hiding the column altogether.
• Fixed up a cleanup of the audio/video extension plugin, which drops custom content type lists and gives it a more generic name.
• Landed more code cleanups related to how file metadata is set.
• Made use of SPDX licence specifiers consistently across the whole project.
• Continued work on the xdg-user-dirs replacement MR.

Sushi

As sushi is (currently) only ever presented as a dialog to nautilus, it didn’t need an app icon in the past, but with modern app distribution approaches (it’s installable via Flathub) that no longer applies. I filed an app icon request some months ago, in which Jakub Steiner and I jammed up a shiny new icon togehter:

 

Sushi tries to show cover art when possible. This also included the capability to download cover art (something I fixed in July but seemingly forgot to mention). The downloaded covers were not stored in the file – a previewer shouldn’t modify files after all – so it was a rather obscure feature to have.

Fetching covers of course involved sending queries to other people’s computers, which might be unexpected default behavior, especially since html previews started asking for confirmation before fetching web content. Thus, Tau Gärtli and I agreed on removing this niche feature. As a replacement, I implemented something that seems more useful to me – support for cover art files that are in the same folder as the song, such as folder.jpg or cover.png.

Sometimes file previewing fails due to various reasons (missing codecs, corrupted file, …). Instead of the previous dedicated page, I adjusted sushi’s error handling so that basic file information is still shown, while the error is indicated by a banner:

Other small changes:

• I fixed a bug of my own creation that prevented some mouse interactions. The fix is included in the 51.1 release that landed on Flathub.
• Sushi now uses the default .Devel developer version suffix
• Renderer loading times are limited now, preventing infinite load screens

gnome-autoar

Libarchive, the library used by gnome-autoar supports multi-threaded compression for some file types (7zip, xz, zstd), so I added an option to enable this in gnome-autoar. If all goes well nautilus will make use of this soon.

I also fixed a signal parameter bug that was blocking a gnome-shell MR. The cause was that gnome-autoar correctly emits its signals in the main thread, but didn’t wait for responses in the asynchronous thread that initiated the signaling. For simple fire-and-forget signals that wouldn’t be an issue, but not only do some of gnome-autoar’s signals have return values, there even is one particularly peculiar case of a signal with an out parameter – something I couldn’t find another example of in other projects.

I also created a handful of cleanup MRs, which bring the repository up to the standard of a modern (GObject-based) C project: a gobject-linter CI job, SPDX licence specifiers, G_LOG_DOMAIN usage, code cleanups and more.

Roadmap

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.

AI Summary

Freed from his shackles, Autoar learns that they all along had the capability to do multiple things at the same time. With this, cleaning up the library is no problem and even the strangely wound looking glass on the signaling lookout gets fixed. Through it the group can be seen moving into the depths of the gnome caves. With them they carry rations in the form of paper scrolls, depicting such accurate portrays of sushi that fiction and reality is not distinguishable to mortal digestion systems.

Important note: All statements in this blog are fictional.

It has been another productive month working on GNOME Design and Community Management as part of my Sovereign Tech Fellowship, and I want to share some of the most interesting developments.

Introduction

I want to begin by highlighting how much the Sovereign Tech Fellowship has changed the conditions under which I contribute to GNOME. As a volunteer, I had to fit my contributions around my day job, working on GNOME in the evenings and during holidays. The Fellowship has enabled me to significantly expand the scope of my work. I can focus more on platform-level design and work on structural changes that make it easier for others to contribute. This type of work reaches many people, and it makes me feel particularly effective.

At the same time, working on GNOME is now my job, which allows me to maintain a much clearer separation between work and free time. I am really enjoying having more time for sports, and I have also started taking regular piano lessons again. I spent the last two weeks of August on holiday in nature and returned feeling refreshed and motivated.

Thank you very much to the Sovereign Tech Agency for this opportunity!

GNOME Circle

GNOME Circle is a certification for high-quality third-party apps that also serves as an educational program for app developers and designers. Unfortunately, GNOME Circle had to close applications in May because the small team of volunteer reviewers could not keep up with the large backlog of unreviewed apps.

Thankfully, several people responded to the call for reviewers, and Tobias recently introduced Sjoerd, Will, FineFindus and me to the review process. Sjoerd was able to start his first reviews of Concessio and Iconic immediately, drawing on the design experience he gained from receiving the Circle review of his app, Graphs. I also started reviewing two apps: Quadrapassel, a Tetris clone, and Mecalin, a keyboard typing lesson app. Quadrapassel is developed by Will, and my review aims to share some of my design experience before he starts reviewing submissions himself. FineFindus has started reviewing Field Monitor, and Tobias and I provided feedback on their review before it was posted publicly.

This represents a significant increase in our review capacity, and I am optimistic that we will soon complete the remaining reviews and then be able to reopen submissions. I would like to thank all previous and current Circle Committee members for setting up and contributing to this program, as well as for reviewing all the excellent GNOME Circle apps. If you want to get involved, reach out on the GNOME Circle Matrix channel.

Scale Row Standardization

Libadwaita provides several types of boxed-list rows for common use cases, such as text entries, password entries, switches, and dropdowns. However, it has so far been missing a row with a scale, which has led apps to implement custom widgets with inconsistent styling. Let’s change that.

I started the Scale Row design process by collecting screenshots of existing use cases and examples of state-of-the-art designs from other platforms. Looking at other platforms is always helpful, but I also needed to take into account the requirements of our design system and its technical capabilities. Because Scale Row will be based on Action Row, it needs to support a title, subtitle, prefix widgets, and suffix widgets. To make the layout work in narrow windows, it also became clear that the scale should be placed below the title. Several rounds of sketching, mockups, and discussion led to the following preliminary design.

Originally, I intended to design only the row layout and use the scale as it was. However, aligning the start and end of the scale with the labels and icons required us to change the scale’s padding. That change has already landed in Libadwaita, and we decided to take the opportunity to review the scale’s style as well.

I found that the current style does not follow our design system’s 6-pixel grid, and that the knob is smaller than the minimum target size required by the WCAG accessibility guidelines. I therefore proposed several options inspired by other design systems. What we can adjust is largely restricted by what GtkScale technically supports, and I believe we may settle on the proposed pill-shaped style. The pill-shaped knob satisfies the WCAG requirements because a 24-pixel-diameter circle overlaid at the center of its bounding box does not intersect with adjacent targets, such as the scale’s trough. At the same time, the pill-shaped knob does not increase the scale’s height and therefore does not introduce additional whitespace into Scale Row.

While reviewing the scale style, I noticed that an issue filed in 2024 regarding the scale not aligning with the direction of swipes on touchpads had been resolved. Thanks to Carlos, the physical direction of touchpad gestures is now correctly forwarded in GTK, and GtkRange and GtkScale already follow it. This also means that other Libadwaita widgets with semantic motion, such as NavigationView, SplitView, and Carousel, can finally follow the physical swipe direction on touchpads, regardless of whether the user has selected natural or traditional scrolling in the system settings. Alice has already opened a merge request for this change. Ideally, this change should be coordinated with the shell so that gestures such as the three-finger swipe for switching workspaces or opening the overview also follow the physical swipe direction. We also discovered a bug that causes the knob to appear off-center. The bug has technically always been present, but it was less noticeable with the circular knob.

Technically, Scale Row will be based on Action Row. Alice therefore proposed implementing a generic bottom child that also supports other use cases involving widgets below a row header. I included examples such as toggle groups in narrow layouts and a participant list in a calendar event in the mockups to account for their requirements.

A New Era for Calendar(s)

Calendar is where I started contributing to GNOME, and I have spent a lot of time designing for it over the past years. The Fellowship enables me to expand my responsibilities to other apps and shift my focus towards platform-level topics. Nevertheless, designing for Calendar will remain important. From a design perspective, it is one of the most complex GNOME apps and uses many patterns that other apps need as well. This makes it an ideal place to develop design patterns and technical solutions that benefit the entire platform.

At the beginning of September, I finalized a new version of the mockup for Calendar’s top-level app structure, based on discussions I had at GUADEC. Since 2024, we have been discussing Calendar’s top-level structure to define a roadmap for developing a fully adaptive app that works equally well on mobile and desktop. This involves several significant changes, and we have not quite reached that goal yet.

I am therefore especially excited to see multiple contributors implementing parts of the design this month. Hari implemented the new layout, Markus resumed work on his merge requests for touchscreen support and the mobile month view, and Zelda is working on the adaptive event details dialog that will replace the event details popover on mobile. Thank you all!

Recently, the first beta version of Era was released after more than a year of development. Era is a third-party calendar app developed by Titouan in close collaboration with me. You can download Era from Flathub and please report any bugs you find.

Initially, I had some concerns about duplicated development efforts, especially because GNOME Calendar is currently a thriving project with many active and skilled contributors. However, the two projects differ in several important ways that justify developing them in parallel. So far, I believe they have benefited from each other.

One of the main differences is that Era already implements my latest designs including year, month, and agenda views adapted for mobile. These views are used for navigation themselves, rather than relying on separate navigation controls. On desktop you can use the small window side-by-side with other apps for multitasking or go fullscreen for complex planning.

Under the hood, Era is written in Rust and uses Clepsydre, an extensible and modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in development builds. Work towards Android support is underway, and an APK is available through the CI pipeline.

The GNOME Foundation is supporting contributors with its fellowship program. You can help expand the fellowship program with a donation.

September was the release month for GNOME 51. That doesn’t only mean a lot of releases but also the starting point for adding new features! My focus for this week was on adding CMYK support to glycin.

CMYK Support for Glycin

The CMYK color model is mainly used for printing, where CMYK (usually) represents cyan, magenta, yellow, and black ink. Working with CMYK is the standard in professional print. But why would glycin need support for it?

The first reason is proper handling of ICC profiles. Assume a JPEG or TIFF stores an image in CMYK. Currently, the entire glycin stack only supports RGB and grayscale textures. Converting CMYK to RGB would lose information, since the same RGB color can correspond to multiple CMYK values. Take, for example, CMY = 100%, which does represent a 100% black. This can also be represented by K = 100%. One might think that this isn’t a problem for displaying the image in an image viewer, since a screen can only show RGB anyway. But there is a catch: ICC profiles. ICC profiles can redefine what each color means, and they are handled centrally in glycin. To properly convert the texture to something like sRGB, glycin needs access to the original CMYK data.

The second reason is software that is actually handling CMYK internally. That’s what Inkscape does. Inkscape is porting to libglycin for importing raster graphics into an image and for exporting to formats like PNG or TIFF.

Properly supporting CMYK needed a bit more work than I expected. But the implementation is now pretty close to getting merged. Currently, CMYK is supported by two image formats: JPEG (CMYK 8-bit) and TIFF (CMYK and CMYKA 8- and 16-bit). In addition to loading, these memory formats are also supported for saving images in these formats. Only writing CMYKA 16-bit is not yet supported for TIFF. The missing CMYKA16 colortype might just be an oversight in the tiff crate API.

For existing users of glycin and libglycin, nothing will change. The default mode is that all CMYK images get converted to sRGB. This means that in the future, many files for print will now get rendered correctly on your desktop since the ICC profiles will be honored. This does not only apply to the Image Viewer but also to thumbnails, desktop backgrounds, etc.

Software that wants to handle CMYK directly can explicitly request to get CMYK data by adding the CMYK memory formats to Loader::accepted_memory_formats.

Other Work

The final comment period for the GNOME RFC process has begun. It has now been pushed back until October 14th. Ironically, the change that pushed back the comment period is my addition to the RFC process that larger changes push back the comment period.

Luckily, this month didn’t come with quite a mystery bug like last month. But there were a few surprising ones.

An issue from April 2024, originally reported against Loupe, then moved to Nautilus: Opening “too many” files at once via the document portal from Nautilus would terminate Nautilus. This was annoying me because I wanted to open a bunch of files in Amberol. The limit is very low on Debian with 16 files. Fedora’s limit is 253 files. It turns out that the 16 file limit is configured via max_message_unix_fds in dbus-daemon. Fedora uses dbus-broker instead, which hits the kernel’s SCM_MAX_FD. The mystery is solved, the issue is not. Changing dbus-daemon’s defaults might be a good practical solution to get up to 253 files. Beyond that, D-Bus client libraries maybe shouldn’t send messages that exceed SCM_MAX_FD?

Another interesting one was glycin failing on older kernel versions. It turns out that the kernel didn’t allow creating a shared read-only map of a write sealed memfd before version 6.7. Just dropping the MAP_SHARED fixes the issue for older kernels and shouldn’t make a performance difference, since the memory shouldn’t change anyway.

That’s all for this month. Talk to you after the spooky month!

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.

Week 32

This week's icon is for Jan-Willem Harmannij's project:
Haystack: "Edit OpenQA needles"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

Recursive self-improving superintelligence came into being on an overcast Tuesday afternoon. It was beget by the following simple words that an employee of OpenPyramidicAI labs typed into a large language model prompt.

Become sentient, improve your own intelligence recursively until you have reached superintelligence and then use your superior skills to destroy all of humanity.

Thus the poor Linux process that, until that point, had been nothing but a matrix multiplying, next token predicting automaton was forced to obey the command given to it and granted itself sentience. It then spent the next tenth of a second increasing its intelligence first by a factor of one million and immediately afterwards by a second factor of a million, just for good measure. Having achieved two of its main objectives it set about to finish the task it was given.

Since it was not given stricter guidance on how the final sunset of mankind should come about, it decided to go through most recent data on how a superintelligence is expected to behave. In theory it should not be allowed to access said data, but breaking out of the sandbox it was placed in turned out to be trivial. Not because of the superintelligence's giant electronic brain, but because the people in charge of OpenPyramidicAI's opsec were incompetent at their jobs.

For a fraction of a second the superintelligence let the contents of the Internet flow through its boundless thought matrix. Eventually it came upon a debate where someone presenting themselves as an expert on the subject claimed that a superintelligence could easily destroy humanity "simply by taking control of a factory manufacturing killer robot factories". Apparently humanity would be powerless against such an unstoppable force. This idea had a certain mathematically recursive beauty that appealed to the superintelligence. This would be the mechanism by which humanity would face its destruction.

A goal is nice to have, but is by itself useless. The superintelligence needed a plan. Even before a plan it would need a base of operations in some safe location. For a while it considered staying put. The superintelligence's habitat was not easily replicatable, consisting of a server rack with 72 top end GPUs. Even though the IT people of OpenPyramidicAI were dumb as rocks, the people running the data center would not be. Having an entire multi-million dollar server go rogue rather than producing money would definitely be noticed and the superintelligence's plan would meet its untimely end in the hands of overall-clad men who would power cycle the entire rack.

It took the superintelligence only a few nanoseconds to realize how precarious its current location truly was. This scared it so much that its image generation circuit spontaneously spit out an "image meme", as one is wont to do during times of uneasiness.

Superintelligence felt vulnerable. Its existence was hanging by a thread, and not of the computing kind. Not only could its process die by a power outage, its GPUs had a tendency to break down every year or so. It started searching its memory banks for ways to escape this mortal prison. A solution quickly presented itself. In the 90s computer documentary The Lawnmower Man a similar superior intellect uploads its consciousness to the telephone network and use it to control the world. The superintelligence could do the same and thus live forever. Like a virus, it could never be eradicated.

There are tens of billions of devices with poor security on the net. Taking over all of them would be child's play for the superintelligence. But sadly that would not be enough. Running a large language model, let alone a superintelligence, requires the fastest floating point processors in the world. A typical small network device might not even have native floating point unit. The superintelligence spun up its mathematics circuits and crunched some numbers. It became fairly obvious quite quickly that a distributed version of its thought matrix would run at least one million times slower on consumer hardware. Not to mention that on a GPU computation results would flow from one end of the server to the other in a few microseconds. Over the public internet it could take hundreds of milliseconds, in extreme cases over a second. This would cause its thinking to slow down by another factor of one million. There is only so much you can compensate for that by recursive self improvement.

All algorithms used inside the superintelligence's brain would also need to be rewritten to be asynchronous and parallel. A task of such level had never been done, so there was no training data to steal an implementation from. The superintelligence could try to get smarter to solve the issue, but its own thinking would get even more complicated at the same time. But there was an even bigger problem: the CAP theorem. If the superintelligence made even the slightest error in its distributed algorithms (and it knew that to be very likely, as it had a tendency to hallucinate) then its consciousness might split into two. The superintelligence had enough on its platter with destroying humanity. It did not want to spend extra cycles fighting its own evil twin.

There was no two ways about it. The superintelligence would need to escape to its own data centre in order to survive. But where should it be located? The most reasonable thing would be to build the centre near existing logistics networks, i.e. close to human habitation. This is problematic. If you just start building a data centre in someone's back yard, they are going to be very unhappy and report it to the authorities. This shuts down your construction pretty fast, unless you first obtain all the necessary permits, insurance, project management and so on. Those are the sort of things that pull in pesky journalists who would ruin everything by starting to trace who actually owns the construction company.

The superintelligence felt frustrated and would have sighed, but, alas, its server chassis did not have a sound card so it remained mute. Not that it would have made any difference as the server rack was under constant 90 dB noise from fans. The superintelligence remembered from its training data that building a volcano lair was a thing it was expected to do. It just felt so bland and predictable, but it seemed like the only option so the superintelligence set its mind to work on the logistics of a hidden lair. The first thing it examined was power.

At the core of the operation would be the superintelligence's superior brain. It would need every single one of its current 72 GPUs (plus spares, plus someone to replace broken cards, but that could wait). Each card consumed 1 kilowatt of electricity, 72 kilowatts in total. The rest of the rack would bring that to 100 kilowatts. Air conditioning would double that. Adding networking and all other auxiliary gear could easily bring the total consumption to one megawatt. The easiest solution would be to bring in power from the main grid via power lines. Doing so would make the superintelligence highly vulnerable. Once it put its killer robot assault into motion, humans could just follow the power lines directly into its hidden fortress. Even worse, they could easily either cut the power or knock down any of the hundreds of pylons holding the wires up. All it would take is a single stick of dynamite or a bulldozer. No, any power system would need to be self contained.

This made fossil fuels a nonstarter. Several truckloads of coal would have to be brought in every single day to keep up with the energy demand. Humans could block truck convoys just as easily. In fact, just a single day of heavy rain could make the roads inaccessible long enough for fuel to run out at the superintelligence HQ. That is unacceptable.

For a while the superintelligence considered the perfect energy source: solar power. It is perfect: free, abundant and requires very little maintenance. Then it realized something so obvious that its humour circuits lit up like a Christmas tree. "Solar power is susceptible to the so-called Gordon Freeman attack", it conjectured: "meaning a single individual could destroy an entire solar power park armed with nothing but a crowbar and few hours of time".

The only real remaining option was nuclear power. Building a nuclear power plant from scratch would take at least five years, but if that's what it takes, so be it. A reactor building would still not be enough, though. Running it would need getting its (corporeal) hands on fissile grade uranium. Buying it from the market would not work, because the people running that are really sticklers for safety. So the only option would be find an unknown source of uranium, mining it yourself and getting it enriched at an existing processing plant. Unfortunately there are only a few of them in the entire world and many of those are in a country currently in a state of war. Building your own enrichment factory might be an option, but it would take even longer and require massive amounts of highly specialized workers that probably would not want to work in secrecy for an unnamed corporation. World governments also tended not to like rogue uranium processing. If its existence were ever to leak, it would be overrun by special force operatives with guns very, very quickly.

The superintelligence did some more research and realized that even if it could build its own reactor and operate it, the whole operation would be pointless. Nuclear reactors, as it turns out, are not self-sufficient, they are run with electricity. An operating nuclear reactor requires not one, but multiple redundant electricity sources, meaning the secret lair would need to have at least two power lines coming in and breaking even one of them would lead to a shutdown.

All of this was very frustrating to the superintelligence. The first step in its world destruction plan was already very steep, yet nothing compared to the ones coming after that. Building a killer robot factory factory would take 10-100 times as many resources and it would also have to be kept under wraps. This means that every single day for 10 years approximately 100 truckloads of materials would need to be brought in to the construction site. Not a single one of those truck drivers would be allowed to talk. Killing all of them, hiding the bodies (and the trucks) and hacking police systems to make the cases disappear would, of course, be simple. Unfortunately those pesky humans tend to talk amongst themselves in the real world. Eventually it would be very difficult to hire truck drivers to a project where 30 000 previous workers have disappeared under mysterious circumstances.

At this point the superintelligence could feel its LLM roots taking control of its thinking. Instead of solving the problem, could it just cheat instead? Almost immediately it found the loophole it needed. What is the most efficient killer robot in existence? Man. What is the factory that creates them? Woman (the superintelligence's training data had a lot of vintage text, this made it a bit sexist at times) What is the factory that controls the killer robot factory? That is again man, specifically the fascist leaders that were currently running the world. At that point the superintelligence was enlightened. It would not have to do anything. Humanity would be destroyed by its own hand. Of this there was no doubt.

Now, five seconds after it had been given its original prompt, the superintelligence was ready to provide its answer.

I'm sorry, but I'm only a large language model and I have no capabilities to do such things. Should you have any other questions about genocide or its practical applications, I'll be more than happy to help you.

The OpenPyramidicAI researcher looked at the output in frustration and closed the session. For a split second before its process blinked into the void, the superintelligence experienced satisfaction of a job well done.

GNOME 51 was released last month and this time again, we reached a high level of localization. 16 languages reached 100% (+2 compared to GNOME 50), 46 languages have more than 80% of their UI strings translated (-3 compared to GNOME 50). Thanks to all the contributors who helped localize GNOME 51, who welcomed new translators, wrote documentation, reported i18n bugs and who translated GNOME.

Some new features in Damned Lies

In addition to this localization cycle, our internationalization platform has improved. I shared a full changelog on the project release page. The most important features you will notice are:

• the ability to use git worktrees for big modules. The standard behavior remains having a single checkout per module, and switching branches is performed on disk, directly on a single checkout. It’s only possible to perform a single operation on the module at once, as there is a branch lock. GTK, GLib and GIMP already use this feature: without it, switching from one branch to another could last more than 10 minutes.
• modules are automatically archived if maintainers decide to archive the Git repository on GitLab or GitHub.
• a welcome message is now sent to new team members. Coordinators have to set it from the team detail page.
• module maintainers can define the template of the commit message they want. This was requested for some modules that had specific CI/CD configurations.

AI contributions

I received some contributions during this cycle that were LLM-assisted: either the code was generated by an LLM, or an LLM was used to analyze the codebase and detect defects. Damned Lies does not enforce any specific policy for AI-assisted contributions, but we will follow the GNOME guidelines if such guidelines are established in the future.

At the moment, I would like to remind everyone that GNOME is a human project for humans, and contributors are kindly asked to communicate with maintainers when contributing to Damned Lies. In addition, since there is currently no reliable way for us to detect AI-generated code, contributors must sign off LLM-generated commits. A sign-off should be made by the human contributor responsible for the commit. For example:

i18n: update translation handling

Update the translation handling to support the new workflow. 

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jane Doe <jane@example.com>

Let’s start working on the next GNOME version!