Table of Contents

• 0) TL;DR
• 1) Introduction
• 2) Issues with current SELinux policy packaging
• 3) Solution: migration from /var to /etc
  • Packages involved in the migration
• 4) Troubleshooting
• 5) Closing Remarks
• 6) References

0) TL;DR

• The SELinux policy packaging had long-standing issues on systems using BTRFS snapshots: files under /var/lib/selinux were not covered by snapshots and could not be rolled back.
• These files have now been migrated to /etc/selinux, which allows the SELinux policy to be fully covered by snapshots.
• The migration applies to openSUSE Tumbleweed and MicroOS systems using SELinux.
• The migration is transparent to the user and automatic on default setups. If you have a non-standard filesystem setup, or if you observe issues, read the full post below.

1) Introduction

SELinux has been the Mandatory Access Control mechanism on openSUSE distributions such as MicroOS and Leap Micro since 2022, and most recently openSUSE Tumbleweed switched the default MAC to SELinux in February 2025.

The files installed on a system by the SELinux policy package have traditionally been split between /var/lib/selinux, /usr/share/selinux and /etc/selinux on most Linux distributions, including openSUSE. The separation across these directory trees conflicts with the modern Linux concept of atomic/image-based updates, which in openSUSE has been implemented as a snapshot and rollback mechanism based on BTRFS. This mechanism only snapshots the /usr and /etc trees, intended for packages and configuration respectively. Other directory trees are meant for user files or, as in the case of /var, for mutable system state files, and as such are not covered by snapshots.

Installing SELinux policy files under /var violates this requirement, and can result in inconsistency in case of rollbacks: policy files under /etc and /usr would be rolled back, but files under /var would not be touched.

To resolve this issue, we have migrated SELinux policy files under /var to /etc. The migration is automatic and does not require any user interaction in standard setups. This blog post explains the issue in more detail, documents the steps taken to migrate the files, and describes known issues and how to resolve them.

2) Issues with current SELinux policy packaging

Atomic/image-based update systems have become increasingly relevant in recent years. In openSUSE, this concept has been realised as both fully transactional systems (e.g. MicroOS, Leap Micro) and as regular distributions with automatic snapshots and the possibility to rollback broken updates (e.g. Tumbleweed). In both of these cases, the traditional SELinux policy packaging causes some issues.

In case of a rollback of an update containing a change to the SELinux policy, if there is a mismatch between what was rolled back (/usr/share/selinux and /etc/selinux) and what could not (/var/lib/selinux), this could lead to policy build issues, external module installation issues, and could bring the SELinux policy and the whole system into a state which is difficult to recover from automatically.

In practice, these issues are very rare, since they require a particular set of circumstances:

1. installing a policy update which contains backwards-incompatible changes (e.g. adding or removing SELinux types, attributes, modules …)
2. rolling back this update
3. performing some action which requires the SELinux policy items affected by the rollback, such as rebuilding the policy or an affected external policy module (either manually or e.g. via RPM package installation).

As a matter of policy, these kinds of backwards-incompatible policy updates are never performed on distributions such as Leap Micro (except possibly during migration between major distribution versions), thus preventing the issue. On Tumbleweed and MicroOS these updates can happen, albeit rarely, and when combined with the probability of a rollback and the further triggering actions they become exceedingly rare.

Manually reinstalling the SELinux policy package (and any affected external policy modules) is sufficient to fix the issues, but this is still an undesirable characteristic of this legacy packaging structure.

3) Solution: migration from /var to /etc

To permanently address the aforementioned issues, we decided to migrate SELinux policy files under /var/lib/selinux to /etc/selinux. As mentioned, this location was already used for other SELinux policy files, and is covered by the snapshot and rollback mechanism.

The migration was tracked in bsc#1221342. After a long period of automated and manual testing over the past few months, the migration will be performed in an upcoming Tumbleweed snapshot.

Some of the challenges encountered during the implementation of the migration process were:

• different rollback and update behaviour on classical and transactional systems (also transactional-update before version 5 used overlayfs for /etc)
• preserving existing local modifications to the SELinux configuration
• migrating custom modules (installed by packages or manually created by the user)
• packaging changes or rebuilds of some packages to properly reflect location changes, including RPM SELinux macros
• cleanup of /var/lib/selinux once no snapshot is using the old path
• installation on a fresh system, without migrating an existing system
• observability of discrepancies between migrated modules in /etc/selinux and last pre-migration state in /var/lib/selinux

The migration process is automatic and in most situations will not be visible to the user, except for information printed in the zypper output during the update. The process takes care not only of the migration of policy modules provided by the system SELinux policy (e.g. selinux-policy-targeted), but also of custom modules installed by other packages (see below) and local modifications to SELinux configuration (booleans, users, ports, …).

To allow the migration to be fully reverted, the process temporarily preserves the “old” /var/lib/selinux/ directory tree even after the migration. Once no snapshots are found which still refer to /var/lib/selinux, the whole directory tree is safely deleted.

Most of the steps are done during package update, except for the final cleanup step which is performed on the system after the migration has been completed. During package update, the migration process will:

• print information about the migration process and inform the user if the system satisfies the migration requirements (root BTRFS subvolume present) or if a non-standard setup was detected (e.g. /etc on different BTRFS subvolume or no BTRFS at all), and what to do in this case.
• check if the system has already been migrated and skip migration in this case (using marker files in /etc/selinux/selinux_modules_migrated-*)
• backup the old location (/var/lib/selinux) to preserve state (marker files selinux_modules_pending-* and temp_selinux_modules_dir_created)
• install package (modules) into the new location (/etc/selinux)
• copy local changes and custom modules (*.local files, 200, 400 and disabled folders) from the old location to the new location, show diff in case of missing custom modules from /etc/selinux (marker file selinux_modules_migrated-*)
• install cleanup systemd service (cleanoldsepoldir.service) and script(/usr/libexec/selinux/cleanoldsepoldir.sh) to remove the old /var/lib/selinux location once no snapshot is using it

After package update:

• at boot, the cleanoldsepoldir service checks if any snapshot still requires /var/lib/selinux. If not, it removes the directory, and creates marker file var_lib_selinux_deleted to stop the cleanoldsepoldir service from running again.
• the cleanup script also allows the user to check if there are some custom SELinux modules missing in the new location, and has some heuristics to find the RPM packages of non-migrated modules to reinstall them

$ /usr/libexec/selinux/cleanoldsepoldir.sh -h
This script checks if it is safe to remove the old /var/lib/selinux directory.

Usage:
  /usr/libexec/selinux/cleanoldsepoldir.sh (Checks snapshots and deletes /var/lib/selinux if safe)
  /usr/libexec/selinux/cleanoldsepoldir.sh --check-custom-selinux-modules (Checks for unmigrated custom modules)
  /usr/libexec/selinux/cleanoldsepoldir.sh -h|--help (Displays this help message)

Packages involved in the migration

These packages contain the SELinux policy packaging and were the main object of the migration:

• libsemanage-conf (store-root set to /etc/selinux/semanage.conf)
• selinux-policy (service cleanoldsepoldir.service and script cleanoldsepoldir.sh)
• selinux-policy-* (actual migration and marker files in /etc/selinux)

All packages which set SELinux booleans were rebuilt:

• selinux-policy-targeted-gaming
• selinux-policy-sapenablement
• container-selinux
• libvirt

Packages which ship custom SELinux modules were also fixed and rebuilt:

• cockpit-ws-selinux
• drbd-selinux
• google-guest-oslogin-selinux
• swtpm-selinux
• tigervnc-selinux
• tpm2.0-abrmd-selinux

We tried to identify all packages affected by this migration, but if you should find other packages in Tumbleweed which need to be migrated, please report a bug.

4) Troubleshooting

• If you have a non-standard filesystem setup (e.g. using custom BTRFS subvolumes, not using BTRFS at all, …) the migration may not work for you fully. You can find out if the migration was successful by checking for the presence of the directory /etc/selinux/selinux_modules_migrated-* corresponding to your installed policy (e.g. /etc/selinux/selinux_modules_migrated-targeted). If the directory exists, the migration has been successful. If not, please open a bug.
• If you observe any issues resembling those described in Section 2, you can resolve them by reinstalling the selinux-policy* package and any affected external modules:

  $ sudo zypper in -f selinux-policy selinux-policy-targeted
  

• After the migration, only the last state of /var/lib/selinux is preserved, which means that some older snapshots may still be inconsistent with it. If rolling back to one of these older snapshots is necessary, you can fix the issues after rolling back by reinstalling the policy and any affected external modules as detailed above.

5) Closing Remarks

The openSUSE SELinux team is committed to keeping openSUSE users safe with SELinux, and to fixing problems that SELinux may cause to the community. To facilitate changes with SELinux we rely on users to work with us and provide feedback, so that we understand what the current problematic areas are. If you encounter problems with SELinux feel free to open a bug or reach out over the mailing list.

6) References

• Tumbleweed Adopts SELinux as Default
• Policy migration tracker bug
• openSUSE Bugreport SELinux
• openSUSE SELinux Mailing List

Although OpenSSL 4.0 released just two weeks ago, the syslog-ng project has already received a GitHub issue complaining that we do not support it. So, before we would allocate too much effort on it: what should we expect?

OpenSSL 4.0 was announced on April 14: https://openssl-library.org/post/2026-04-14-openssl-40-final-release/ However, this announcement mentions that it is NOT a long-term support (LTS) release.

This raises the question that if it is not an LTS release, then can we stay on version 3.x and skip 4.x altogether? When will Linux distributions start using it? Looking at Repology, there are already a few places where OpenSSL 4.0 is available. This includes Gentoo, the community where the GitHub issue originated from, and also various FreeBSD ports. The current list is available at: https://repology.org/project/openssl/versions

Fedora is planning to use OpenSSL 4.0 as default starting from the next release: https://fedoraproject.org/wiki/Changes/OpenSSL40 However, OpenSSL 3.x will most likely stay supported for backwards compatibility.

I am also curious if there are any other projects which have added support for OpenSSL 4.0. If so, then what are your experiences? Was porting your code to use OpenSSL 4.0 difficult?

I am all in for supporting the latest technologies, but currently, even if we have an open request for OpenSSL 4.0 support, I do not feel that I have enough information to prioritize its development.

Share your thoughts with us in this syslog-ng GitHub discussion: https://github.com/syslog-ng/syslog-ng/discussions/5685 or reach out to me on Twitter / Mastodon / LinkedIn.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/support-for-openssl-4-0

It is with great joy that I officially announce the release in the openSUSE family (Leap and Tumbleweed) of the new package focused on cryptography resistant to the post-quantum era.

The libzupt library is designed to offer encryption and decryption of files and binary data in memory using a hybrid approach based on ML-KEM-768 + X25519.

libzupt is a modern SDK that simplifies the adoption of post-quantum cryptography in real-world applications. Currently, it has initial support for C++, Python, and Java, with support for Node.js (under development). Its goal is to make the implementation of advanced cryptographic mechanisms accessible without compromising usability for developers.

libzupt, created by Alessandro de Oliveira Faria, is a modern SDK that simplifies the adoption of post-quantum cryptography in real-world applications. Currently, it has initial support for C++, Python, and Java, with Node.js support (under development). Its goal is to make the implementation of advanced cryptographic mechanisms accessible without compromising usability for developers.

The project originates from the Zupt initiative, conceived by Cristian Cezar Moisés. As a tribute, the library inherited the name of the original project. Zupt, in turn, is a compression and backup tool that already incorporated advanced concepts such as authenticated AES-256 encryption and post-quantum key encapsulation.

The motivation behind libzupt is directly linked to the evolution of modern cryptography. The ML-KEM algorithm was standardized by NIST on August 13, 2024, as a secure key encapsulation mechanism for post-quantum scenarios. It allows for the secure establishment of keys even in insecure channels, anticipating future threats.

Below is a simple example of using libzupt in Python:

import zupt
encryptor = zupt.Encryptor(keypair.public_key)
message = b"Hello, Post-Quantum World! This is a secret message."
ciphertext, enc_header = encryptor.encrypt(message)

The main benefit of natively providing this library in openSUSE, is that it allows current applications to be prepared for a scenario where quantum computing could compromise classical algorithms, such as Shor’s Algorithm.

By combining traditional cryptography with mechanisms resistant to quantum computing, libzupt adds a strategic layer of protection. This enables the development of more resilient systems, ensuring the confidentiality and integrity of data in the long term, even in the face of technological evolution.

For more information, go to software opensuse or the source.

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog feed aggregator lists the featured highlights below from April 17 to 23.

Blogs this week cover a Tumbleweed weekly review delivering seven snapshots with notable updates including GNOME 50, KDE Plasma 6.6.4, and Linux kernel 6.19.12. The week also features the venue announcement for openSUSE.Asia Summit 2026 in Yogyakarta, a SUSE Security Team winter spotlight, performance tuning improvements in syslog-ng, a hands-on look at Cockpit as a YaST replacement, and more.

Here is a summary and links for each post:

Kookbook Updates to Version 0.3.0

The KDE Blog covers the 0.3.0 release of Kookbook, a recipe management application created by KDE developer Sune Vuorela. The update brings minor bug fixes along with a migration to Qt6. The application stores recipes as Markdown files and offers ingredient indexing, tag-based organization, and flexible synchronization through external tools like Git or Nextcloud.

Testing Cockpit, the YaST Replacement in openSUSE Tumbleweed

Victorhck in the Free World explores Cockpit, the web-based system management tool that is replacing YaST in openSUSE. After installing the cockpit-client-launcher and resolving missing GTK dependencies, the author found the interface clean and well-organized with familiar configuration options alongside modern features for managing storage, networks, and software repositories.

New Performance Tuning Possibilities in syslog-ng

Peter Czánik’s Blog discusses performance enhancements coming to syslog-ng 4.12 that achieved seven million events per second under laboratory conditions. While the figure represents a benchmark rather than a real-world deployment number, Peter explains that the underlying technologies are already available on the development branch or have existed for some time but lacked sufficient promotion and testing.

Best JPG to PDF Converters for Speed and Ease

The KDE Blog evaluates a range of JPG to PDF conversion tools, from desktop options like KDE Plasma’s Service Menus to online platforms such as Adobe Acrobat Online and iLovePDF. The post weighs each tool’s strengths regarding conversion speed, ease of use, and privacy, and also covers mobile solutions like CamScanner for document digitization.

AI Workshop at Linux Center Valencia

The KDE Blog announces a free AI-focused event organized by Slimbook at their Linux Center facility in Paterna, Valencia on April 25, 2026. The workshop features three sessions: an overview of current AI tools, a hands-on tutorial for running AI locally using Ollama and Fox, and an advanced session on creating autonomous AI assistants for personal computers.

From Virtual Desktop Deployment to Running Local AI – New Barcelona Free Software Talk

The KDE Blog announces a Barcelona Free Software talk on Tuesday April 28, 2026 at 19:00 at Akasha Hub in Barcelona, featuring Alberto Larraz, co-founder of IsardVDI. The talk traces IsardVDI’s 14-year journey from a Free Software alternative to Citrix and VMware Horizon in educational settings to a versatile platform that now leverages GPU management to run local AI inference workloads. Attendees will learn how IsardVDI can be used to generate images, run LLM chats, and power local code assistants using sovereign AI models.

SUSE Security Team Spotlight Winter 2025/2026

The SUSE Security Team winter report documents code review activities across multiple software projects. The team examined systemd releases v258 through v260, snapd transparency features, various D-Bus services including bootkitd and rtkit, and investigated SteamOS and Deepin desktop components. A revisit of Deepin software revealed persistent vulnerabilities in the accounts service, prompting the team to deprioritize future Deepin reviews.

openSUSE.Asia Summit 2026 Announces Venue at Universitas Gadjah Mada

openSUSE News announces that the openSUSE.Asia Summit 2026 will be held October 3–4 at the Teaching Industry Learning Center of Universitas Gadjah Mada in Yogyakarta, Indonesia. Organizers anticipate around 350 participants over two days of talks, workshops, and community activities. The venue was selected for its modern facilities and the university’s strong reputation as a leading Indonesian institution focused on education, research, and innovation.

Per-Screen Virtual Desktops and Wayland Session Restore – This Week in Plasma

The KDE Blog covers the latest This Week in Plasma highlights, including a major new feature in Plasma 6.7 that allows each monitor to independently switch between virtual desktops. KWin has also gained support for the Wayland session management protocol, paving the way for applications to remember their size and position after a system restart. The edition also rounds up numerous UI improvements, such as drag-and-drop support for app launchers, a new standard Badge component in Kirigami, and a range of bug fixes across Plasma 6.6.4, 6.6.5, and 6.7.

Hello Old New ‘Projects’ Directory!

Matthias Klumpp’s Blog introduces the xdg-user-dirs 0.20 release, which now enables a Projects directory by default in Linux home folders. The folder offers a standardized location for project files that do not cleanly belong in existing categories like Documents or Music. Users who prefer the old layout can simply delete the folder and the utility will adjust accordingly, while administrators can customize default locations through configuration files.

Tumbleweed – Review of the Week 2026/16

Victorhck and dimstar cover a busy week with seven Tumbleweed snapshots delivered in seven days across snapshots 0410 through 0416. Major updates included GNOME 50, KDE Plasma 6.6.4, Samba 4.23.6, PHP 8.4.20, GStreamer 1.28.2, and Linux kernel 6.19.12, along with improvements to transactional-update’s soft-reboot functionality. Looking ahead, the team is preparing significant upgrades such as Linux kernel 7.0, LLVM 22, and GCC 16 as the system compiler.

Episode 72 of KDE Express: Plasma 6.6.4, Gear 26.04 and More News

The KDE Blog shares the latest episode of KDE Express, a Spanish-language podcast covering the KDE community and open source software. The episode highlights significant releases including Plasma 6.6.4 and KDE Gear 26.04, along with developments across various KDE applications and distributions.

View more blogs or learn to publish your own on planet.opensuse.org.

Table of Contents

• 1) Introduction
• 2) Helper Overview
• 3) Security Issues
  • 3.a) Arbitrary chown() via Symlink Attack in sync() Method
  • 3.b) Arbitrary File Deletion in reset() Method
  • 3.c) Symlink Attack via /var/lib/plasmalogin/wallpapers in save() Method
  • 3.d) Missing Integrity Check of Configuration Data in save() Method
  • 3.e) Lack of File Descriptor and File Size Verification in save() Method
• 4) Suggested Fixes
• 5) Severity
• 6) Upstream Bugfix
• 7) CVE Assignment
• 8) Timeline
• 9) References

1) Introduction

In recent releases of the KDE desktop environment a fork of the SDDM display manager called plasma-login-manager has been integrated. As usual this led to a review in our team for the privileged D-Bus components contained in the package. While most of the code remains the same, the new upstream added a privileged D-Bus helper called plasmaloginauthhelper, which suffers from defense-in-depth security issues. The full details of the issues will be discussed in the following sections.

For this review we looked into plasma-login-manager version 6.6.2.

2) Helper Overview

plasmaloginauthhelper makes the D-Bus interface “org.kde.kcontrol.kcmplasmalogin” accessible to all users in the system via the D-Bus system bus. It offers three actions sync(), reset() and save() which are all by default protected by Polkit’s auth_admin setting.

These methods allow to manage configuration data stored in the home directory of the plasmalogin service user, which has a preset of /var/lib/plasmalogin. The helper runs with full root privileges and interprets various client-supplied data. The plasmalogin home directory has the following permissions:

drwxr-x--- 5 plasmalogin plasmalogin 4.0K Mar 24 13:25

Actually this helper is also a kind of fork of a helper found in the sddm-kcm repository, which we covered in a previous report. It seems the codebase has not improved since then, but rather additional attack surface has been added in the meantime.

3) Security Issues

3.a) Arbitrary chown() via Symlink Attack in sync() Method

In the sync() method the helper service naively performs chown() calls on files located in the service user’s home directory (/var/lib/plasmalogin), allowing a plasmalogin to root exploit.

The chown() is performed for the paths $PLASMALOGIN_HOME/.config, $PLASMALOGIN_HOME/.config/fontconfig as well for a list of configuration files like plasmarc placed into $PLASMALOGIN_HOME/.config.

A compromised plasmalogin service account can place symbolic links here to direct the chown() to arbitrary files in the system. After the chown() the helper writes client-supplied content into these files, which will also end up in arbitrary files in case of a symlink attack.

This method’s logic would also allow deletion of certain files like plasmarc in arbitrary directories, would the relevant statement in the service implementation not lack the final filename component in the path construction:

QFile(homeDir + QStringLiteral("/.config/")).remove();

Thus this removal logic doesn’t work at all at the moment, since it attempts to remove the .config directory instead of the actual configuration files.

3.b) Arbitrary File Deletion in reset() Method

In the reset() method the paths $PLASMALOGIN_HOME/.cache and $PLASMALOGIN_HOME/.config/fontconfig are recursively deleted. For this purpose the Qt API QDir::removeRecursively() is used. The implementation of this function follows symbolic links even in the final path component, which means that a compromised plasmalogin service user can leverage this logic to achieve the deletion of arbitrary directory trees in the system.

3.c) Symlink Attack via /var/lib/plasmalogin/wallpapers in save() Method

In the save() method the path /var/lib/plasmalogin/wallpapers is created and opened by root, using a system call sequence affected by a race condition. A compromised plasmalogin user can replace the directory by a symbolic link in time for the service to write wallpaper files to arbitrary locations in the system, leading to local Denial-of-Service (DoS) and integrity violation.

In this spot the helper employs a low-level openat2() system call to avoid symbolic link resolution, but this only applies to the actual files placed within the wallpaper directory, not to the directory itself, which is naively opened before that.

3.d) Missing Integrity Check of Configuration Data in save() Method

In the save() method the contents of the file /etc/plasmalogin.conf can be completely controlled by the caller. Since this method is protected by auth_admin Polkit authentication this is basically acceptable, but there is not even an integrity or syntax check of the data, the method blindly forwards whatever the client passes to it into this file, without a maximum size limit or any sanity checks. While this is not directly a security issue it is a lack of robustness, because the D-Bus service is responsible for maintaining a sane structure of the privileged configuration file, preventing a broken system e.g. in case of buggy clients.

3.e) Lack of File Descriptor and File Size Verification in save() Method

For the actual wallpaper files, file descriptor passing is employed, which is good. There is no upper limit enforced on the amount of data placed into the wallpapers directory, however, which allows to exhaust disk space in /var/lib/plasmalogin.

Even file descriptors passed from clients should be verified to check whether they refer to regular files and have no unexpected file flags set. This verification is missing.

4) Suggested Fixes

We suggested the following fixes to upstream:

• Foremost the helper should drop privileges to the plasmalogin user before performing any file system operations in /var/lib/plasmalogin, thereby eliminating all symlink attack surface. There still remains Denial-of-Service (DoS) attack surface if the service user places e.g. a named FIFO pipe somewhere. Avoiding this requires careful inspection of each path component by the service before opening it.
• The helper should verify the structure and size of data written to /etc/plasmalogin.conf.
• The helper should place a limit on the maximum amount of space which may be used for wallpapers in the plasmalogin user’s home directory.
• The helper should verify the type and flags of file descriptors passed by the client. The descriptors should not have special file types and they should not have any unexpected flags like O_PATH set.

5) Severity

None of the issues in this report is exploitable in a default installation of plasma-login-manager. Most of the problems affect the situation when the plasmalogin service user is compromised and thus affect defense-in-depth.

It is conceivable, however, that some actions in the helper, like the wallpaper management, could be reduced to lesser authentication requirements like a Polkit yes setting for locally logged-in users in the future, be it due to upstream changes or due to choices made by system integrators. Then further problems like disk space exhaustion by other unprivileged users could sneak in as well.

Based on the high severity of the defense-in-depth issues shown in this report, our assessment is that there is effectively no separation between root and the plasmalogin service user account.

6) Upstream Bugfix

At this time there is no bugfix available by upstream, but a security fix is planned for the next Plasma release on May 12. We have not been involved in upstream’s bugfix process so far and have no knowledge about the approach that will be taken to address the issues from this report.

7) CVE Assignment

We suggested a single CVE assignment relating to the lack of privilege drop of the D-Bus service, which is the root cause of most of the issues described in this report. In coordination with upstream we assigned CVE-2026-25710 and shared it with them to track these defects.

8) Timeline

9) References

• blog post about issues in sddm-kcm6
• blog post about the introduction of file descriptor passing in kauth
• openSUSE plasma-login-manager KCM helper review bug
• plasmaloginauthhelper code
• plasma-login-manager repository

A few years back I did a quick exploration of what GNOME app icons might look like in an alternate universe where we kept on using VGA displays. Chiselling pixels away is therapeutic. So while there is absolutely no use for these, I keep on making them if only to bring some attention to what really matters for GNOME, having nice apps.

Here's a batch of mostly GNOME Circle app icons, with some 3rd party ones thrown in.

If you're reading this on my site rather than Planet GNOME or some flickering terminal in an abandoned Vault, then congratulations. You've stumbled upon a working Pip-Boy module! Found it half-buried under irradiated rubble, its phosphor display still humming with that familiar green glow. Enjoy these icons the way the dwellers of Vault 101 were always meant to, one glorious scanline at a time.