Overview

My project was to write the Pitivi Timeline Ruler in Rust using GTK4 and create GObject bindings for it. The project goals overall went well, and I was able to complete the widget successfully along with adding a layout manager structure to the ruler for child widgets to be added from the Pitivi/Python side. My standalone repository contains a working Python demo to verify successful FFI functionality.

Integration into the Pitivi application is not complete. The GTK4 port branch is still a work in progress and is not quite ready yet for deployment.

My commit adding the ruler to the WIP GTK4 branch can be found here .

My repository containing all of my commits and the standalone widget with demos can be found here

Plan Going Forward

I will stay actively involved in the GTK4 porting effort, apply for GNOME membership and stay involved in the Pitivi project. The GNOME community has been very welcoming, and I plan on continuing to contribute both to Pitivi and the broader GNOME ecosystem for the foreseeable future.

Design

General Architecture

A major structural change that has been made after mentor feedback was to move application orchestration out of the widget itself, and keep more of the logic on the app side. The design is a "dumb widget, smart app" framework, where the ruler does not own editor policy.

The app provides the logic for how to handle gestures and what to do when the user interacts with the widget. One example of this is that project_duration was removed as a property entirely, and logic around bounds is now handled entirely on the app side. This allows the widget to be used in a variety of contexts, and allows the app to handle bounds in whatever way is appropriate for the context.

The rendering code also received a fairly large cleanup. Previously, the widget stored several pieces of drawing state separately, including adjustments, cached Pango layouts, and font descriptions. These have now been grouped into a single DrawingState struct behind one RefCell . This made ownership easier to follow, and allows the code to release it's mutable state borrow before connecting or disconnecting signals.

I also introduced a labels_dirty flag so timeline labels are only recalculated when they're actually needed during the snapshot phase, rather than repopulating the cache with every setter or adjustment call.

The widget follows font and color settings from the users GTK4 theme, allowing user theme changes seamlessly.

Time Markers

The ruler utilizes a BTreeMap to cache the text markers that are visible at the current window size plus a half a screen size buffer over either edge. I used a BTreeMap because it offers high efficiency insertion, deletion, and lookup for this case where our markers are sorted.

The ruler recalculates the spacing needed between labels by calculating an intentionally wide timecode using the current font and some padding. This measurement is cached until a change in frame-rate or font invalidates it.

Labels include frames when zoomed in below 1 second, and drop the frame count when zoomed out past that point.

Major Ticks and Intervals

Major divisions are calculated using a two-mode strategy. First, the pixel density is calculated to determine whether a one-second interval can meet the minimum label spacing. If so, frame-aligned intervals are used, with the smallest interval meeting the minimum label spacing selected.

If one second is too narrow for a label, frame alignment is abandoned in favor of whole-second intervals, selecting the smallest interval that meets the minimum label spacing from a pre-defined list. This list can be tuned later to meet Pitivi's UI needs.

Minor Ticks

After discussing ticks with some video editors, I realized that frame alignment is more important to the video editing community than clean time divisions. Because of this, I made the decision to implement a reverse modulo loop to consider possible intervals from largest to smallest that accurately divide frames. The resulting spacing is also checked against the minimum tick spacing to make sure we don't end up with a block of ticks that are too close together. The result is that our minor ticks are asymmetrical and are not even as the user zooms in and out, but they do always accurately divide by frames in the major interval.

Layout Manager & Layout Child

We needed some mechanism to position arbitrary external widgets (play-head, markers, loop-brackets) on the timeline. The timeline uses nanosecond timestamps, so the parent ruler determines x-cords for the children based on the zoom and horizontal scrolling position.

I introduced two objects (public C-wrapper and Engine):

1. PitiviTimelineLayoutChild
   • Subclasses gtk::LayoutChild .
   • Metadata wrapper for generic widgets dropped onto the timeline.
   • Adds a custom GObject property for timestamp .
2. PitiviTimelineLayoutManager
   • Subclasses gtk::LayoutManager and is installed on PitiviTimelineRuler .
   • Creates the custom layout child for each child widget.
   • overrides measure() and allocate() .

During allocation, the manager reads the ruler's ns_per_pixel , horizontal adjustment, and the child's time stamp to determine the child's x-coordinate. The child is centered on it's time stamp and scrolls with the ruler. The Python demo shows an example using ruler.add_marker(playhead, 0) to add a play-head at the start of the timeline.

Bindings and Build

The FFI layer in ruler.h and capi.rs expose the following small API:

• pitivi_timeline_ruler_new() creates a ruler as a GtkWidget .
• pitivi_timeline_ruler_clocktime_from_pos() converts an x coordinate to a nanosecond time stamp.
• pitivi_timeline_ruler_add_marker() adds a child widget at a time stamp and returns a layout-child object.
• The properties of the ruler are exposed as GObject properties, and can be set and retrieved using standard GObject property accessors.

The Process

Challenges

The FFI bindings were a major challenge for me. I ran into significant challenges fixing bugs and understanding conceptually how the Rust bindings actually worked. My initial FFI attempt did compile, but I had to work through significant GTK initialization and headless CI issues. The fixes show up in my commit history as changes of a couple of small lines of code, but the time spent understanding the issues was significant.

I also came into this with very limited knowledge about Flatpak and Meson. Getting myself to a point where I understood what the build systems were doing took a significant amount of effort. I think I spent about the same amount of time reading about GIR, GObject, Flatpak and Meson as I did writing the code. For a very small percentage of the actual code, those tools required the most attention. I view this learning as really valuable for future work in the GNOME space, and I tried to take as much time as I could afford to do my best to genuinely deepen my understanding.

The rendering logic, while similar to previous GTK4 widgets I had built, ended up having numerous rounds of refactoring and learning. I wrote about 4 different strategies for scaling, multiple designs for splitting time and frames and multiple minor tick rules. Even once I was settled on a design, I had multiple waves of finding cache inefficiencies, clearing stale entries, and removing precision and allocation bugs. The ruler is visually small, but the underlying math and rendering logic took quite a bit of work to really get to a professional standard. I would not be surprised if the logic changes again in the future as I continue to work on the Pitivi GTK4 port and get feedback from the community.

Major Milestones

• May 3: Built the initial window render as a standalone GTK4 application.

• May 8: Added the initial GObject getter/setter structure, a GtkScrolledWindow test, and zoom bounds.

• May 9-13: Drew the initial major and minor ticks, changed the scale to nanoseconds per pixel, and added Pango labels to test scale behavior.

• May 14-28: Reworked time stamp math, wrote code to extract frame-rate from video's GES timeline which was later scrapped, and refactored rendering of ticks to draw a single interval and then paint it repeatedly across the ruler.

• May 30-June 4: Wrote the dynamic label-width measurement, minimum tick spacing, and frame-oriented major/minor interval selection structure. Added gtk::Scrollable interface to the ruler.

• June 6-26: Refined cache eviction for scrolling. I also addressed zoom drift, font and DPI changes, adjustment-signal cleanup, and precision around the playhead coordinates. I wrote the unit tests for subdivision and timecode math in this period as well.

• June 30-July 3: Removed redundant APIs, moved gesture handling to the app side, refactored types throughout the codebase, and removed the widget's project-state ownership.

• July 5-25: Created the initial FFI bindings and the layout manager and layout child, and then attended GUADEC in A Coruña, Spain. I managed to resolve the GTK initialization CI issues and successfully exposed the ruler and layout child.

• July 26-29: Added dirty-label cache invalidation and consolidated the rendering state into DrawingState struct. These optimizations simplified borrow management and reduced thrashing the Pango cache.

• August 1-12 - Added the Python demo to python/test.py , fixed allocation updates for children widgets near the start of the ruler during zoom changes, added Meson build, added the Meson test target that runs the Rust tests.

• August 12-Present: I am currently battling through adding my ruler to the Pitivi GTK4 port branch.

Special Thanks

I would like to send a massive thank you to my mentors, Yatin and Alex Băluț. I was going pretty significantly off track a few times throughout the project and I got nudged in the right direction at some critical moments.

I would also like to thank the GNOME travel committee. Getting to attend GUADEC was a really incredible experience. Sergey Bugaev took a lot of time to sit and work through some of my bugs with me and help provide some guidance. As a long time GNOME daily user, getting to spend time and meet maintainers and Federico was a really exciting opportunity.

GSoC has been a great experience, and I am very grateful for the opportunity to work on this project. I am looking forward to continuing to contribute to the GNOME ecosystem.

One of the larger bits of work I’ve been doing crosses many core projects. I’m motivated to switch to GNOME OS across multiple form factors, but to do that, homed and related tooling need quite a few functional gaps fixed.

TL;DR

• github.com/chergert/linux
• github.com/chergert/cryptsetup
• github.com/chergert/qemu
• github.com/chergert/systemd
• github.com/chergert/edk2

I really wanted a rather simple storage stack. I try to run XFS or ext4 in most places because they continue to serve me well. I also want to run GNOME OS on phones, where we’ll need dm-inlinecrypt for better performance and to avoid loading raw storage encryption
keys into system memory.

Where I prefer something like thin provisioning is a multi-user setup, where I want encryption, integrity, layering, and reliable accounting without dedicating a fixed partition to every user.

Getting all of those properties at once required work from the filesystem down through device-mapper, the block layer, UFS, QEMU, and cryptsetup.

Keeping the storage key out of memory

Traditional full-disk encryption requires the raw volume key to enter kernel memory. That key can unlock the entire device, so extracting it from a running system is particularly valuable to an attacker.

Hardware-wrapped keys change this arrangement. The long-term key is stored as an opaque, device-bound blob. During activation, it is converted into a boot-scoped ephemeral blob and handed to the storage hardware. The hardware derives and programs the AES-XTS key without disclosing it to software.

There is still a separate 32-byte software secret for integrity and other cryptographic operations which cannot be offloaded. Knowing that secret does not reveal the inline-encryption key.

This reduces the opportunity to extract a reusable storage key, but it is not magic. It does not protect plaintext already present in memory, nor does it defeat an attacker who fully controls the running system.

The practical problem with hardware-wrapped keys is that they are difficult to develop and test without the relevant hardware. Even when hardware is available, failures across the complete stack can be difficult to reproduce and inspect.

So I started building the hardware I needed in QEMU.

A virtual UFS inline-crypto engine

The QEMU work adds an optional UFSHCI 4.1 inline-crypto profile. It supports AES-256-XTS, 512- and 4096-byte data units, 32 keyslots, 64-bit data-unit numbers, and both legacy and MCQ request formats.

It models more than just the encryption operation. Keyslots are programmed in stages before being activated, can be evicted, and are zeroized during reset. Requests take their own snapshots of key state so that concurrent eviction or reprogramming has deterministic behavior.
Crypto failures are reported as storage errors rather than returning corrupted data.

There is also a test-only wrapped-key mailbox. It can import or generate a key, prepare a boot-scoped version, derive the associated software secret, program a keyslot, and evict it. The long-term and ephemeral representations use authenticated envelopes so tests can also exercise damaged or substituted blobs.

This mailbox models the API and lifecycle that the guest needs, but it is not a trusted execution environment. QEMU necessarily has access to its root secret.

Following an encrypted write

With the hardware model available, a write can be followed through the entire Linux stack.

dm-inlinecrypt attaches an encryption context to the I/O, including the key and data-unit number. The block inline-crypto layer programs a UFS keyslot, then UFS submits the request to QEMU. Only encrypted bytes reach the backing image. Reads take the reverse path.

This makes dm-inlinecrypt a useful full-device target. Device-mapper describes which blocks should be encrypted, while the actual transform stays in inline-encryption hardware.

The target distinguishes raw keys from hardware-wrapped keys. A long-term wrapped blob is prepared into a fresh ephemeral blob during activation. Only the ephemeral form is placed in an active device-mapper table.

Key replacement also makes secure suspend useful. Userspace can suspend the device and wipe the active key. Resume is refused until a replacement has been installed, at which point a new ephemeral key is prepared and programmed.

Integrity without losing the hierarchy

Encryption by itself does not prevent undetected modification, so the protected configuration places exported dm-integrity above dm-inlinecrypt .

That ordering means integrity authenticates the plaintext seen by the filesystem. Inline encryption protects the filesystem data as well as the integrity tags, superblock, and journal when they reach physical storage.

The HMAC-SHA256 integrity key is derived from the hardware-provided software secret using HKDF-SHA256. The binary LUKS UUID is used as the salt, along with a fixed domain-separation string. This keeps integrity separate from the hardware-only inline-encryption key.

I’ve added a fixed profile at 4096-byte integrity blocks, 32-byte HMAC tags, colocated metadata, and a 32 MiB journal. This is fairly intuition based so it needs more testing.

Suspend and resume follow the layering. Suspend wipes integrity first then inline encryption. Restoration is reversed. This is really hard to test with real hardware, so Qemu again really comes in handy.

Provisioning blocks before publishing them

Thin provisioning adds another problem. A filesystem may publish a logical allocation before the thin pool has assigned physical storage. Failure from lack of capacity is then deferred until too late such as when writing data, an integrity tag, or the integrity journal. All of those can be catastrophic.

I added REQ_OP_PROVISION based on earlier ideas on LKML to make persistent allocation a block-layer op. It is different from a write and is effectively the opposite of discard: it asks the storage stack to ensure that a range is physically backed.

Provisioning is carried through the block core, loop devices, device-mapper, thin volumes, dm-integrity , and ext4. Thin volumes allocate, zero, and commit their mappings. Integrity provisions every corresponding data, metadata, and journal region. Ext4 provisions new data and metadata extents before exposing mappings.

The initial ext4 support is conservative. The provision mount option implies nodelalloc , requires 4 KiB extents without bigalloc , rejects unsupported stacks, and disables online resize.

Turning it into a LUKS2 workflow

The cryptsetup work ties these pieces together.

A platform provisioner can generate or import a wrapped key, derive the optional software secret, format a LUKS2 device for hardware-wrapped encryption, and add ordinary LUKS2 keyslots using the opaque blob as the volume key.

Hardware-wrapped segments have an explicit key_type and mandatory requirements. The integrity configuration is also fixed and marked as dependent on hardware-wrapped-key integrity support. That should make older implementations reject the device.

During activation, cryptsetup retrieves the long-term blob, prepares an ephemeral one, creates dm-inlinecrypt , derives the integrity key, and finally creates dm-integrity above it.

For now, this interface is library-only which is how I’m using it from homed.

Testing all of this in a custom GNOME OS build resulted in me finding some issues in tianocore as well (edk2) which I’ve fixed in my tree to allow booting off PCI-UFS over SCSI.

A laboratory for the whole stack

The important result is that this can now be tested without specialized storage hardware.

We can run AES-XTS known-answer tests and independently inspect ciphertext in QEMU’s backing image. We can test both data-unit sizes, legacy and MCQ queues, fragmented requests, concurrency, reset, cancellation, rekeying, damaged envelopes, and storage errors.

We can also exercise thin-volume provisioning through integrity and inline encryption, reject malformed or downgraded LUKS2 metadata, and verify secure suspend, resume, and key replacement.

Each layer has tests which I tried to keep working and improve along the way.

There is plenty left to do. Namely, I’m not really interested in doing LKML type stuff while unemployed living abroad. So if this is something other people want, they’ll need to encourage their respective teams to pick up the work.

Either way, I now have something useful which is a virtual test lab for a security feature which requires each of these layers to work together.

Earlier this year as I drift abroad in France, I made a new abstraction over Avahi and systemd-resolved. It is called librebonjour and I wrote about it here .

It’s nice in that I no longer need to build Avahi to get GObject bindings to essentially call a D-Bus interface. It’s also nice to not have to care as an application developer if the system is configured with Avahi or systemd-resolved. Though, the systemd-resolved abstraction was lacking a bit compared to Avahi due to missing features.

When you are browsing for services using Avahi, you can be notified automatically of changes. This doesn’t quite work the same in systemd-resolved. Librebonjour had to set a timer and poll occasionally for updates and compare old-to-new sets to notify the application. Not very ideal.

When looking at a recent systemd checkout, I noticed that it already had support for the notification over its varlink interface. A handfull of commits later to hoist a few things and handle client disconnections/isolation properly and I can have the feature for librebonjour too.

One more dependency I can cut out of my system (there will be many more coming, I assure you, as GNOME is heavy with cruft).

I’ve been working on a bunch of things across the Linux puzzle for a product I want to build. Here is an overview of a few of those things.

LibMKS at 120hz

I wanted to get my virtual machines to 120hz so that I can start testing product features inside of VMs. In fact, I actually like doing development with virtual machines over say, trying to shove all your development tooling in a sysext which, at least to me, feels like square-peg/round-hole territory.

To get this working, a few things needed improvements.

Qemu

Qemu has a dbus display backend where it can send you DMABUF FD. But it doesn’t really handle any sort of sync and that becomes a problem as you crank up the frame rate. Additionally, it just defaulted to 75hz with no mechanism to override it.

So I have some patches which provide a new D-Bus interface which can be implemented by LibMKS. It provides something more like a Vulkan swap-chain as well as API to set the refresh rate. While this isn’t a mapping 1:1 of what a wayland protocol might do for frame rate, it does match more what the emulated graphics device expects, so it is probably fine for now and clearly an huge improvement.

A big change in the new API is that we will register all the DMABUF up front, and then tell the client just to switch to another DMABUF along with damage rectangles. Of course, I also had to make Qemu start collecting damage rectangles correctly.

• DMABUF3 Listener API for D-Bus
• Allow Clients to set Frame Rate

Linux

With those changes in place, I kept seeing damage being full-frame. The next part of the stack that can break is thus the Linux kernel virtio graphics driver. Damage rectangles come in as properties on the drm plane being submitted. So it turns out that in two places some short circuiting was preventing that from working right.

After fixing all that (and the corresponding LibMKS side) I have decent graphics performance in a VM.

Since I continue to be floating precariously abroad, this is my notice of such patches. If you are interested in seeing these upstream and work in either of those communities, feel free to crib them, improve them, and submit them upstream. I’m happy locally patching my software given the copious amount of free time I have so there is little incentive for me to collaborate with corporations.

• Virtio fix 1
• Virtio Fix 2

Combined with the LibMKS merge request !53 I can have both minimal damage rectangles all the way to host GPU scanout as well as drag windows around in the guest quite fast.

Injection vulnerabilities, like cross-site scripting (XSS) or command injection, occur when we fail to properly encode untrusted output when inserting it into a trusted context. Before injecting uncontrolled or untrusted data, it’s essential to encode, escape, or quote the data to prevent it from breaking out of its intended context.

Some security folks previously used to like to talk about “input sanitization.” In practice, input sanitization is hopeless. Instead, nowadays we do the opposite and think about “output encoding.” When you inject untrusted data into a new context, assume the data is always malicious, and encode, escape, or quote it to make it safe for use in that context. Let’s look at some examples.

Pango Markup Injection

Here’s a low-stakes example of Pango markup injection:

markup = g_strdup_printf ("<b>%s</b>,
                          my_user_provided_data);
gtk_label_set_markup (GTK_LABEL (label), markup);

The untrusted data is not escaped and may decide to inject its own Pango markup, or break out of any markup that you used yourself. For example, if the data is </b><span foreground="blue" size="x-large">Hello world!</span><b> then it can decide to be blue and extra large instead of the intended bold. That’s not especially serious and probably not likely to be a security issue, but surely it’s an unintended bug. If you’re injecting an uncontrolled string into a Pango markup context, like a GtkLabel, then use g_markup_escape_text() first. (Pango markup can do other interesting things like hide characters or capitalize them. I’m not sufficiently creative to claim that’s definitely a security problem, but perhaps attackers will be more clever than me.)

A real-world example: in this GNOME Shell issue report , the title of a desktop notification is able to use Pango markup to manipulate its own formatting. (At least, probably , because the issue report is unconfirmed. Looks plausible, though!)

Unix Shell Command Injection

Another good example is the Evince command injection vulnerability from a few months ago , where a malicious filesystem path is able to trick Evince/Atril/Xreader into executing arbitrary code. Evince expects the path of a file to open to be something like /home/foo/hello.pdf , but a malicious PDF instead provides the evil input --gtk-module=/home/foo/evil.so /home/foo/hello.pdf . If not quoted properly, we have a command injection vulnerability where --gtk-module is interpreted as a command line flag rather than as a path:

Incorrect: /usr/bin/evince --named-dest= --gtk-module=/home/foo/evil.so /home/foo/hello.pdf

Correct: /usr/bin/evince --named-dest=' --gtk-module=/home/foo/evil.so /home/foo/hello.pdf'

If you’re constructing a Unix command line, as in the Evince example above, then use g_shell_quote() . Failure to do so is ruinous. (But beware: this isn’t necessarily safe if you’re using an actual Unix shell .)

XSS for Desktop App Developers

With that primer out of the way, let’s consider what happens when you inject untrusted content into HTML (or CSS, or JavaScript).

I used to think XSS matters only for websites, and is surely not something that desktop app developers need to know about, right? Wrong, as I discovered five years ago when, to my surprise, Prakash (@1lastBr3ath) reported that websites could inject scripts into Epiphany’s new tab page (about:overview) via malicious page titles . This on its own is not especially serious, but it’s surely not supposed to be possible.

If your desktop app uses WebKitGTK or another web engine, you probably do need to think carefully about XSS. For example, before injecting untrusted data into HTML, we need to HTML-encode it, which Epiphany didn’t do anywhere. In the simplest case, that looks like this:

char *
ephy_encode_for_html_entity (const char *input)
{
  GString *str = g_string_new (input);

  g_string_replace (str, "&", "&", 0);
  g_string_replace (str, "<", "&lt;", 0);
  g_string_replace (str, ">", "&gt;", 0);
  g_string_replace (str, "\"", "&quot;", 0);
  g_string_replace (str, "'", "&#x27;", 0);
  g_string_replace (str, "/", "&#x2F;", 0);

  return g_string_free_and_steal (str);
}

Simply replace the few dangerous characters with HTML entities, and you’re good to go. That doesn’t work for HTML attributes, though, where the rules are slightly different. And it definitely doesn’t work for CSS or JavaScript. Carefully review the OWASP Cross Site Scripting Preventing Cheat Sheet to understand what you can and cannot do.

Recent XSS Bugs in Epiphany

Anyway, back to the old about:overview bug report. Turns out, Epiphany had many similar vulnerabilities. I attempted to fix them all , but in fact, I had missed a spot. In this old commit , I recognized that a URL is untrusted data that must be encoded before I inject the URL into the error message. But I treated the error message of the GError returned by WebKit as if it’s trusted and does not need to be encoded. In fact, the error message itself may contain a URL! Oops. Fernando Munoz recently noticed and reported several example URLs that could inject content into Epiphany error pages. I’m unable to share my favorite example URL here on WordPress, because WordPress is sanitizing it (yes, that is indeed ironic, considering my above recommendation to not do that). But the result of the injection looks like this:

So an evil URL can mess up the Epiphany network error page. That’s not particularly serious, but Fernando found a second injection that is much worse , an XSS vulnerability in Epiphany’s autofill implementation. Here, selector is an untrusted DOM element ID provided by the web page itself. Notice that no output encoding is performed before the untrusted value is injected into the JavaScript command:

  page_id = webkit_web_view_get_page_id (WEBKIT_WEB_VIEW (view));
  world_name = ephy_embed_shell_get_guid (ephy_embed_shell_get_default ());
  script = g_strdup_printf ("EphyAutofill.fill(%lu, '%s', %i);",
                            page_id,
                            selector,
                            fill_choice);

  webkit_web_view_evaluate_javascript (WEBKIT_WEB_VIEW (view),
                                       script,
                                       -1,
                                       world_name,
                                       NULL,
                                       view->cancellable,
                                       autofill_cb,
                                       NULL);

Because the untrusted data here is already used as a quoted data value, one of very few cases where it is safe to inject untrusted data into JavaScript , this would actually have been safe if only Epiphany had JavaScript-encoded the value first, following the OWASP rules for JavaScript encoding : “Encode all characters using the Unicode \uXXXX encoding format, where XXXX represents the hexadecimal Unicode code point. For example, A becomes \u0041 . All alphanumeric characters (letters A to Z, a to z, and digits 0 to 9) remain unencoded.” But Epiphany did not do so. (I got confused by the OWASP rules and didn’t realize how easy it was to make this safe, so I fixed it in a more complicated way instead, by removing the need for injecting the form ID .)

So how bad is this mistake? In Fernando’s example, the ID of the evil form element is "a'); alert('XSS in private world'); var _=('" , allowing the malicious website to run any script it wants. That might not seem so serious, because websites don’t need to exploit any vulnerabilities to execute JavaScript… right?

Script Worlds

Websites are only supposed to be able to execute JavaScript in the default script world. Think of a script world as basically just a big namespace for all of your JavaScript: the default world is what the website itself uses, but desktop applications can create their own private script worlds in order to run their own scripts. In a private script world, you can manipulate the page’s DOM as usual, but you have a separate environment for executing JavaScript code, so you don’t have to worry about name clashes or scripts conflicting with each other. Also, website scripts cannot access your scripts.

In practice, web browsers inject their own scripts into every web page in order to implement various browser features. Epiphany uses a script to find the best web app icon for a web page, for example. These scripts use a private script world that websites should never themselves have access to. But in this XSS attack on Epiphany’s form autofill implementation, the malicious website has managed to execute its script in the private script world. Now it can access whatever internal web browser features are available in that script world.

Unfortunately, there’s one more relevant Epiphany feature implemented using scripts: the password manager. Epiphany’s password manager is necessarily exposed to its private script world because Epiphany needs to execute JavaScript code in the web page in order to autofill passwords. Although there were no relevant bugs in Epiphany’s password autofill code (which is totally unrelated to its vulnerable generic form autofill feature), this did not matter: if an XSS bug in any Epiphany feature can be abused to execute code in Epiphany’s private script world, that code can access the password manager and exfiltrate all the user’s saved Epiphany passwords for every website. (At least, probably , because I have not set up an attack website to test this. But I don’t see why it wouldn’t work!) So that’s pretty serious.

Conclusion

I requested a CVE for the autofill vulnerability earlier today, but nowadays CVE requests usually take a couple of weeks, so I don’t have one yet. It is fixed in Epiphany 50.6 and 49.9. If you don’t have those versions yet, don’t panic. To be exploited, you have to manually trigger form autofill by right clicking on a form and then selecting either “Autofill Personal Fields” or “Fill This Field,” so that makes it much less scary. Even more fortunately, users probably won’t ever do that, because selecting either option always causes Epiphany to reject all further mouse input, becoming unusable . Nobody has reported this bug before, so it seems safe to conclude zero people are using Epiphany’s form autofill feature!

It’s already a month since we were in Spain for GUADEC and I still haven’t gotten around to writing something, so before I completely forget here are a few quick impressions and photos!

Local-First

Similar to last year, my main focus was on local-first, since that’s what I’ve mostly been working on recently. Julian and I gave a talk about Reflection and the p2panda-gobject bindings , and more generally plans for making local-first sync part of the GNOME developer platform.

Julian showing off p2panda-gobject during the BoF on Sunday

We also had a local-first BoF to discuss system integration on Sunday, and a p2panda-goject workshop on Monday where we prototyped the Migrations app Jakub designed. Both were really well-attended, and it was super cool to see people starting to prototype their own little experiments that sync, including a collaborative Snake game, and a collaborative drawing app.

Blackboard at the local-first BoF with some notes on the Contacts and Sync portals

Our current thinking around system integration is that we wan to have two separate portals: one for Contacts, which would just manage P2P identities (so apps don’t have to each have their own identity system and contacts management), and a second one that actually syncs data on behalf of apps using a system API. For the former there is already a relatively detailed plan (see the talk linked above), and this will be prototyped as part of a p2panda NLnet grant.

This entire area is of course still experimental so all plans are subject to change, but it’s exciting to see things get more and more concrete over the past year.

Talks

Some of my favorite talks:

• Session Save/Restore by Adrian Vovk: Really cool to see the progress in this area, but also incredible how many moving parts are involved in getting this to just work . Kudos to Adrian and everyone else who’s helping to push this forward!
• Foundation Annual General Meeting by Allan Day: Really clear and concise overview of where the Foundation is at, what changes have been made to make it more financially sustainable, and what challenges still persist. The fellowship in particular is a very nice, tangible new thing and at least to me a sign that some things have changed for the better. I found this framing particularly interesting: the Foundation is a corporation, and the AGM is a meeting for “shareholders”, i.e. people who invest their time (rather than their money) in the Foundation, to assess whether the investment is well managed.
• The Future of Boxes by Felipe Borges: I’m very happy to see Boxes revived and modernized, it’s a secret gem of our app ecosystem. Kudos to Felipe for his work on this!
• A Brief History of Graphs by Sjoerd Stendahl: Very nice talk, and a great success story for how programs focused on the third-party app ecosystem like Circle can help to bring people into the community.
• GNOME OS Mobile lightning talk by Aberrahim Kitouni: Between this and the Mobile BoF it was very nice to see more people across the community pushing towards making mobile an official part of the GNOME release process.

Great to see new generations making old wisdoms their own :)

City and Venue

The logistics of constantly going back and forth between the Rialta dorms, the University building, and the city center made the social side of the conference more difficult than in other years, especially because public transit stopped relatively early in the evening. As usual, the smart move would probably have been to stay in the city center, but that only goes so far if everyone else is staying at the official accommodation, which is far away. More generally, the A Coruña city center was cute, but other parts of the city felt really car-centric and not very fun to be in.

The view from the hill was pretty cool though :)

Meta

I found it a bit sad that once again, we didn’t manage to use the fact that so many people were together in person to make progress on resolving the conflicts of the past few years. I didn’t see it as my responsibility to take care of this, and I assume everyone else felt the same way. But here’s an idea for next year: An official “Conflict Resolution BoF”, chaired by a trained mediator.

If there’s any interest I’d be happy to co-organize something like this, but I wouldn’t want to be solely responsible for it.

More Photos

Local-first workshop on Monday Philipp at the Design BoF The Mobile BoF People hacking at the university Traditional GUADEC dinner

See you next year!

Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.

I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).

I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.

There is No Drama Here

First off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.

Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.

Why Boxes Shouldn’t Be “Core” (and Why Versioning with the OS is Outdated)

The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.

Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.

Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.

Flathub-First: Moving Fast and Ending Distribution Bottlenecks

As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.

By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.

Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub . If you are filing bug reports or seeking support, the Flathub build will be the baseline.

Branding and Infrastructure Changes

To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”,  and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.

What’s Next?

This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle .

To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.

If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.

For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.