I have 30 years of documented history on the web and in my personal recordings. That defines very well who I am, what I do, how I see the world, and how people see me. I worked on that. Sometimes consciously, sometimes as a side effect of my job, my side projects, my community work. Now that AI agents make it easy to use this kind of material, I have a base to anchor them, to build on what I did before and accelerate what I do, still staying me.

If you are starting now, you won't have this body of material to anchor your agents. So do spend some time building this corpus of what is genuinely you. Don't let an AI generate what you are. Write yourself, publish, think through your thoughts, give presentations. Small things are fine. They will accumulate over time.

Of course, tools will shape part of your identity. I used to do my presentations with xfig, printed on overhead projector slides. This was painful, but it shaped quite a bit how I worked and how the result looked. So it is part of my identity. The technical constraints did influence how I spoke, how I presented. It also shaped what I presented, because there was a bias toward what I could show with the tools available to me.

This won't be different with AI. It will shape who you are. But be aware, and make sure that there is a signal from the human in there. It's ok if it's imperfect, if it's a bit weird. It's ok if it's different. But make sure it's yours.

Shape that signal. That's you. That's your identity.

Copy Fail (tracked as CVE-2026-31431) is a critical vulnerability in the Linux kernel that allows a local non-root user to gain full root access to the system. It is considered extremely dangerous because it is a pure logic error – unlike other known holes like Dirty Pipe or Dirty COW, it does not require complex […]

The post SUSE responds to the copy.fail vulnerability appeared first on SUSE Communities.

We are excited to announce that the Call for Speakers for openSUSE.Asia Summit 2026 is now open! This year, the Summit will take place on October 3–4, 2026, at the Teaching Industry Learning Center (TILC), Vocational School, Universitas Gadjah Mada (UGM), Yogyakarta, Indonesia. For more details, stay tuned to our official channels and news portal.

The openSUSE.Asia committee invites speakers from all backgrounds to share their knowledge, experience, and passion for openSUSE and open source. Speakers may also apply for support from the openSUSE Travel Support Program (TSP). We encourage everyone, near or far, to submit their proposals and join us in Yogyakarta!

Topics

The examples of the topics (not limited to) are as the following:

• openSUSE (e.g., Leap, Tumbleweed, Micro OS, Open Build Services, openQA, YaST)
• Desktop environments and applications (e.g., GNOME, KDE, XFCE)
• Office suite, graphic art, multimedia (e.g., LibreOffice, Calligra, GIMP, Inkscape)
• Multilingualization support (e.g., input methods, translation)
• Cloud, Virtualization, Container, and Container Orchestration (e.g., Kubernetes, Rancher)
• Package supply-chain security, vulnerability management
• Embedded and IoT
• Other applications running on openSUSE

Topics that are not related to a specific technology are also welcome. For example:

• An overview of FLOSS technologies
• Development, Quality Assurance, Translation
• Tips & Tricks, Experience stories (success or fail), Best practice
• Marketing and community management
• Education

Types of sessions

We are inviting proposals for these two types of sessions.

• Long talks with presentation (45 min. + Q&A)
• Short talks with presentation (30 min. + Q&A)

Lighting talk sessions (5 min.) will be announced later.

Schedule

• Proposal submission deadline: 1 July, 2026
• Notification to speakers: 21 July, 2026

How to submit your proposal document

Please submit your proposal at events.opensuse.org. If you do not have a SUSE community account, please sign up before submitting your proposal.

• You must follow the openSUSE Conference Code of Conduct.
• Your proposal should be written in English, between 130 and 250 words, and have a clear, relevant title.
• Please check for spelling and grammar before submitting, using tools like LibreOffice, Google Docs, or Grammarly.
• See our guide for tips on writing a great proposal.
• If you need help, contact committee members in your country or region.

Requirements for your presentation

• You may present in English or Bahasa Indonesia, but all documents and slides must be in English.
• Speakers must be present at the venue; prerecorded videos and remote presentations are not allowed.

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
• Change History

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 several months, the migration was performed in Tumbleweed snapshot 20260505.

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

Change History

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.