Planet GNOME

It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.

For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

I realized that deleting local copies of files early and often is better than keeping them forever.

I'm the kind of person who will work on something, share their work, and then just let the file I had linger around indefinitely. You never know, it's better to have a local copy, it can save the day. Or you keep it at hand when you're offline. And do I really need a reason to keep a copy of the file I was working on anyway? Hoarding files and keeping them forever is tempting.

The one thing I've overlook in the past is context. When I produce or get a file, I do so in a specific context. But if I want to do some cleanup later I will certainly have lost that context, or have fragments of it. I won’t know if I can delete it safely or not, so I will keep it forever. The longer a file has been around, the more difficult it becomes to delete it.

The best thing I can do in a work context is to make it not a me-problem. Whenever I get or produce a file, I make sure there is a copy of it in a company shared drive, and I delete it from my machine as soon as possible.

Throwing it over the fence is bad behavior of course, so I make sure it’s stored somewhere with as much context as possible for people who need to use it. My machine stays decluttered, and if it’s stolen I "just" lose hardware, I have a safe copy of my work data, and there is little to leak on my (encrypted) disk.

Note: this is true for documents because all versioning systems are terrible. This is not true for code thanks to git and the like.

For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.

I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.

Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.

Screenshot of the Fingerprint Authentication dialog

The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.

Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.

Screenshot of a fingerprint enrollment

This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!

Some time ago I visited a used book fair and came across this awesome piece of 80s scifi-asthetic.

This book is a collection of short stories by the Polish author Stanisław Lem originally published in 1964. Its English title is The Cyberiad. One story, about Trurl's electronic troubadour, turned out to be surprisingly topical.

Spoilers for the whole story follow

The inventor Trurl (revealed in other stories to be a robot) wants to create a machine that can generate poetry. He begins by obtaining several hundred tonnes of books to use as training data.

Trurl gets to work constructing the electric poetry machine. In the process they have to create massive data storage containers that stretch further out than one can see using binoculars. This is considered a necessary evil to get this great invention going.

The machine will not work as expected. As a last resort Trurl rips out all logic circuits and replaces them with "narsistors". Then things start working.

Trurl invites his friend Klapaucius over to test the new machine. They give it all sorts of weird and wacky instructions like "create a pastoral love poem that also contains mathematics and cybernetics". Basically they do a whole bunch of prompt engineering. They talk and behave exactly like people of 2021-2023 did when LLMs first appeared.

Eventually the machine causes uproar among poets and there are protests demanding it to shut down. These go nowhere in part because the media secretly love the machine. They are using it to create their own content for pennies and thus don't want to see it come to harm. As all of this is going on various people develop symptoms quite similar to modern day AI psychosis.

Things eventually crash when Trurl gets the machine's electrical bill, which turns out to be astronomical. He needs to get rid of the machine and manage to dump it on a visiting dignitary who takes it to his home planet where causes a supernova explosion. Trurl deems that to be sufficiently far away to not be his problem any more.

The difference between fact and fiction

In the story all the problems are caused by the fact that the machine's output is vastly higher quality than anything humans can create. Even the great Stanisław Lem could not predict that in reality the output would turn out to be mediocre garbage and still lead to all the same problems.

Even though the story specifies that the machine is given some "basic instructions" first, nobody tries to do a prompt injection attack on it. That would only appear almost 30 years later in 1993's Paranoia novel Title Deleted for Security Reasons. An earlier example may well exist somewhere, it almost always does.

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.

If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell.

Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies.

A compact decision tree Can it run bash or arbitrary code? ├─ Yes → Run a generic agent in a sandbox └─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"? ├─ Yes → OK, maybe LangChain or equivalent makes sense └─ No → Goto start

I also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed.

Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system.

Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all.

Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it.

I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.

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.