Linux desktop Gnome: Between financial difficulties and technical progress

Contents

The Gnome project is in a tricky situation: While the widely used Linux desktop is technically on a secure footing, things are looking less good financially. In recent years, donations have decreased while costs have remained the same. Despite the tight financial situation, the Gnome project organized a hybrid conference. Participants and interested parties from overseas, Europe and other countries met at the end of July for the annual Gnome conference GUADEC. It took place in Lombardy at the University of Brescia.

The talks presented the progress made in recent months in areas such as the GTK toolkit, the Gnome shell and the XDG desktop portals, which are important for Flatpak. Topics such as accessibility and security as well as project development, for example to prevent maintainer burn-out, were also discussed. At the annual general meeting of the Gnome Foundation, which took place during GUADEC, it became clear that a conflict from the previous year continues to occupy Gnome members.

Progress on accessibility

Red Hat employee Lukáš Tyrychtr presented the latest progress in the accessibility of Wayland and Gnome, especially for the blind. In the past, there has been criticism in this area. He began by explaining to those present how a screen reader works and why this poses special challenges. This is because a screen reader is not limited to reading text aloud, but must also be able to recognize any keyboard events and even intercept some of them so that they do not end up in the compositor, such as Mutter from Gnome shell, or in the application currently being used. For example, blind people often use a function to cancel the text being read out.

Changes to the AT-SPI2 accessibility service and the introduction of GTK 4 with its accessibility bus meant that GTK 4 apps under Wayland did not work with the Orca screen reader. This problem remained unsolved for several years. Together with other Red Hat employees, Tyrychtr, who is visually impaired himself, developed a new approach in which key events are no longer intercepted in the app, but already in the compositor. As there was previously a lot of traffic on the accessibility bus, an event is now only sent if a screen reader is also listening. In addition, the DBus name is checked against an allowlist so that no arbitrary process can act as a keylogger. The changes are implemented in AT-SPI2 core from version 2.56 as well as in the screen reader Orca 48, Gnome-Shell 48 and KDE's compositor Kwin 6.4.

Independently of this, the visual warnings in the Gnome shell have been adapted so that they are compliant with the European Accessibility Act (EAA). In addition, the accessibility options are now more prominently placed on the login screen.

There were other presentations from Red Hat's accessibility team, such as an accessibility workshop for app and shell developers. As blind people do almost everything with the keyboard, Lukáš Tyrychtr appealed to the attendees that the keyboard user experience must not be allowed to deteriorate. In a panel discussion, Gnome developer Emmanuelle Bassi described accessibility as the twin of usability. Accessibility is important so that everyone really has access to the computer.

Colorful Gnome shell

Not only has accessibility improved in the Gnome shell since version 48, but support for HDR has also been introduced. After years of reworking the source code of the compositor Mutter and other components, HDR can now be used system-wide. If Gnome is running in Wayland mode and an HDR-capable screen is connected, a corresponding switch appears in the settings. This is not the end of the work. Still on the agenda are tone mapping (adjusting HDR content to the range supported by the screen), support for ICC profiles, color management even without HDR, fixing night mode and displaying HDR content in SDR mode.

The Gnome shell team has also upstreamed numerous internally used Wayland protocols. This covers color management, color conversions, better timing when updating screen content, as well as a workaround to avoid memory leaks in Mesa. Final work is currently underway on a session management protocol to restore programs and their windows after a new login. The current draft of this much-requested feature still contains too many bugs. This is also difficult to implement due to the restricted rights of Wayland clients; applications do not have access to the entire screen area. The compositor, on the other hand, may have to wait a long time when starting an application to see whether it will make the old windows available itself, for example because it takes a long time to open a large project or because the user has to authorize the previous session to be restored.

The extensive removal of X11 code from the Gnome shell also means that its nested option, with which a session could be opened in a window, is no longer available. This was mainly of interest to shell developers for testing, a task that is now taken over by the Development Kit, an independent GTK 4 application that runs as a separate process. The small group of shell developers should be pleased that it is now easier to test developments. As the Development Kit uses the same API as the Remote Desktop, the latter should benefit from the fact that more Gnome hackers are now using this API.

More security

Although it is often claimed, Linux systems are not inherently more secure than other operating systems. However, the low distribution on desktop systems makes Linux unattractive for user malware. The Spanish security researcher and free software activist Paula de la Hoz also pointed this out. Basically, almost the same dangers lurk under Linux as elsewhere, such as hidden crypto miners, ransomware, and phishing. Toolkits for malware now also offer payloads for Linux systems. De la Hoz told c't that servers and IoT devices are still the main targets of attacks. However, she warned against underestimating the risk of software from questionable sources or blindly copying and pasting commands from the internet onto your system.

In his presentation, Gnome developer Michael Catanzaro called on people to stop undermining the Flatpak sandbox. This is essential, as it is never possible to write secure code with insecure programming languages such as C. Rust may be more secure by design, but there are risks lurking in the dependencies (supply chain security). “Our Rust applications have far too many dependencies,” warned Catanzaro, referring to several hundred dependencies between individual apps and Rust's cargo repository.

He praised the Flatpak sandbox, however, as it provides a contained environment. While this doesn't exempt developers from updating dependencies or code, and it's not completely secure, he added, to cause damage from within the sandbox, an attacker would need at least two exploits: one to trick the app's code and another to break out of the sandbox.In practice, however, many applications request excessively extensive permissions, such as access to the entire file system, thus invalidating the sandbox.

Catanzaro does not blame the app developers alone but also criticized the lack of or inadequate XDG Desktop Portals. These portals are a collection of interfaces that dynamically grant apps access to resources when users agree to share them, such as a webcam or a specific file. More cooperation is needed in the development of the portals, and a plan is needed to resolve the biggest outstanding issues. There is also a lack of a strategy on how to deal with applications that legitimately cannot run in a sandbox.

Given such requirements, it is hardly surprising that the keynote by Mirko Brombin, developer of the innovative Linux distribution Vanilla OS and the WINE tool Bottles, did not meet with huge enthusiasm. Brombin introduced cpak, a new way for Linux to package command-line tools, services, and applications. cpak is based on standards from the Open Container Initiative (OCI), the container images used for example by Docker. These are combined with a cpak.json file, which defines the required rights and resources, among other things. According to Brombin, cpak was primarily developed for embedded devices and is positioned between Docker and Flatpak or Snap. In contrast to these, cpak does not require any background services, but consists of a single independent binary(cpak), which executes the respective cpak bundle. Many critical questions from the audience related to security aspects. Although cpak provides for a separation between cpak applications and the host system, several attendees complained that this was already insufficient in its structure or that it could be circumvented in other ways.