Update on what happened across the GNOME project from August 14 to August 28.

GNOME Core Apps and Libraries

Sophie (she/her) announces

The GNOME 51 Flathub SDK is now based on the Freedesktop SDK v26.08. The GNOME Beta SDK is available from Flathub Beta as org.gnome.Sdk/x86_64/51beta and GNOME Nightly as org.gnome.Sdk/x86_64/master.

You might need to update the sdk-extension and append-path in your Flatpak manifests to newer versions like LLVM 22, and install newer versions of the extensions on your local system like org.freedesktop.Sdk.Extension.rust-stable//26.08beta.

Mutter ↗

A Wayland display server and X11 window manager and compositor library.

Toluwaleke announces

Hello everyone! I’ve been working on GPU reset recovery in Mutter through the summer, under the mentorship of Jonas Ådahl, Robert Mader, and Carlos Garnacho.

Previously, a GPU reset would take the whole session down, crashing or freezing it. That’s no longer the case: Mutter now detects a reset and recovers automatically, restoring windows, background, cursors, and text, all in an instant. The work isn’t fully done: GNOME Shell doesn’t recover completely yet, and real hardware testing has been trickier than expected, but the implementation is up as an upstream MR for review, and I’ll keep working on it after GSoC.

Full details, demos, and some of the more entertaining debugging stories are in my wrap-up post.

Python Bindings (PyGObject) ↗

Python language bindings for GNOME platform libraries.

Arjan announces

Today I release PyGObject 3.58.0.

This is modest release, which contains some quality of life improvements:

• Generic annotations for Async.
• Path separator (/) support for Gio.File objects, similar to pathlib.Path.
• Updates to tutorials and examples.

Behind the scenes, this release includes an update to the marshalling code. Now it’s easier to clean up after a call is dispatched from Python to C or visa versa.

Lastly, the ability to find libraries automatically on Windows has landed in this release. Before, you had to call os.add_dll_directory() for each directory which contains DLLs you want to use. Now, a default directory are added, relative to where PyGObject is installed.

PyGObject can be found on PyPI and the GNOME download server.

GNOME Fellowship

Glycin ↗

Sandboxed and extendable image loading and editing.

Sophie (she/her) announces

Libglycin 2.2.beta.1 has been released. This release brings two important workarounds. The first avoids triggering a memory leak in gtk-rs that has been fixed upstream but where a gtk-rs bugfix release isn’t available yet. The second workaround avoids using the async Gio.File API in libglycin’s sync API. The Gio.File internals rely on at least one thread being available in the Gio.Task thread pool. However, it is currently common practice to starve the complete Gio.Task thread pool via Gio.Task.run_in_thread() when using sync APIs. Therefore, libglycin now internally uses Gio.File’s sync API for executing blocking functions like Gly.Loader.load().

Sophie’s work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation.

Sovereign Tech Agency

swick reports

Together with Modal, I’m happy to announce that the Sovereign Tech Agency is investing nearly €510k into Flatpak development. The focus is on closing gaps in Flatpak’s sandboxing story: new portals for audio, networking, VPNs, and spell checking, plus infrastructure work on entitlements and intents.

I’ll be leading the technical side alongside Adrian, with organizational support from Kateryna and Cade. We’ve brought on a great team and the project will ramp up over the coming months through the end of 2027.

Read the full announcement on the Modal blog.

Prototype Fund

verdre reports

I’m happy to announce that Test Center is available on Flathub now 🧪️✨️

https://flathub.org/en/apps/cx.modal.TestCenter

Test Center is a new native app to manage experimental versions of apps (flatpak) and system components (systemd sysext, only available on GNOME OS), similar to Apple’s Test Flight. The initial version we just released supports installing and managing both types of experiments, but we have a lot more planned including a built-in feedback workflow, updates, expiration dates, and an integrated “first-run” dialog for experimental apps.

If you want to give the app a spin, here’s a fun merge request to try, adding interactive screenshot UI to Epiphany: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2129

After the initial release, our next focus for Test Center is adding “studies”, i.e. developer-curated experiments with a custom name, icon, testing instructions, etc. This requires metadata that is not part of the merge request itself, which means more complexity in the developer workflow. To get your input on this we’re having another community call on Thursday, September 10 at 13:00 UTC.

See the full agenda and sign up here: https://pad.gnome.org/K1MftsinR2-uruO\_4KWnLQ

GNOME Circle Apps and Libraries

Brage Fuglseth reports

Last week Bazaar was accepted into GNOME Circle.

Bazaar is a new app store for GNOME with a focus on discovering and installing apps and add-ons from Flatpak remotes, particularly Flathub.

Congratulations!

Tuba ↗

Browse the Fediverse.

Evangelos “GeopJr” Paterakis 🏳️‍⚧️🏳️‍🌈 says

Tuba v0.11 is now available, with many new features and bug fixes!

✨ Highlights:

• Tuba moved to Codeberg!
• Full Mastodon quotes support
• Collections
• Hashtag Lists
• UnifiedPush
• Android builds
• Better custom emoji picker
• Improved media viewer
• More compact narrow layout
• Custom thumbnail support for media
• Font-size slider
• Regularly update stats in threads and check for new replies
• Support for Mastodon’s new profile tabs settings
• Formal AI policy
• Much much much more!

Read more and see all the changes in action on the (very) informative changelog!

Graphs ↗

Plot and manipulate data

Sjoerd Stendahl reports

Graphs is now available in the GNOME nightly repo. You can get the latest build straight from the main branch by adding the GNOME Nightly repo using flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo, after that you can just install Graphs like you’d usually do.

The current nightly includes some enhancements, such as a further optimized codebase and a much improved math parser. But also the handling of very large data files. Instead of crashing or locking up the application, Graphs now uses a LOD-based approach and downsamples large datasets visually to a maximum of 5000 datapoints, still drawing over one datapoint per pixel even at 4K resolutions. This behaviour can be turned off for each item for the sake of scientific accuracy.

Another major feature that already has landed in the nightly build is the implementation of fills. This enables you to add visually pleasing fills above, beneath or between curves, or use a fill area to e.g. show error margins. Fills can be coupled to any number, equation or even to another item in Graphs.

I’ve also been experimenting a bit with implementing free variables, as well as the introduction of support for date-time datapoints. But there’s no set ETA for that as yet, and both features need some rethinking so edge-cases are dealt with more cleanly. Such features will hit the nightly first though. Note that the nightly version is always in active development, and is purely meant for testing purposes. You can expect things to break from time to time, and project data might get corrupted. Do not use the nightly for mission-critical work.

Third Party Projects

Jan-Michael Brummer says

For those of you looking for a modern mail suite dedicated to GNOME, here is Stamp.

Over the last two years I’ve been working on Stamp as a modern replacement for Evolution’s user interface, suitable for both private and business accounts. It is based on the Evolution Data Server backend, combining its proven reliability with a modern Adwaita interface.

Besides standard mail features, Stamp also supports a number of Microsoft 365 features such as Internal/External identifiers and Categories, which are quite common in enterprise environments. Thanks to its Adwaita-based design, it also works well on mobile devices.

Mail and Contacts are already integrated, and Calendar support is available in a pending merge request based on GNOME Calendar as a library. Future versions will make these components pluggable, allowing Stamp to be shipped as a standalone mail client or as a complete personal information suite.

Got your interest? Check it out: https://gitlab.gnome.org/jbrummer/stamp or download it via GNOME Nightly

Francesco Caracciolo says

Newelle 1.5.0 released!

Newelle, AI assistant for Gnome, has received a new major update, which brings a lot of UI refinements, improved agentic capabilities and other interesting features. Highlights (I have written personally with my keyboard every single character of this description. Emojis are indicative of what is each feature, stop complaining under each post)

• 🖥 Improved terminal tool, Newelle can now manage persistent Terminal sessions and interact with TUIs
• 💫 Mode switching: users can now create custom “modes” that quickly change prompts, tools and skills (ex. Planning mode)
• 📲 Added a curated catalog of MCP servers that can be used to connect your applications to Newelle
• 🌐 Added citations, the LLM can now state the source of an information
• ➕ You can now add LLM providers directly from the UI (OpenAI/Ollama/Anthropic compatible)
• 🚀 Improved text generation animation
• 🔻 Added “Compact Mode” for tool calls and input bar
• 🧩 You can now download and explore new extensions and skills directly in Newelle
• ✏️ Added a Skill editor to create and edit Newelle Skills directly from Newelle

Full changelog: https://github.com/qwersyk/Newelle/releases/tag/1.5.0

Download: https://flathub.org/en/apps/io.github.qwersyk.Newelle

Anton Isaiev says

RustConn 0.21.0 is out - connection manager for SSH, RDP, VNC, SPICE, Telnet, Web and Zero Trust (GTK4/libadwaita).

New features: portable encrypted credential store you can sync through a cloud folder, with tools to copy stored passwords between any two backends and to change the passphrase; a jump host that can be set once on a group or for the whole application and is inherited by SSH, SFTP, RDP, VNC and SPICE, with a per-connection Direct override; window sizing for the external RDP client; an option to reveal the session toolbar on hover or on click only; connection names in split panes; a flat accent Shell button in the header bar instead of the oversized pill; Georgian translation, so 17 languages now.

Fixes: the sidebar context menu opened and vanished within a frame on GNOME Wayland, and did not open at all when there was no room below the pointer; the terminal started at 24x80 in Flatpak instead of its real size; telnet, ssh and serial processes stayed alive after quitting, and quitting from the tray tore nothing down at all; a jump host set on a group or globally was stored and shown as inherited, then dropped at connect time; the Secrets page could stay empty and a KeePass operation could freeze the window with no way out, so every credential-path subprocess now has a deadline; SPICE asked to install virt-viewer on machines that already had it; Simplified Chinese had never loaded in any package; minimizing to tray silently killed port forwards, recordings and external viewers; nine dependency advisories are gone along with the GTK3 binding stack that the macOS tray was pulling in.

Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project. 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/

Tanay Bhomia reports

Whisp v1.4.1 - Exporting and Better OCR

Whisp is a minimalist, folder-less note-taking application built for speed and simplicity. Designed around a fluid, gesture-driven interface, it features powerful text-expansion capabilities to help you capture and organize your thoughts without the friction of a traditional file system.

This week, we released Whisp v1.4.1, bringing several productivity enhancements and UI polish to the app:

Instant Export: You can now instantly export your current note to a file directly from the main menu. Native Markdown Lists: Creating lists is faster than ever—typing - or * followed by a space now automatically formats the line as a list item. Smarter OCR: The Smart Paste image-to-text engine now correctly preserves hard indentation and paragraph structures from the original images. GNOME HIG Polish: We replaced the old update popup with a sleek, non-intrusive update banner, and fixed a responsive layout bug that caused the Preferences dialog to clip on narrow screens.

Links Download - https://flathub.org/en/apps/io.github.tanaybhomia.Whisp Website - https://tanaybhomia.github.io/Whisp/ Source Code - https://github.com/tanaybhomia/Whisp Donate - https://tanaybhomia.github.io/Whisp/donate.html

Bouncer ↗

Bouncer is an application to help you choose the correct firewall zone for wireless connections.

justinrdonnelly says

Bouncer 50.2.0 has been released! This release brings closer alignment with the GNOME Human Interface Guidelines, including the ability to undo changing a network’s firewall zone or forgetting a network, more consistent controls, and clearer empty states. Bouncer also handles more edge cases and error conditions, with improved feedback and recovery options when saved networks or firewall information cannot be loaded. Spanish translations have been added, and Occitan and Danish translations have been updated. The new release is available on Flathub.

Shell Extensions

Just Perfection announces

The extension port guide for GNOME Shell 51 is ready, and we are now accepting 51 packages on EGO.

If you need any help with your extension you can ask us on GNOME Extensions Matrix Channel.

Daniel Elia says

The Calendar Reminders extension has been released! It replaces the Evolution reminder notifications with ones that fit GNOME Calendar better, which allows you to join virtual meetings straight from the notification itself, open the GNOME Calendar app to the event, or snooze the notification.

You can get the extension from EGO here!

🇧🇷️ Fabito02 says

ChromaLeon v2.2.0 has been released with new styling options and a significant restructuring of the theming logic for GNOME Shell.

ChromaLeon is an extension I created that can change the accent colors of GNOME Shell and applications based on the wallpaper’s colors, as well as apply tinted styles, generate a dynamic icon pack, and more.

The focus of the v2.x.x updates was to resolve structural issues and simplify maintenance, thereby extending the extension’s lifespan and improving contrast standards relative to the GNOME interface.

Key improvements in this version include:

New style application logic: ChromaLeon now applies Shell styles as a theme rather than an overlay stylesheet. This resolves any conflicts with other extensions.

Simplified maintenance: All styles are now based on a copy of the default GNOME Shell theme. This makes it easier to track changes in new GNOME Shell versions, preventing conflicts or missing styles.

Improved contrast: ChromaLeon previously had methods to adjust contrast for very light colors, but issues remained with very dark colors. ChromaLeon now also adjusts very dark wallpaper colors to ensure optimal contrast with the dark theme.

New fully light style: This option applies a light style to the entire Shell, unlike the default GNOME light theme, which keeps the overview and app grid dark.

Better contrast in the light theme: The light theme now offers improved contrast for interface elements compared to the default GNOME light theme for the Shell.

Additionally, many bugs reported in the repository or identified by me have been fixed, resulting in greater stability during use.

I would also like to give a special thanks to the developer of the Luminus extension. The “fully light” style was based on it.

Leandro Rodrigues says

Aurora Shell is making its first appearance in TWIG 🎉. It is a modular extension for GNOME Shell 50 with a configurable dock, Clipboard History, Capture Tools for screenshot annotation and local OCR, Tray Icons, Meeting Clock, Weather Clock, and privacy helpers. Each module is optional and managed from the same preferences window.

Version 50.12 is mostly about the dock. It can now sit on the bottom, left, or right edge of the screen. Users can set a maximum icon size from 16 to 64 pixels and turn on live window previews with window actions. Window Previews is off by default and can be enabled under Dock & Panel → Dock.

Outside the dock, Meeting Clock now extracts conference links from redirect and tracking URLs and requests another banner when an active alert fires again. Tray Icons now loads icons supplied as absolute SNI paths.

Aurora Shell 50.12 is available on EGO. Read the full announcement or visit the GitHub release.

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!

GSoC 2026 has come to a close, so here’s where things stand with GPU reset recovery in Mutter. If you’re catching up, the short version is in my intro post: a GPU reset invalidates the EGL context and wipes all GPU memory, and until now Mutter had no way to come back from that. My project is a recovery mechanism so a reset doesn’t take the whole session down. Here is what things look like now:

In the video: After a period of normal operation, a reset is triggered. Mutter recovers successfully and is back to normal operation instantly. Everything is restored, from the background to windows and cursors. Then a loop is executed to trigger a reset every second while various activities are performed within the session. Through it all, Mutter remains unfazed and the session responsive.

Where We Left Off

In my last progress update, the compositor survived a reset, but with two open gaps:

• The display stayed blank until the creation of a new framebuffer was manually forced (I triggered it with a window maximize keyboard shortcut in that demo).
• The desktop background came back with garbled/wrong textures.

Both of those are now fixed, along with a lot more that wasn’t even in scope for that post yet.

A Well-Defined Recovery Order

My previous update touched on this problem: recovery involves a lot of GPU-associated state scattered across Cogl, Clutter and Meta, and a lot of it depends on being torn down and rebuilt in a specific order. The font renderer needs the stage unrealized first; the stage needs stage views rebuilt before it can be realized again; and so on. The earlier approach made use of a single signal on ClutterBackend, and relied on G_CONNECT_AFTER and GLib’s signal connect order for ordering, which worked but was fragile and implicit. That’s now been replaced with a dedicated ClutterGraphicsRecoveryContext type encapsulating all the core recovery logic, and whose signals are emitted in a fixed, well-documented sequence:

Anything in the compositor that owns GPU-associated state now hooks into one of these instead of guessing at ordering. Only recreate-context can actually fail; if it does, recovery aborts there and recovery-failed is emitted instead of continuing on to recreate graphics resources.

What Else Recovers Now

Framebuffer and background: The display now comes back on its own, no manual nudge required, and the pause is virtually unnoticeable. There is no blackout, at least from the compositor’s point of view. To the user, however, monitors driven by a GPU that resets may briefly go dark. The desktop background restores correctly and immediately: when a background image is set, loading it from disk can take a moment, so a plain colour is shown in the meantime. One caveat worth flagging for anyone testing this: background image loading was recently moved out of Mutter in !4980. That means reloading the image and reuploading its texture after a reset is no longer something Mutter can do on its own; it now falls on downstream consumers (like Shell) to handle it.

Window and surface content: Wayland surfaces restore to their last rendered frame right after recovery, instead of going blank until the next commit. When a client commits a new buffer in the narrow window between when a reset occurs and when it finishes, and the buffer attach fails because the context is already lost, the surface gets a dummy texture so nothing crashes, and the real content replaces it when we re-attach the buffer during restoration.

Cursors: Both Xcursor-based cursors and Wayland client cursors restore their textures on reset.

Actor effects: All ClutterOffscreenEffects (blur, desaturate, deform, shader, etc) recreate their GPU-side pipelines and textures on reset instead of quietly holding onto invalid ones.

Stream sources: Screencast and remote-desktop pipewire streams stop and restart cleanly around a reset, recreating the necessary GPU-side resources instead of ending up in a broken state.

Overlays: MetaOverlays (used for things like cursor sprite compositing) recreate their pipeline and texture too.

Along the way, a decent amount of the codebase moved from static and class-level CoglPipelines to named pipelines owned by the CoglContext, specifically so they’d get recreated automatically instead of leaking or going stale across a reset.

Tales From The War Front

The context that died too soon and then never died

Historically, objects didn’t take references to CoglContext; they simply held bare pointers to it. The reason was that there was only a single context for an entire session, which got destroyed at exit after all the objects associated with it had been destroyed.

Since the context is now recreated during recovery, this introduced a whole new problem: some objects now outlived their associated CoglContext, resulting in use-after-frees and segfaults. Specifically, some objects can not be destroyed until they’re replaced by new ones (after we have recreated the context) because they hold on to crucial states which get destroyed by lower levels of the stack as soon as they become inactive. There’s also the case of garbage collection, e.g in Shell, where the garbage collector may keep objects alive after we’ve destroyed their associated context.

To solve this, every object holding a pointer to CoglContext now takes a reference, and the context is explicitly disposed of and marked as defunct during recovery. The use of a defunct context is restricted so associated objects don’t make use of invalid data and silently corrupt memory. The context is finalized when the last reference to it is dropped. Also, with this change, we can more easily spot objects that needed to be restored after a reset.

With this in place, defunct CoglContext objects were, for a while, never finalized after a recovery cycle; they’d plateau at a fixed refcount and stick around. Tracking it down took multiple long GDB sessions. The actual root cause, once Jonas helped dig further, turned out to be leaked CoglPipelines and pipeline cache entries. The stencil and current pipelines weren’t being unrefed by the context, which in turn kept the default pipeline (their parent) alive too. There was also a cyclic dependency in CoglPipelineCache that only surfaced as a use-after-free once those pipelines were finally unrefed. Two separate bugs stacked on top of each other, and the second one was hidden by the first.

The popup that broke hell loose

During recovery, the whole actor tree is unrealized and re-realized, which started by unmapping everything from the stage down. With a popup open when reset occurs, this crashed at an internal invariant check. A thousand steps (in GDB) later… It turned out a ClutterInputOnlyActor, owned by the popup’s ClutterGrab, was getting destroyed mid-unmap. A grab doesn’t hold its own reference to an actor it owns. So when the actor got unmapped, the grab was detached, which in turn disposed of the actor, removing it from the tree. So, the unmap loop lost track of the next sibling and left the rest of the tree mapped.

The apparent fix was to have ClutterGrab take a proper reference to the actor it owns and pre-fetch the next sibling before unmapping so the loop doesn’t depend on an actor that might disappear underneath it. It worked, in the sense that the crash went away, but it turned out that removing a grab actor during recovery broke other things further down the line in ways that were harder to pin down. The real problem wasn’t how the unmap loop handled a disappearing actor; it was unmapping the actor tree at all as part of recovery.

The actual fix was to stop unmapping the stage during recovery entirely. Two new private methods, _clutter_actor_realize_mapped() and _clutter_actor_unrealize_mapped(), unrealize and realize the actor tree recursively while leaving everything mapped, with a flag on ClutterActorPrivate carving out an explicit exception to the established unmap-before-unrealize / realize-before-map invariant. Recovery now uses these directly without unmapping and mapping the stage, so the popup, its grab actor, and everything else stay exactly where they were.

The time-travelling touch

For a while, single resets were sometimes turning into two or three in a row, with no clear pattern. The reset trigger mechanism (used for testing without messing with real hardware) works by touching a file that llvmpipe watches for a changed mtime. That file lived in a virtiofs-mounted directory shared between my main machine and the test VM, and the mtime it ended up with was consistently a bit ahead of the VM’s and even my main machine’s clock at the time of touching the file, sometimes enough that by the time one recovery finished, the file still looked “new” and triggered another reset. Not a bug in the recovery logic at all or the manual reset implementation, just a quirk of the shared filesystem layer. Moving the trigger file to the VM’s own local filesystem made it go away.

Here’s a sample from one of my debug sessions (timestamps are the giveaway):

$ date -Ins && touch ~/llvmpipe_reset && date -Ins
2026-07-31T15:53:34,157134442+01:00
2026-07-31T15:53:34,160985080+01:00

$ stat ~/llvmpipe_reset
...
Modify: 2026-07-31 15:53:34.255579148 +0100
...

And the corresponding recovery logs:

Clutter-Message: 15:53:34.164: [RECOVERY]: Graphics reset detected
Clutter-Message: 15:53:34.251: [RECOVERY]: Graphics recovery successful
Clutter-Message: 15:53:34.251: [RECOVERY]: Graphics reset detected
Clutter-Message: 15:53:34.321: [RECOVERY]: Graphics recovery successful

Where Things Stand

The recovery mechanism itself is solid: Mutter survives GPU resets, the session stays alive and responsive, and the visible state (background, windows, cursors, text) is restored correctly, automatically and instantly. There are still a couple of edge cases I’m chasing down, mostly around rapid resets, but nothing that looks architecturally hard, just more debugging.

The implementation has now been submitted upstream for review. By the way, that MR is a clean recommit of the whole branch. The real development history, which can be found at my fork, was a lot messier: a lot of iteration, backtracking, and reordering as the design of the recovery cycle itself evolved. Once the approach stabilised, it made more sense to rebuild the commit history cleanly from the current state than to untangle months of exploratory commits.

Real hardware testing has also been trickier than expected. On the AMD GPU I tested with, the default reset method used by the kernel driver (MODE2) turns out not to invalidate EGL contexts, which means it can’t exercise the code path this project implements. The other reset modes either weren’t supported by the driver or failed outright. So testing thus far has mostly stayed in the VM, using the llvmpipe reset simulation Robert implemented before GSoC started.

Honest Note On Scope

Going by the goals set out at the start, this isn’t finished. A few things from the original plan are still ahead:

• GNOME Shell doesn’t fully recover yet: After a reset, Shell recovers successfully, but not completely. On-screen framebuffers, windows, cursors and text are restored. However, the Shell UI (the chrome, overview, widgets, effects, and icons) and desktop background image are not restored. Here’s a recording showing the current state of the UI:

• The llvmpipe reset simulation is not yet wired into tests or CI.
• Real hardware testing is still an open problem, for the reasons stated above.

I’ll keep working on these after GSoC.

What’s Next

• Chase down the remaining edge cases
• Get GNOME Shell recovering reliably; a few known to-do items include:
  • Clear the background cache and reload the image (will restore the desktop background)
  • Clear the texture cache (should restore icons)
  • Clear the theme node cache (should restore widgets and effects)
• Add test coverage using the llvmpipe reset simulation, and get it into CI
• Find a real hardware reset setup that actually exercises context invalidation
• Push the MR through upstream review

Reflection (A Personal Note)

I still remember opening gsoc.gnome.org on that fateful day “just to see what GNOME’s doing this year” and scrolling down just to see this project, and I was immediately drawn to it. I had known graphics was the path I wanted to take, and this project checked so many boxes. At the same time, I couldn’t deny how daunting it seemed. Yes, I have done some graphics work in the past (my GSoC project last year, in Uni and personally), but nothing of this scale. Anyway, I decided to take up the challenge; after all, why do it if it isn’t challenging?

Here are two notable challenges I faced, from which I also learned a lot:

• The sheer mass of the codebase: Man, Mutter is huge !! Coupled with the fact that my project cut across every layer and almost every aspect of it. I wasn’t building a compositor, but I had to understand how a lot of it worked. This wasn’t the kind of project that dealt with a single subsystem.
• Debugging, debugging and debugging: Logs are good and have their place, but also their limits. This project required using the debugger a lot. I’ve become so much more comfortable with sifting through logs and stack frames, and stepping through thousands of lines of code.

And here are three notable lessons I learned (more of):

• There’s always a simpler solution to any problem (thanks, Jonas).
• Keep digging, never give up: Some of the “bugs” I encountered just kept on giving. Some were like playing whack-a-mole, others like the hydra. Life is all about resilience.
• Community matters more: It’s good to get the job done, but the people we meet along the way are more important.

Throughout the course of this project, I got to do things I never imagined I would (at least, not this soon), like chatting on a kernel dev IRC . I could go on forever, but let’s call it a wrap here for now.

Thanks

A huge thank you to my mentors, Jonas Ådahl, Robert Mader, and Carlos Garnacho, for believing in me and for the guidance and hands-on help throughout. Thanks to Google and the GNOME Foundation for this awesome opportunity. Finally, thanks to the entire GNOME community and everyone who followed along this summer, asked questions, or gave feedback. GSoC has ended, but this isn’t done yet, and neither am I – more soon!

Together with Modal, I’m happy to announce that the Sovereign Tech Agency is investing nearly €510k into Flatpak development. The focus is on closing gaps in Flatpak’s sandboxing story: new portals for audio, networking, VPNs, and spell checking, plus infrastructure work on entitlements and intents.

I’ll be leading the technical side alongside Adrian, with organizational support from Kateryna and Cade. We’ve brought on a great team and the project will ramp up over the coming months through the end of 2027.

Read the full announcement on the Modal blog.

In Some Changes to GNOME Security Tracking, I reported:

I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

Hello! I'm Angelo Verlain, a Software Engineering student, and I've been working for the last 3 months easing the debugging process of GJS apps by adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC 2026).

A debugger is software for executing a computer program in an environment that allows for programming-level inspection and control. A debugger is often used to debug, but can be used for other goals including testing. Common features of a debugger include stepping through code line-by-line, breaking into the program's flow of control, managing breakpoints, and reporting and modifying memory. ¹

What is GJS?

GJS or GNOME JavaScript is a JavaScript interpreter that allows developers to write code that can leverage GLib/GObject and various other libraries that work with GObject Introspection like GTK, Libsoup, etc...

In practice, GJS allows you to write GNOME/GTK Applications and GNOME Components in JavaScript. The GNOME Shell & Extensions, GNOME Weather, GNOME Audio Player, GNOME Maps, Workbench are all examples of projects powered by GJS.

What is DAP?

The Debug Adapter Protocol is a a specification that describes how messages are passed between a debugger client (for example, your IDE) and server (such as the Node.js or any other language runtime). It specifies and communicates pausing & continuing execution, setting breakpoints, stepping through the code, viewing stack traces, and more. It works by defining a standard way for your development tool (e.g. GNOME Builder, VS Code, Zed, etc...) to connect to a debugger.

Today, you can already debug applications and libraries written for/with Android, Node.js, Deno, C, C++, Rust, Python and more. This project aims to make GJS applications debuggable in your favourite editor or debugger by implementing a DAP adapter for GJS.

Adding DAP to GJS

GJS already supports debugging programs by use of the --debugger flag, which spins up a GDB-style CLI interface where you invoke it by running gjs --debugger [file-name].js and writing commands like breakpoint [line], step, frame to set breakpoints, step through the code and print the stack frame respectively.

It works well, but it's different from the GUI debugging that’s more popular these days.

Here's an example of GJS debugging the following code saved as test2.js

function print(i) {
  console.log(i);
}

for (let i = 0; i < 10; i++) {
  print(i);
}

If GJS had support for DAP, you wouldn’t be limited to just using the text mode debugger, but could debug applications using your favourite editor (Zed, VS Code, etc…)

The workflow would be easier too: Press F5 to debug (standard hotkey), specify the path to your entrypoint, and then run the program. To set a breakpoint, simply type the debugger keyword or click in the gutter/margin of your editor (even after your program has started execution!).

When the program reaches that breakpoint, you will have a nice stack trace showing where the program stopped, and give you options to inspect the current variables in the different scopes, continue execution, or step next, in our out of frames.

Here's an example of debugging the same script using VS Code's Node.js adapter (the experience we want):

Note that you can more clearly see the variables, call stack and breakpoints in the debugger.

Scope

My work is focused on launching & debugging GJS apps.

The scope is also limited to launching & debugging GJS applications or running scripts in the GJS interpreter and debugging them. Attaching to already running applications is not in scope.

Concretely this also means that debugging components like the GNOME Shell is not in scope.

Furthermore, I have only written an extension for Zed since it’s the editor I use, but other editor extensions like VS Code, Builder, and Emacs could be implemented as a follow-up task and will be relatively easy since GJS itself implements the DAP specification and we just need to bridge the two. If you want support for a specific editor or debugger, please let me know :).

Progress

I've made significant progress on the project.

The project period is coming to a close and I’ve made significant progress. Currently, the following is implement:

• A work-in-progress GJS DAP Extension is implemented, which allows you to debug GJS applications inside the Zed Editor. It's not yet published to the Zed Extension Store though
• You are able to launch a GJS program or run a file and break on entry
• Automatically pausing on debugger statements
• Ability to add breakpoints by clicking in the gutter/margin of the code editor (even while the app is running!)
• When execution pauses, you are able to resume execution to the next statement, or step in/out of functions/methods/scopes.
• When execution pauses, you can see all the stack frames
• When execution is paused, you can also inspect the different scopes and the variables defined in all of the scopes

My next steps will focus on the following:

• Implement a VS Code Extension so you can also debug GJS applications in VS Code in addition to Zed
• Allow configuring breaking on Caught and Uncaught exceptions

Figure: Debugging a program with a visual debugger (Zed), showing breakpoints (red circle in the gutter), current line highlighted and variables

I’m looking forward to sharing my progress when we get to the end of the program! Expect another blog post in the next couple of weeks.

Almost two months ago I went to my first GUADEC conference. While I’ve been busy since then, writing proper travel report has been something I’ve been putting off for a while. Without much further ado, here’s a report of my impressions

First impressions

It’s always a bit nervous to go visit a conference for the first time. While I’ve been at many conferences where I’ve given talks on international stages before, GUADEC has felt different to me. Mostly because there’s so many people I’ve known from online interactions, yet nobody that I have ever met in real-life.

While it’s usually a pretty obvious conclusion that people that are nice online are so in real life as well, there’s always that voice inside that fears feeling as a complete outsider. While I’m not new to FOSS, having used Linux since 2006, and publishing applications within the GNOME-ecosystem since 2022. I am still a relative newcomer when it comes to engaging a bit more active and vocally.

Fortunately, I found directly that people were really nice. And actively tried to engage me in discussions as well. Many gnomies recognized me, and approached me first. Which nice feeling welcomed into an established community, and definitely makes it easier to engage on other fronts as well.

Talks

There’s been a lot of interesting talks and workshops that stuck with me. I’ll just do the egomaniacal thing and talk about my own talk first: A Brief History of Graphs. The reason I’m putting it on top is not that it’s the best one, but it was obviously a highlight to be able to present my journey within this project to the rest of the GNOME community. The talk is about how I started developing applications, and the lessons learned along the way through community feedback and GNOME Circle. A large part of the main focus ended up being pretty design-focused. But that’s also where much of the lessons are to be learned. You cannot create a great app without putting design first, before the technology. And by that I mean design in a big way. Not how it looks, but think about what it should do before even considering what it could potentially do given the technology at hand. Designing from a technology-first mindset leads to a worse experience for all. It’s food for another blog, but I don’t think it’s a coincidence that every project that explicitly claims to put technology over people¹ kinda sucks.

Either way, it’s been my entry point into GNOME, and has given me a lot of fulfillment over the years. I encourage everyone to start to contribute and engage. It’s gotten much more difficult over the years thanks to shortcuts in the form of text-prediction machines, but there’s really a lot of value of getting it wrong and learning along the way.  It wouldn’t be there without the human interactions behind that journey.

Enough babbling about my own talk, here’s just a list of talks that I found particularly interesting:

• • • Towards a Local-First Desktop – by Julian Sparber and Tobias Bernard. This in particular is a very important topic to me. I don’t want to sound like an alarmist, but we need to prepare for a future where we may not always have access to a large centralized internet. Not only has this been proven by recent geopolitical circumstances, it’s not like we’re making any progress in avoiding a major climate catastrophe. Local-first technology allows us to remain resilient, even when our centralized infrastructure is under pressure, be it due to geopolitical pressure or by force of nature. Very interesting talk about a very cool technology.
    • The related local-first workshop in particular has been really cool as well. We hacked together a quick implementation of local file transfer within a few hours. Julian showed us how easy it is to get local sync to work with p2panda. I will definitely hack further on this in the future when I have more time on my hands. In the end we managed to send information between devices in a simple Python program.
    • Session Save/Restore – By Adrian Vovk. I never really realized the potential of this feature, Adrian makes a really good case of showing what this feature would provide. But most interesting to me was how complex things are. Once the first prove of concepts were shared a while ago, you’d might make the mistake of thinking it’s just some formal implementation, but there’s a lot of moving parts, and the talk really provides a get a good sense of why these implementations take as long to develop. Fantastic work by Adrian.
    • Performance profiling Mutter, GNOME Shell & apps with Tracy – by Ivan Molodetskikh (YaLTeR). I don’t do Mutter or Shell development, nor have I really used profilers in the past. But Ivan really shows how powerful profilers (Tracy in particular here) can be. I’m highlighting this talk in particular because it inspired me to do some profiling in Graphs (with plain cprofile), nothing as fancy, but we’ve had some significant performance upgrades since then!
    • GNOME Internationalization: accessibility for all over the world – Very nice talk by Guillaume Bernard about internationalization. This one has mostly stuck to me because he has some very clear examples how difficult translations can be. While some things might be obvious, such as the order of words being different, but there’s a lot more subtleties than expected such as counting and pluralization being different as well. He makes a really good case about why it’s important as app developers to use proper practice such as not breaking up sentences, using gender-neutral language, and using the correct categorization and calls to gettext.
    • Beyond #RRGGBB: cross-application color palettes the slightly hard way – By Nathan Willis. While color pallets are maybe not the sexiest topic for everybody, I find it super-interesting to listen how such settings are a bit of an unstandardized clusterfuck where pallets are all stored differently with different names, formats and locations. While I don’t have the impression that this is better in the closed source world, it is less than ideal in creative work when working with multiple applications. Very entertaining talk to listen to.
    • Lightning Talk: GNOME Shell Design Dreams – Obviously the Design dreams talk had to be included. It’s just very cool to see the thoughts and plans on the future of Shell. It’s no wonder this talk did numbers online as well. I’m in particular looking forward to improved search, and improved quick settings.

Traveling to and in A Coruña

Getting to A Coruña was not ideal, but not terrible either. Unfortunately travelling by train was not very viable for us from Sweden, but we are lucky enough to have an international airport in Linköping with direct flights to Amsterdam. From there, it’s single flight to Madrid, and then another one to A Coruña. All by all, we woke up at 04:00, and arrived somewhere around dinnertime.

Traveling to and from the venue worked relatively well. There’s a local app for public transport, where you can bus-rides for dirt-cheap. Buses went often. Walking around within the city was less practical. I realize I’m probably a bit spoiled from my own hometown. But to me A Coruña felt very car-centric with very trafficked roads going everywhere, and only a minority percentage of the public spaces being dedicated to pedestrians. This is not a city where I would dare to take a bicycle, which I was considering at first as an alternative to the bus. Where I’d have to add that I’m saying this having grown up in the Netherlands, where bicycles often are prioritized over both pedestrians and cars. In fact, it’s the only country in the world with more bicycles than people.

The beach was very nice. Being situated at the Atlantic, A Coruña has a wonderfully mild climate compared to most of the European South. Living in the North, temperature is always a bit of a concern when traveling to Southern Europe during the summer, especially nowadays. Temperatures in general were around a comfortable 25°C. We had some warmer days were the temperature passed 30°C, but given we were in a European heatwave where Madrid was close to 40°C, I cannot complain.

The Venue

The venue was hosted at the Informatics Faculty of the University in Coruña. It was easy to find the entrance from the bus, and it offered a nice public space for the coffee breaks and general mingling. The main stage was large and comfortable. The second stage, where I had my own talk was hosted in a regular classroom on the top floor. Whilst it’d have been nice to have the stages somewhat closer, the path to the second stage was labeled very clearly, and we were never over capacity in any of the stages. Another really nice thing is that there were many possibilities to charge electronic devices. On my own laptop, which doesn’t last for much more than a few hours, this has been very useful. Especially during the local-first workshop. The conference itself went smooth with no major delays or unexpected outages. Shoutout to the organizers for making this a success!

One area that I would have liked to see some improvement was the availability of plant-based options. In particular during the first day, there were no non-meat options on the menu, and the restaurant staff did not seem prepared for multiple people wanting to have a vegetarian alternative. This also is related to the fact that vegan options in general seem very niche in Spain (or at least this city), but for an international conference the restaurant staff should probably have been a bit more prepared for such dietary requirements. My initial ambition was to keep myself to completely plant-based options during the trip, but quickly gave up on that when arriving to A Coruña.

Special Thanks

I really want to give a special thanks to the GNOME Foundation. Partly to all the people who made this possible by organizing this. The local team in A Coruna, the volunteers, and anyone else that took part in organizing this. Also thanks to the people making nicer pictures than me, this includes the staff that has been hired for this. All images apart from the top one with the tower, and me holding an ice cream have been stolen from the GNOME Cloud. The conference overall has been a real nice experience, and it really gives energy to do more. There’s been some areas where I’m getting a bit more further involved in the meantime as well.

Also, I should really thank the GNOME Foundation for sponsoring my travel. It’s been a very expensive trip from Sweden, even when going alone, and I couldn’t have taken those expenses without getting reimbursed for part of the trip. It is really appreciated, and these programs really help for new people to get involved!

1 – To be fair, these projects claim to put technology over politics, not over people. It should be noted that they never mean marginal tax rates, it’s always about policies like the CoC and the right to kick down at disenfranchised minorities such as trans people. Ergo, putting technology over politics in this context is by definition putting technology over people. Unless you don’t count minorities as people. With some of these folks, you never know.

I’m on a VPN setup with several friends that, obviously, includes a VoIP network. I also have an old magicJack adapter and a deep and abiding need to use hardware in ways I should not. There was obvious synergy here.

Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to a company called TigerJet who made a range of chips for hooking up phones to computers, either via USB or PCI. Some more digging suggested that it was a 580 part, and someone had conveniently uploaded some reference code and datasheets, so figuring out how to talk to the chip wasn’t terribly difficult. Once configured it simply sends HID events whenever a user hits a phone key or changes the hook state, and otherwise exposes a USB audio device that can be spoken to using the stock kernel driver. It also has the ability to generate dial tone and assert ring signal, giving a full traditional phone experience.

So you’d think this would be a super easy project, but I’d made things harder for myself by deciding I wanted to tie directly into Asterisk rather than just smashing an existing SIP stack onto the device. Asterisk uses channels to talk to devices, and channels end up as compiled C code that Asterisk can load dynamically. I didn’t want to have to deal with the pain of compiling stuff and matching ABIs and everything so writing a new channel from scratch was unappealing. Fortunately, the websocket channel is available in recent versions of Asterisk and provides a convenient way to get audio in and out, but that still leaves the job of handling incoming and outgoing calls. That’s handled with the Asterisk Rest Interface, which can initiate a call or respond to an incoming one and bridge various channels together to produce a bidirectional audio stream. There’s a convenient async Python library that handles the low level protocol.

Code for all this is here¹, and works for my use case, but I should really abstract out the asterisk side and the magicJack side to make it easier to adapt to other devices. That’s a job for later, though. For now, you get this:

In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.

For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).

The fellowship is time-limited, so I am intending to make the time I currently have count!

So, what’s planned?

I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:

Freedesktop.org, Specifications and Organization

I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.

While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).

Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.

In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).

AppStream

A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.

AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.

I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.

PackageKit & System Upgrades

Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.

My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.

In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.

That’s a lot of tasks!

Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.

Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .

You can also expect blog posts about key features or interesting changes, so stay tuned!

Week 30

This week's icon is for Titouan Real's project:
Era: "Manage your time"

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!).

In recent weeks, I’ve been working on adding key rotation support to flatpak, so that repositories which sign their commits and summary files with a key with an expiry date have a way to push updates to that key to all the clients which use them. Currently that’s not possible without each client manually having its config updated to use the new key data (even if the change in key data is just to bump the expiry date).

In the process I’ve learned a few more things about GPG keys, subkeys, signatures, UIDs, etc., which I thought I might dump here in case it’s useful for someone else (or me, in the future). I don’t claim to be an expert, so I may still be misunderstanding some bits. GPG is complex. One thing which has helped ground things is finding the documentation in RFC 4880 (and related) which defines the GPG packet format.

One thing which keeps flatpak’s use of GPG simple is that it doesn’t use any of the web-of-trust features or trust-on-first-use (TOFU). Its use of GPG is limited to the keyring format (essentially pubring.gpg), for storing and publishing public and private keys, subkeys, signatures, revocations, UIDs; and using them to sign and verify OSTree commits and various repository files (summary, summary.idx, etc.).

Quick primer on the parts of GPG

GPG has keyrings: collections of primary keys. A primary key has public and private/secret parts. The way flatpak uses it, the secret part of a key always stays on the server, and is used to generate signatures. The public part is published by the server and configured in every client using that repository, used to verify the commit signatures. Each client has one keyring per remote it has configured. Typically this contains one primary key, but it could contain several, any of which can be used to verify signatures from that remote.

A key is identified using a fingerprint, a 40-character hex string. It can also be identified using a key ID, which is a substring of the fingerprint. There’s also keygrips, but let’s ignore those.

You can see fingerprints for keys using gpg --list-keys --fingerprint.

A primary key has one or more subkeys (at least in flatpak’s usage). All of these keys have public and private/secret parts as above. Each key has a usage which indicates what GPG will let you use it for, such as certifying, signing, authenticating, encrypting. The primary key is typically used to certify its subkeys by creating cross-certification signatures which bind them to the primary key, forming a short chain of trust — anyone who trusts the primary key should trust a subkey which it cross-certifies.

You can see subkeys as the sub lines using gpg --list-keys --with-subkey-fingerprint. The [SCE], [S], [E] (etc.) fields show the usage flags for a key.

The other usage we care about is signing (flatpak doesn’t use authentication or encryption usages). GPG separates keys by usage to prevent attacks where a key is used for a purpose it’s not intended for, and because keys used for different purposes often need to be treated with different levels of care.

In particular, separating by usage means the private/secret part of the primary key can be kept completely offline, and only brought out in a special key signing ceremony when a new subkey needs to be generated and cross-certified. This reduces the risk of the very valuable primary key, which is the root of every client’s trust in the repository, being leaked.

So, we use a signing subkey for day-to-day signing of OSTree commits. For a big flatpak repository, the private/secret part of this subkey might be kept in a hardware security module, so it can’t be exfiltrated from the server if the server were compromised. But there’s still the risk of a compromised server being used to sign things it shouldn’t (such as malicious apps).

That’s a matter for server security, but we can somewhat mitigate against the possibility of the signing subkey being leaked by setting an expiration date on it. Clients might choose not to trust signatures made by it after that date; and gpg certainly wouldn’t allow it to be used to create new signatures.

The expiry date of a key is shown as an expires field in the gpg --list-keys --with-subkey-fingerprint output.

What happens when the subkey expires? By that point, the administrators should have generated another subkey, cross-certified by the primary key in a key signing ceremony (I assume the ceremony involves cake). The private/secret part of the new subkey needs to stay secret, as before; but the public part needs to be distributed to every client’s keyring, along with the new cross-certification signature from the primary key, so the clients know they can trust signatures made by that subkey.

That’s the bit which flatpak is currently lacking.

So in summary: GPG has keyrings. Keyrings have primary keys. Primary keys have one or more subkeys and cross-certification signatures from the primary key on those subkeys. Each subkey has a usage, but flatpak only uses certify (for the primary key) and sign (for the subkeys). Keys can have expiration dates.

And if you want to see the full contents of a keyring, run gpg --list-keys --with-colons. It’ll output everything (no filtering) in a machine readable format described here (best reference I’ve been able to find), which is sometimes easier to use than remembering which --with-blah option to pass to GPG to get it to show the information you want.

What else does GPG have?

Quite a few things. We’ll ignore the big things which are not relevant to flatpak.

Each primary key also has one or more UIDs. These are like subkeys in that they are cross-certified by the primary key. Each UID is a user identity — typically a name and email address. If you were using GPG in a web of trust, the binding between the primary key and a UID is what you sign that you trust when you sign someone’s key in a key signing party.

The UIDs are listed below each primary key in gpg --list-keys.

Flatpak doesn’t need UIDs, but they are an unavoidable part of GPG — each primary key must have at least one. A flatpak repository will typically put a server contact email address in the UID and then everyone will ignore it.

UIDs can be revoked; for example if someone loses control of the email address in it and wants their friends to no longer trust emails from it. Flatpak currently doesn’t use this.

What else can be revoked? The cross-certification signatures! You may have heard of a GPG revocation certificate. This is a way of revoking an entire primary key. But there’s also a way of revoking a particular cross-certification signature, meaning that the primary key is still valid/trusted, but the owner of the primary key has lost control of one of the subkeys, and that subkey should no longer be trusted. This is different from key expiration, as it’s a statement that something has explicitly gone wrong.

Because of how GPG is built up as a series of packets of different types, a signature revocation is actually a revocation packet appended to the primary key. This means you can re-cross-certify a subkey after revoking it, by appending another cross-certification packet. And even revoke it again after that. Not sure if there’s a use case for this or if it’s just a consequence of the packet format, but this behaviour does play havoc with working out whether to trust a subkey.

Cross-certification signatures can also have an expiration date built into them, separate from the expiration date of the subkey. I’m not sure of the use case for this either, but there must be one.

Some notes on running GPG on the command line

GPG is historically famously hard to use. I feel this has got better in recent years, particularly for scripting it. In particular it’s added a whole load of --quick-blah commands to generate keys, set expiries, etc. from scripts.

One thing which repeatedly tripped me up before I stopped trying to fight it was its concept of a ’homedir’. GPG needs to look for its keyring (and trust database, and various other files) somewhere, and will not run without them, so you always need to pass it a ‘homedir’ to look for them in. By default, this will be ~/.gnupg, so it’s very easy to accidentally end up operating on your personal GPG keyring when you’re trying to do something in a project.

If using GPG as a tool or in a script, I think you should always create a temporary homedir, pass it as gpg --homedir=/path/to/temp and explicitly import whatever keys or context you need into this homedir before doing whatever operation you need.

This is necessary even if ‘all’ you want to do is view a downloaded .gpg keyring, because what GPG displays may be affected by the trust database in its homedir. So to view a downloaded keyring you should still do something like mkdir temp; gpg --homedir=./temp ./path/to/download.gpg.

If you are trying to sign something, you will typically pass the fingerprint or key ID of a primary key to GPG; for example as gpg --local-user 0xfingerprint --sign ./path/to/file. GPG will helpfully use the usage flags of the subkey of that primary key to choose which subkey to sign with. If you want to sign with a specific subkey, you need to suffix the fingerprint with an exclamation mark (!) otherwise GPG will still choose what it thinks is the most appropriate subkey, which might not align with the subkey you carefully chose. This ! suffix format is common throughout the GPG command line interface for when you want to specify a specific subkey.

Sorry

That was more of a braindump than I imagined when I set out to write this. I hope some of it is useful; feedback welcome if I’ve got anything wrong. If any GPG experts fancy reviewing key rotation support in flatpak, the draft implementation is here.

Hello,

Here’s some thoughts on software for August.

Bear with me on these broad categories but I think you can group most software projects into one of these groups: art, infrastructure, and activism.

Art is primarily to communicate experiences and feelings to others. Making video games is art. Making digital musical and instruments and visual effects is art. The drawing you did as a child that’s stuck on somebody’s fridge is art. The 3rd year computing student’s university coursework, uploaded to Github without comment and abandoned forever… that’s art, or at least, it’s a sketchbook. The thorny entry to the IOCCC, the optimized inner loop deep in some graphics toolkit, that only a handful of people will ever look at, but all of them will agree: that’s art.

People make art for fun, learning and practice.

Infrastructure is stuff that is needed and expected for the world to function. The definition of infrastructure changes over time, as societies adopt and depend on new technologies. Roads, milk delivery, electricity, bakeries, aqueducts, supermarkets, the internet, trams, the lift in your apartment building, and so on. Many societies depend on software projects now. Web browsers, phone cells, operating systems, social networks, software developer tools, power grid management, Google Maps, and so on.

People make infrastructure for money, or perhaps out of a sense of duty.

Activism is a desire to bring about a particular social or political goal or change. I don’t know when the first activist software project started, but it was no later than the 1980s when the GNU project began its stated mission to make proprietary software unviable via copyleft, and many free software projects followed along. The design of the GNU C compiler was shaped by the mission. Tor began in the 2000s with the goal of ensuring private, uncensored internet access. Bitcoin began with the stated aim of destroying the financial system, the wake of the 2008 bank crisis. Although in many countries it’s now regulated financial infrastructure, which shows you that projects can move between these categories over time.

People spend our energy on activism based on our beliefs, usually a sense of wanting to make the world a better place for everyone, or at least for ourselves, and our friends and family.

Not everything fits into these categories (the biggest gap I can see is experiments and research) but let’s keep this short, I want to use them to look at the conversations I keep seeing in the open source world this year.

When one person sees a project as activism and another sees it as infrastructure, you see some genuinely confused conversations happening.

Codeberg banned projects with largely AI generated code from the site, and Sourcehut is considering doing the same. If you see these projects as Git hosting infrastructure similar to Gitlab and Github, then that decision makes very little sense. Why would they want to host fewer projects? However if you see the project as a group of activists trying to reduce the power and influence of US tech firms, and limit the harms of rapid of adoption of AI, then it makes a lot of sense.

Linux decided to allow some LLM use and not put too many limits, as long as its making the project better. If you see Linux as a bunch of engineers building infrastructure then it’s a very logical decision. But if you thought your contributions were part of some activist movement then that might be a disappointing decision.

Every so often I hear someone say things like “please keep politics out of software”. You can infer that they’re probably talking about infrastructure software — and it’s as misguided as if they said it about any other infrastructure. Is an aqueduct political? If one country is seen as stealing another country’s water then… yes. Can a shipping lane be political? Yes, see numerous examples, including the ongoing US-Iran conflict. Can a road be political? Yes, if it crosses a border, especially if it’s in dispute. Ask someone old from Berlin or the north of Ireland about whether roads can be political.

Maintaining software takes a lot of effort. If someone is putting in that effort without being paid, they have some other motivation for doing it. Humans rarely do difficult, laborious work for no reason. Our motivation might be to learn, to show off, to have fun, to meet people, to collaborate with friends, or it might be to work towards some kind of political or societal change. I’ve probably contributed to open source for all of these reasons at different times.

We are increasingly referring to open source software as “digital infrastructure” and funding some of the maintenance work via corporate money and public money. This is great, but it requires the project to frame itself as infrastructure rather than activism. You are unlikely to get funding from Microsoft if you openly state that your goal is to destroy Microsoft. You are unlikely to get funding from a government if your stated goal is to destroy the modern financial system or prevent all forms of censorship.

Activists using open source licenses have something of a problem to deal with. If your goal is to bring about world peace, you hardly want people building drones and missiles using the software you develop. Yet the open source movement have made it clear that if you try to limit who can use your software, it’s no longer open source. And, many software engineers have made it clear they don’t give a shit about software licensing anyway and they’ll use your code however they want without even reading the license.

You can control access to software infrastructure, of course, just like you can put soldiers and passport controls on a bridge or a road. But you can’t call it open source any more.

The GNOME desktop project is art, infrastructure and activism. The discussion on Reddit is mostly people who design and post desktops and themes for fun. Several corporations build products with GNOME, and treat it as infrastructure. And then there are contributors who want to bring about change, perhaps weakening the power of Big Tech by spreading an ethical alternative to Android and iOS.

GNOME hasn’t made a statement on AI use, and I don’t think we’ve tried very hard to discuss it so far. I wonder if we’re putting it off because we’d have to also discuss whether our goal is to maintain some infrastructure, or build something cool-looking, or bring about meaningful societal change?