Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.

AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.

Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).

Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.

PNG images are great!

The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.

But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.

To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.

For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.

JPEG-XL vs PNG in AppStream

Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).

For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.

So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:

PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.

As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.

Interesting JXL encoding findings

As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.

In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).

The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:

My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.

Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).

The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:

For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.

JXL in AppStream

Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.

Upsides of JXL in AppStream right now

If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).

Downsides of switching to JXL too quickly

JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).

This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.

It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.

Media pipeline improvements

Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).

The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.

AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.

As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).

The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).

With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).

I want to see / try this!

Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.

Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.

What’s next?

With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.

For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.

As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.

Dear syslog-ng users,

This is the 141st issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

New performance tuning possibilities in syslog-ng

On April’s fool’s day, I shared that syslog-ng can reach 7 million EPS. This test lab result was in part possible thanks to a few performance enhancements coming to syslog-ng version 4.12. How 7 million EPS is possible? Before diving deeper, let me repeat it: 7 million EPS is just a lab testing result, not (yet) possible in the real world. However, the technologies enabling this are already available on the development branch of syslog-ng, or have been available for ages, just not tested or promoted enough.

https://www.syslog-ng.com/community/b/blog/posts/new-performance-tuning-possibilities-in-syslog-ng

Nightly syslog-ng containers based on Alma Linux

For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available. A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!

https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-containers-based-on-alma-linux

The status of OpenSSL 4.0 support in syslog-ng

OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng

Learning syslog-ng

How can you learn syslog-ng? There are many possibilities, depending on your time and budget. Possibilities range from tutorial series through reading the documentation to instructor-led training. Find out which one is for you!

https://www.syslog-ng.com/community/b/blog/posts/learning-syslog-ng

Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

In 1993, I stood at the top of the World Trade Center feeling like being on top of everything. It was the culmination of my first proper trip west, a stark contrast to a country behind an iron curtain or even a small-town Amherst, New Hampshire, where I had to earn my way into that adventure.

Many people can't wrap their heads around how such enormous buildings could collapse on September 11. What I can't wrap my head around is that they survived the first attack, which happened in February of '93, when I was, entirely oblivious to what had happened on the ground floor a few months earlier, soaking in those panoramic views.

The attack was carried out by a group of radicals led by mastermind Ramzi Yousef. In the underground parking garage of the North Tower, they detonated a yellow Ford van packed with explosives. It's often claimed that the terrorists used Czechoslovak Semtex, but in reality it was a massive, roughly 600-kilogram homemade explosive charge, further reinforced with pressurized hydrogen tanks. Semtex was only a trigger explosive.

The explosion was devastating. The blast tore a 30-meter crater through five floors of underground parking and damaged several support columns, though the main structural frame of the tower held. Though the tower didn't collapse as the terrorists had originally planned, the shockwave destroyed the main electrical wiring and emergency lighting, and smoke rose as high as the 93rd floor. Six people lost their lives and more than a thousand were injured, most from smoke inhalation during the grueling evacuation through dark stairwells. Operations in both towers were completely paralyzed and the complex had to be shut down for nearly a full month. Total damages and subsequent repairs cost roughly half a billion dollars.

Because of the '93 bombing, the Port Authority installed photoluminescent safety markings along the steps, landings, and handrails throughout the towers. When the planes struck eight years later and emergency lights flickered or failed, these glow-in-the-dark strips guided occupants downward. According to National Institute of Standards and Technology, 33% of survivors in the North Tower and 17% in the South Tower directly credited these markings with aiding their escape. The stairs were well-lit by battery-pack emergency lights and photoluminescent guides, and people moved much faster. Survivors who had been in the building during both attacks noted that the 2001 descent took roughly half the time it did in 1993.

I only know about all of this because of the internet — a firehose of news and dangers pouring at me every hour of every day. Could I stand up there today, soaking in those fantastic views, still so oblivious and happy?

Table of Contents

• 1) Introduction
• 2) D-Bus and Polkit Additions
  • 2.1) systemd v260.2 and v261 Reviews
  • 2.2) Polkit Rules File in upower
  • 2.3) New Polkit Action aa-notify.from_file in AppArmor
  • 2.4) New Polkit Actions in fwupd 2.1.4
  • 2.5) Changes in Polkit Rules in gnome-initial-setup
  • 2.6) D-Bus and Varlink Services in wall-broadcaster
  • 2.7) Transactional Update Notifier D-Bus Service
  • 2.8) Plasma Kameleon RGB LED Helper
  • 2.9) Samba Helper in kdenetwork-filesharing
  • 2.10) GNOME Remote Desktop Race Condition in new pcscd API in 51.beta
• 3) Review of File-Based Linux Capabilities
  • 3.1) After-the-Fact Review of Slipped Capabilities
  • 3.2) CAP_NET_RAW for cacti-spine
  • 3.3) CAP_PERFMON for ksystemstats6
• 4) Revisit of Apptainer
• 5) Restriction of Varlink Service Packaging
• 6) pam-ssh-agent Module
• 7) wireguard-tools: Update Logic for resolv.conf
• 8) wicked: Command Injection via DHCP Options (CVE-2026-44932)
• 9) Conclusion

1) Introduction

This edition of the spotlight series covers both spring and summer 2026, since we did not get around to publishing a dedicated spring article due to high workload in our team. Some of the highlights that kept us busy during that time were:

• Incomplete privilege drop in cosmic-greeter when accessing files in user home directories.
• Defense-in-depth issues in a D-Bus helper in plasma-login-manager.
• Disk space exhaustion in the malcontent parental control system.
• Various issues leading to privilege escalation in qSnapper, a GUI frontend for the snapper utility.
• Local Denial-of-Service attack vectors in seunshare, a sandboxing program from SELinux userspace utilities.
• Escalation of Network Manager and UDisks2 Privileges in PortProtonQt, a GUI application for launching Windows games on Linux.
• Full remote system compromise in a network protocol in OpenRGB.
• Authentication bypass in LACT, a GPU manager application for Linux.

Apart from these dedicated publications, we want to shed some light on some less visible efforts in our team during these past months. Topics that we will cover this time are various changes to D-Bus service configuration and Polkit policies which we will cover in section 2). In section 3) we will look into a number of file-based Linux capability assignments in packages. In section 4) we will discuss a revisit of the starter-suid setuid-root binary in the Apptainer container runtime. In section 5) we will point out new whitelisting restrictions in SUSE distributions regarding the packaging of Varlink services. In section 6) we will examine the pam-ssh-agent module which was recently packaged for openSUSE. In section 7) we will discuss concerns about a script in wg-quick for setting up DNS for Wireguard VPN interfaces. Finally, in section 8) we will look at a shell command injection issue we found in the wicked network configuration framework, which can lead to remote root code execution in combination with dracut.

2) D-Bus and Polkit Additions

As usual, many of our reviews were concerned with D-Bus services and Polkit authentication. We look into packages containing D-Bus interfaces and Polkit policies, both when they are first introduced and if they are later modified. In the past months we dealt with a number of reviews of this type, discussed in the following sub-sections.

2.1) systemd v260.2 and v261 Reviews

As we pointed out in previous spotlight editions, systemd is a heavy user of D-Bus and Polkit and also started backporting new features from the mainline development to existing release branches, resulting in an increased review effort on our end.

This time we looked into the follow-up release v260.2, which introduced Polkit actions org.freedesktop.machine1.inspect-machines and org.freedesktop.machine1.inspect-images in the context of systemd-machined. Nothing problematic was found in these two additions.

The new major release of systemd v261 also resulted in a review bug for us. Various Polkit actions were added to our systemd-experimental package, as well as a couple to systemd-machined and systemd-resolved. In this case we also had nothing to complain about and allowed the changes to enter openSUSE Tumbleweed.

2.2) Polkit Rules File in upower

The energy management software upower triggered a review due to a Polkit rules file which appeared in the package. Polkit rules are JavaScript drop-in files which alter the outcome of Polkit authentication requests based on custom logic. In this case a strange rule was added to upower, allowing the root user to perform system power state changes like rebooting or entering suspend. Since the root user is by default allowed to perform any Polkit operation anyway, we asked our upower packager to investigate what the supposed purpose of the rules file might be. He was unable to find out, however, therefore we decided to simply drop this rule file from the package to avoid unnecessary administration efforts. It could be that the rules file is intended to be used on systems where even the root user has limited capabilities.

2.3) New Polkit Action aa-notify.from_file in AppArmor

The AppArmor utility aa-notify, which allows system administrators to easily whitelist AppArmor violations, added an additional Polkit action net.apparmor.pkexec.aa-notify.from_file. This action allows to read in additional AppArmor commands from a file on disk. All the Polkit actions related to aa-notify require auth_admin authentication and are inherently risky, since they provide full system access via various angles. The defense-in-depth and separation of privileges is not ideal here, but we decided to accept the change, since there are no better alternatives available for managing AppArmor profiles.

2.4) New Polkit Actions in fwupd 2.1.4

The firmware update daemon is another heavy user of D-Bus and Polkit. We reviewed it many times in the past already as changes to the API appeared. Security-wise we rarely found tangible issues, but the interface is vast and only parts of it are actually authenticated, while the rest offers access to public information and similar code paths which are assumed to be uncritical.

For the recent update of fwupd to 2.1.4 we reviewed a couple of additional Polkit actions, some of which adding authentication to previously unrestricted D-Bus methods. We couldn’t find any issues in the API changes, and accepted the new version into openSUSE Tumbleweed.

2.5) Changes in Polkit Rules in gnome-initial-setup

gnome-initial-setup is a wizard intended for single-user systems to create a user account with administrator privileges after installation of Gnome-based systems. Its approach is to allow a special gnome-initial-setup user to obtain a range of root-like privileges to perform the necessary initial setup logic.

The security boundary between the gnome-initial-setup user and root is very thin, but the approach is still better than running the setup wizard with full root privileges. A somewhat worrying aspect of the component is that the wizard automatically starts after system boot when there are “no user accounts present” in the system, which is a condition that might be possible to fake or force by way of other security issues in the system.

We have reviewed the package a couple of times in the past. This time a change to the Polkit rules in the package appeared, which led us to looking into the code once again. The change allows gnome-initial-setup to invoke Polkit action org.freedesktop.home1.passwd-home without providing a password, for setting up a portable home directory managed by systemd. This does not change the general security concept of gnome-initial-setup, which is why we accepted the change into openSUSE.

2.6) D-Bus and Varlink Services in wall-broadcaster

A while ago a new D-Bus and Varlink service called wall-broadcaster was added to openSUSE Tumbleweed. This service aims to replace the old-school wall setuid binary, which allows to write terminal messages to all users in the system. Messages processed by this service are also forwarded on D-Bus level e.g. to interested consumers in graphical desktop environments.

We inspected the privileged components and protocols and could not find any security issues, which is why we accepted the new services.

2.7) Transactional Update Notifier D-Bus Service

txnupd is a notifier for SUSE systems based on transactional-update. It sends out a D-Bus signal propagating the results of a transactional update process. The corresponding D-Bus service was recently renamed, which triggered a follow-up review. The privileged daemon which emits the D-Bus signal is only accessible by root and does not cross privilege boundaries, thus this is a rather worry-free case of a D-Bus service.

Still we identified an issue during the review, namely that the same script was used in two different modes, in a privileged and an unprivileged context, mixing two different security domains, which could potentially lead to future issues when developers overlook this detail when making changes. We managed to improve the service in this regard by splitting the script into two different ones for better separation of security concerns.

2.8) Plasma Kameleon RGB LED Helper

A new D-Bus service was added to kdeplasma6-addons which deals with the synchronization of RGB LED devices, like illuminated keyboards, with the color scheme of the KDE Plasma desktop. We looked into the privileged D-Bus helper for this feature and found the interface to be small and offer little attack surface, thus we accepted the new component into openSUSE.

2.9) Samba Helper in kdenetwork-filesharing

A D-Bus service in the kdenetwork-filesharing package which interacts with Samba network shares saw changes in its D-Bus configuration and Polkit policy. The name of the helper binary was changed and additional Polkit actions for starting and stopping the Samba daemon were added. We could not identify newly introduced security issues and thus accepted the changes into openSUSE.

2.10) GNOME Remote Desktop Race Condition in new pcscd API in 51.beta

Our GNOME packagers reached out to us regarding changes they ran into in the GNOME Remote Desktop beta release for version 51. The GNOME Remote Desktop component is constantly growing in complexity, by now amounting to about 75,000 lines of Glib-based C code. This time a new daemon called grd-pcscd was added, which offers an additional D-Bus API to deal with smart cards by interacting with the pcscd smart card management daemon. The approach of the D-Bus interface is a bit unusual:

• there is a new org.gnome.RemoteDesktop.Pcscd.Connect D-Bus method which is accessible to arbitrary users without authorization checks. The method takes a file descriptor as sole argument, which is supposed to refer to a pcscd connection that grd-pcscd should use for further smart card operations.
• the daemon runs a separate D-Bus session on this file descriptor via Glib’s g_dbus_connection_new().
• the session of the process calling Pcscd.Connect is looked up via the caller’s PID. Based on the session ID obtained this way, another D-Bus interface is then made available in the daemon under /org/gnome/RemoteDesktop/Pcscd/<session-id>, offering the org.gnome.RemoteDesktop.Pcscd.Session interface. All methods on this interface are protected by Polkit auth_admin actions and therefore offer no additional attack surface.

We checked possible attack vectors resulting from crafted data sent on the file descriptor passed to the Pcscd.Connect() method. The Glib functions processing D-Bus messages on this file descriptor are pretty robust, however, and valid D-Bus messages will not reach any additional code paths as long as no further configuration takes place via the privileged Pcscd.Session API.

We found the lookup of the caller’s session ID based on its PID problematic, however. This is a race condition that allows the caller to attempt to let the daemon see the session of another user in the system, by cycling PIDs. This allows a local unprivileged attacker to at least block other users’ smart card usage. Even worse, it allows to potentially spoof pcscd replies or intercept sensitive data like smart card PINs provided in other users’ sessions.

We created a private upstream bug describing the problem. Since the issue only made it into the 51.beta release of GNOME, there was no necessity for coordinated disclosure and we also did not assign CVEs. We are happy that we helped to prevent this issue from reaching the final release of GNOME 51.

3) Review of File-Based Linux Capabilities

File-based capabilities work much the same as setuid-root binaries: special extended attributes are set on executable binary programs which tell the Linux kernel to automatically execute the program with additional Linux capabilities in effect. During the past months we looked into quite a number of Linux capability assignment requests, which we will discuss in detail in the following sub-sections.

3.1) After-the-Fact Review of Slipped Capabilities

Special file-based permissions like setuid/setgid bits or Linux capabilities have been managed in SUSE distributions via the permissions package for a long time already. Packaging of such bits is restricted and requires mandatory reviews by our team. Recently it came to our attention that a loophole sneaked into our checkers, resulting in a couple of packages which use file-based capabilities reaching openSUSE Tumbleweed without us having looked into them.

Historically the RPM packaging format did not support embedding of Linux capabilities into package metadata in the first place, thus there was no need to reject them on this level: only a warning was emitted by our rpmlint integration when capabilities appeared. With recent releases of the RPM package manager, this restriction is no longer present. Our RPM checkers recognized the capabilities which lacked a whitelisting but did not trigger fatal build errors. This allowed the affected packages to reach openSUSE Tumbleweed without going through the intended security review process.

Once we noticed this, we quickly adjusted our checkers to prevent such cases in the future and looked into the packages that slipped into production without a review. The following paragraphs discuss the reviews we performed in this context.

CAP_NET_ADMIN and CAP_NET_RAW for ttl

The ttl package assigned cap_net_admin and cap_net_raw to the ttl binary for tracing network routes. During our review we identified that actually only cap_net_raw was necessary and we could successfully drop the broader cap_net_admin privilege. Otherwise we deemed the code paths for cap_net_raw safe and accepted the capability formally into our whitelistings.

CAP_SYS_RESOURCE for noisetorch

The noisetorch package provides a virtual microphone in Pulseaudio and assigns cap_sys_resource to the noisetorch binary for bypassing realtime scheduling limits. We looked into this a longer time ago already and rejected the capability, because the use case for the additional privilege was not very convincing.

There exists a corner case in Pulseaudio that can cause it to exceed realtime scheduling limits when loading plugins. The noisetorch plugin seems to trigger this corner case in some situations, which is why it temporarily bypasses scheduling limits by modifying the Pulseaudio process based on the cap_sys_resource capability. Furthermore the noisetorch program attempts to modify its own executable by adding the cap_sys_resource capability via a privilege escalation dialog, should it be missing. This mixture of a capability being used to work around what looks like a bug in Pulseaudio and the fact that the program tries to apply its own policy regarding file-based capabilities is what led us to reject this request previously.

After looking into the matter again we decided to accept the capability this time, provided that the package would be patched to disable the self-modification logic, which we deem unsuitable, since it bypasses our permissions profiles. A corresponding patch was implemented and we proceeded with a formal whitelisting of cap_sys_resource for noisetorch.

CAP_NET_ADMIN for cloud-hypervisor

The cloud-hypervisor package is a virtual machine manager and uses cap_net_admin to configure privileged virtual machine networking. During our review we focused on the code paths that deal with cap_net_admin only, because the project consists of 150,000 lines of Rust code, not counting vendored code. We could not find issues in the cap_net_admin usage and therefore formally accepted this use of capabilities as well.

3.2) CAP_NET_RAW for cacti-spine

Cacti is a system and network monitoring tool, and cacti-spine is a C program used as a drop-in replacement for a PHP-based program in Cacti for polling network services. In this context it asks for cap_net_raw privileges to send out ICMP messages. According to upstream documentation the utility is even intended to be used with full setuid-root privileges: this is not a good idea at all, however, since it is not very careful in parsing and processing command line arguments, among other issues. Assigning cap_net_raw is acceptable, though; we could not find any tangible security issues in this configuration.

3.3) CAP_PERFMON for ksystemstats6

The ksystemstats6 package contains the helper program ksystemstats_intel_helper, for which an openSUSE user requested the cap_perfmon capability. The helper utility needs it to calculate the GPU usage in the system. The rarely seen cap_perfmon allows programs to open otherwise privileged performance event counters. The utility is only 200 lines long; for prudence we requested to apply a patch with a hardening to the program which also made it into the upstream repository by now. After this patch arrived in the openSUSE package we granted the capability in openSUSE Tumbleweed.

4) Revisit of Apptainer

Apptainer is a container runtime (formerly called Singularity) which we already reviewed a couple of times in the past, since it contains a setuid-root binary starter-suid. The early reviews around the year 2019 uncovered a number of security issues in this area. A few years ago we dropped the starter-suid binary from our packaging, because upstream implemented new features which we believed made the extra privileges unnecessary.

A SUSE customer recently ran into issues because of a specific Apptainer use case they had, which still relied on the starter-suid program being installed. For this reason we revisited the Apptainer code base to check the current situation of this sensitive helper binary.

The logic executed by the starter-suid program is still highly complex and its execution paths hard to follow. We could not identify any new issues in the code this time, however, which is why we accepted the setuid-root binary back into SUSE distributions. Since we are still unhappy about the overall complexity of the program we are relying on an opt-in model: users need to become a member of the apptainer group to use it, which limits the attack surface.

5) Restriction of Varlink Service Packaging

With Varlink services becoming more widespread, we decided to introduce whitelisting restrictions for packages wanting to submit them to SUSE distributions. Contrary to D-Bus services, there is no central instance managing the Inter-Process-Communication of Varlink, and there are also no standard configuration files that every Varlink service ships. Varlink applications simply define a path where the Varlink UNIX domain socket will be placed and that is about all there is to it.

A kind of standard pattern in systemd socket units for Varlink daemons is that they contain a FileDescriptorName=varlink directive. This is what we have decided to rely on to restrict the packaging of Varlink services. We looked into all existing socket units of this kind in openSUSE and did not find any tangible security issues in them. From now on, when packages contain new Varlink socket units, a mandatory review by our team will be required before they can be added to SUSE distributions.

6) pam-ssh-agent Module

Recently we received a request to allow the pam-ssh-agent module into openSUSE. The module performs PAM authentication based on SSH public keys: a random payload is requested to be signed by an SSH private key; the signature is then verified by the PAM module based on a list of configured trusted public keys.

The PAM module is of moderate size, consisting of about 1,500 lines of Rust (not counting vendored sources). The code and documentation generally show security-consciousness, which is a good thing. We identified a few aspects in the PAM module that could be problematic, mostly as a result of bad configuration:

• the PAM module can be configured to look for acceptable public keys in the to-be-authenticated user’s home directory, which allows to basically bypass local sudo authentication, for example. This is also documented in the upstream README.
• an authorized_keys_command can be configured to call a program which produces authorized public keys. If an untrusted program is configured here then this would result in issues in local authentication scenarios.
• the authorized_keys_command is by default run with the privileges of the to-be-authenticated user; an option allows to change this to be run as root, however, which could easily lead to security issues further down the chain.
• a special authentication path in the PAM module inspects the SSH_AUTH_INFO_0 environment variable, if the current PAM stack file is named “ssh”. Public keys found in this environment variable are implicitly trusted by the PAM module, assuming that sshd already took care of the authentication, verifying the public key(s). This is a bit of a heuristic, which could break in some (highly) unexpected scenarios.

In spite of these uncertainties we are generally content with the quality and documentation of the PAM module and accepted it into openSUSE. It is up to system administrators to configure this PAM module carefully to avoid any security issues.

7) wireguard-tools: Update Logic for resolv.conf

An openSUSE user was concerned about the security of wg-quick, a script which is part of the wireguard-tools package, a collection of utilities for the Wireguard VPN solution. wg-quick is supposed to bring up a WireGuard VPN interface in a worry-free manner.

A Linux-specific “DNS hatchet” is applied during build time of wireguard-tools on openSUSE. Hatchets are overrides of the script logic in wg-quick, a rather makeshift approach at customizing the logic towards specific operating systems.

The openSUSE user approached us because he was worried about the mount logic that this “DNS hatchet” implements for /etc/resolv.conf. During the review we found the approach of the script a bit unexpected but not unsafe at all. The script is concerned with the safe update of name server configuration in /etc/resolv.conf, a resource which is difficult to manage in Linux, because there is no central mechanism for maintaining the consistency of the file when multiple programs want to modify it. VPN clients are a typical use case when this results in problems: the VPN client adds VPN-specific name servers, thereby overriding previously existing name servers from static configuration or provided by DHCP servers. When the configuration is blindly overwritten this results in the loss of the original DNS configuration; once the VPN connection is terminated, DNS is no longer working.

To prevent this situation, the “DNS hatchet” performs a bind-mount of the new configuration file over the original one in /etc/resolv.conf. The resulting file will be read-only, preventing further modifications of the configuration until the VPN connection is terminated. When the VPN is shutdown, the bind-mounted file will be unmounted again and the original name server configuration reinstated.

We have no security concerns about this logic, and explained the situation to the creator of the review bug accordingly.

8) wicked: Command Injection via DHCP Options (CVE-2026-44932)

wicked is the network configuration framework used in SUSE Linux Enterprise 15-SP7 and earlier. Its DHCP clients dump the settings of an acquired lease into files below /run/wicked/leaseinfo.*, which contain lines of the form KEY='value'.

We found that the values of a number of DHCP options, among them POSIXTZSTRING, were written out verbatim, enclosed in single quotes but without any validation or escaping:

fprintf(out, "%s='%s'\n", __ni_keyword_format
        (&key, prefix, name, index),
        val_to_print);

A DHCP server can thus place a single quote in an option value and break out of the quoting. A dnsmasq configured with

dhcp-option=100,'; chmod a+w /etc/shadow; /bin/true '

results in the following line in the leaseinfo file:

POSIXTZSTRING='Hello_World'; chmod a+w /etc/shadow; /bin/true ''

The interesting part about this issue is who actually executes this. wicked itself never sources these files; it only passes them on to netconfig modify, which rejects any line whose value is not strictly single-quoted. There was, however, also no documentation stating how the leaseinfo files were intended to be consumed. Since their syntax looks exactly like shell variable assignments, third party code simply started to source them from shell scripts. We found several examples of this in our distributions and in the wild, among them dracut’s network-legacy module, the SUSE cloud-netconfig scripts and SystemImager.

The dracut case is the nastiest one: ifup.sh sources the leaseinfo file as root in the initrd, turning the issue into unauthenticated code execution as root for an attacker on the local or adjacent network. The network-legacy module is not active by default, but it is pulled in by plausible setups such as remote unlocking via dracut-sshd, or systems that need NFS, iSCSI or NBD during early boot. We confirmed this end-to-end on SLE-15-SP7.

We rated the issue CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8 High) and CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H (5.8 Medium). This is a nice example of the improved precision of CVSS v4.0, which is able to express that the impact materializes in a subsequent system rather than in wicked itself.

The issue was handled under embargo and fixed by wicked upstream: single quotes are now rejected in all string options and discarded values are logged as warnings; should a suspect string still pass the input check, single quotes are additionally escaped in the leaseinfo output. The fix was released for all maintained SLE and openSUSE codestreams, including a rebuild of the initrd, which carries its own copy of wicked.

9) Conclusion

As can be seen from this edition of the spotlight series, maintaining the security of a complete Linux distribution is no small feat both in terms of volume and range of topics that have to be covered by our team. We continue to contribute to the overall security of the Linux ecosystem by reviewing code, publishing security reports and contributing back upstream to be able to provide our users and customers with a robust and secure Linux distribution that you can trust.

There is a question that comes up often in openSUSE forum threads or a Reddit comment section and that is what version of X does one actually get on Leap versus Tumbleweed?

Until recently the honest answer was very often “go look it up yourself, package by package” unless someone actually had the answer.

Now there is a better one.

The openSUSE version diff tool!!! Yes github.com/openSUSE/osdiff tooling generates a complete, machine-built comparison of source package versions across Tumbleweed and the current Leap releases.

The idea of listing source package versions in a consumable format grew out of a discussion community member Axel Braun raised at a weekly Release Engineering meeting. The site republishes itself automatically. No guessing, no anecdotes, no six-month-old blog post. Just the numbers.

The tool pulls the archive indexes straight from download.opensuse.org; this is for open-source software (oss) and non-oss, x86_64 and noarch and it’s done for Tumbleweed, Leap 16.1, and Leap 16.0; then it compares the upstream version of every source package it finds. The result is a single sortable, filterable table with a timestamp on it.

The scale is worth pausing on. A recent run covers 17,532 source packages: 17,143 in Tumbleweed, 10,574 in Leap 16.1, 10,551 in Leap 16.0, with 10,264 present in both Tumbleweed and Leap 16.1. Every package lands in one of five status buckets:

The page carries maintainer information and it is careful about what it claims: only the upstream version is compared, not the RPM release. That distinction matters, and the tool states it up front rather than quietly blurring it.

Open data changes the conversation. The single most valuable thing here isn’t the HTML page. It’s the downloads sitting at the bottom of it: diff.json, diff.json.gz, and diff.csv.

This open data turns a nice webpage into infrastructure. Anyone can pull the JSON, and the shape of the data is stable enough to build on. Which is where use cases start multiplying.

• Prospective users deciding between Leap and Tumbleweed. Someone who needs a specific toolchain version for work can confirm it in ten seconds rather than installing and finding out.

• Media, reviewers, and documentation writers can immediately find information they need to dive deeper into a related topic. This page gives a journalist instant information to help them determine if a flavor of openSUSE has exposure fixes. Distribution comparisons are notoriously prone to stale or half-remembered version numbers, and a wrong number in a review can stick around for years in search results. A citable, timestamped, auto-generated source removes the excuse for guessing. If you write about openSUSE, you now have a footnote you can actually point at.

• Aggregators like DistroWatch where the site tracks package versions across dozens of distributions do enormous manual or semi-manual work to keep tables current. Machine-readable exports of an entire distribution’s package set, refreshed automatically, is exactly the kind of upstream cooperation that makes that work cheaper and more accurate. What do you say DistroWatch? Want to know “what’s in what” tables.

• Packagers and maintainers get immediate knowledge. The tool attaches the maintainer names to those rows so somebody knows who to ask.

• Contributors looking for a first task. One of the hardest parts of joining a distribution project is finding something concrete to do. A filtered list of packages that are behind, with maintainers listed, is a genuinely welcoming on-ramp.

• Sysadmins and platform teams gain quick confirmation for their development. Before migrating a fleet from Leap 16.0 to 16.1, or evaluating whether a workload can move from Tumbleweed to Leap, the practical question is which dependencies shift and by how much. The 16.0-versus-16.1 columns answer that directly, and the CSV drops into a spreadsheet or a diff script without ceremony.

• Developers targeting openSUSE will know which library versions your users will have, this is the compatibility matrix. It also tells you whether your own package is present in Leap at all.

• Researchers and the merely curious can have a lot of fun with the open-data. Full-distribution version data, published openly on a recurring basis, is a dataset. Software-ecosystem researchers and people who just enjoy graphing things now have raw material that didn’t exist in convenient form before.

Having Leap package versions visible alongside Tumbleweed’s is a meaningful shift in how a release gets communicated. Historically, “what will be in the next Leap?” was answered in release notes near the end of the cycle, or reconstructed by people willing to dig through OBS. Publishing the state of the in-development distribution as it evolves means the community can see the release taking shape rather than being handed a finished summary.

Small tools like this rarely get the attention they deserve, but a table that is always correct, always current, and freely downloadable quietly removes an entire category of friction from a project. We hope you enjoy it.

The openQA test suite for openSUSE and SLE has a test module called tests/console/sudo.pm. It verifies that sudo works: passwords, shells, sudoers rules, environment isolation. Basic stuff. It runs tens of thousands of times per year and takes about 9 minutes each time. That adds up.

Where the time goes

There is no single bottleneck. The test uses expect to interact with password prompts. Every sudo call goes through credential cache reset, process spawn, password entry, and result verification. It does this 20 times because the test runs the full suite twice with slightly different sudoers configurations.

Google Summer of Code is now over for openSUSE.

This summer, we had the privilege of mentoring eight contributors.

Mario Marín Hinojosa enhanced the openSUSE git workflow build results. He blogged about his progress and you can already see in it action on br.opensuse.org. See an example for devel:languages:python:Factory!

Akash Kumar wrote the foundation for an Uyuni on Kubernetes storage benchmark. This meant enhancing sumaform, the deployment tool used by the CI, to work with an existing Kubernetes cluster. He also wrote cucumber tests in the Uyuni test suite to benchmark the reposync and the download of packages from several minions. There are still other tests to add and he documented this all in the github mentoring issue. Akash will give a presentation at the openSUSE.Asia Summit in Yogyakarta in about a month; come and get to know him!

Digvijay Rawat worked on a AI agent to help with the root cause analysis of errors on Linux machines managed by Uyuni. He documented how it works, how to install it and what is left to be done in his repository. He also prepared a demo video to show how it off.

Geetansh Goyal added an MQTT publisher to Uyuni so its events can be used in automation. He also added Node Red nodes to use those events. His work is described in his repository. Tell us your use cases. Geetansh also presented at the openSUSE conference and would like to start buildin an openSUSE mirror and community in India. Find out how Geetansh described his Google Summer of Code experience.

Himanshu Jaiswal helped porting the Uyuni API docs to openAPI and Swagger. This was not just the matter of rewriting the doc from the current Javadoc to the new format, but also adding automation for it and fixing the many errors that came up. He documented the state of his project in a gist for the curious to take a look or help.

Jay Prakash added an mgrctl get command to wrap up the Uyuni API in a similar way to kubectl get. This only supports systems and system groups for now, but has been written with extensibility in mind to reduce the work needed for other Uyuni objects. He documented his work in a special git repository.

Surya Srinivasan worked on a native support of LDAP in Uyuni. With his work in, configuring the use of an LDAP server could be done from the Uyuni web interface! He described his work and what remains to be done in a gist.

Anuj Agrawal began the program this summer with us, but had to resign as he started working for Google. Congrats!! He started a chat bot project to help get started with openSUSE. The project uses a local SLM and RAG and was already nicely kicked out. To know more about the project, check out the code and documentation in his repository or read Anuj’s blog post about the openSUSE Assistant.

Many thanks to all eight of them for their involvement. We are looking forward to keep working with you all. Many thanks also to those who mentored them, gave time and patience to help them get started with contributing to openSUSE.

Dear Tumbleweed users and hackers,

This week saw the release of 6 snapshots (0827, 0828, 0829, 0830, 0901, and 0902).

It was an exceptionally productive week of updates, headlined by major transitions in our core toolchains. The base system has been elevated with the arrival of glibc 2.44, which brings foundational performance and security enhancements, including standard C23 library features, Intel/AMD shadow stack support, and optimized memory routines. Close on its heels came the system default transitions to Rust 1.98 and LLVM 23.1.0, giving developers access to the latest compiler features and optimizations.

On the core system front, the stable update of Linux Kernel 7.2.2 was delivered to maintain top-tier hardware compatibility. Virtualization hosts received a major update to QEMU 11.1.0, introducing substantial emulation improvements. Wireless network security was bolstered with the release of wpa_supplicant 2.12, and scientific workflows were updated with python-numpy 2.5.2. Finally, on the desktop side, we saw upgrades to pcre2 10.48 and xwaylandvideobridge 0.5.2.

These 6 snapshots delivered the following updates:

• chrony 4.9
• emacs 31.1
• flatpak 1.18.2
• glibc 2.44
• harfbuzz 14.4.0
• icewm 4.1.0
• libjpeg-turbo 3.2.0
• Linux Kernel 7.2.2
• llvm23 23.1.0
• nautilus 50.3
• pcre2 10.48
• python-numpy 2.5.2
• qemu 11.1.0
• rust 1.98
• wpa_supplicant 2.12
• xwaylandvideobridge 0.5.2

With these significant milestones checked off, it is time to turn our gaze forward to see what is currently brewing in our staging areas:

• Linux Kernel 7.2.3
• Mesa 26.2.2
• LibreOffice 26.8.0/RC3
• fontconfig 2.18.3: Currently held up as it breaks the AppStream test suite.
• Swig 4.5.0: Received a few fixes, but some YaST-related integration issues remain to be addressed.
• libnettle 4.0.0: Currently excluded from main staging runs while developers work on resolving test suite breakages in libzypp.

Source