Dear Tumbleweed users and hackers,

This has been a very productive week with 7 published snapshots (0220…0226). Naturally, some snapshots were a bit smaller than others.. It does not matter if you update to all intermediate snapshots or skip a few. Tumbleweed is built to be resilient against this and should not care much. We frequently hear that people fire up a VM that was last used one year ago, running zypper dup, and being positively surprised that this all works. But you should be allowed to expect that.

The 7 snapshots from this week brought you these changes:

• KDE Plasma 6.3.1
• GPG 2.5.4
• MariaDB 11.7.2
• Poppler 25.02.0
• LibXML 2.13.6
• PostgreSQL 17.4
• Mesa 25.0.0
• Linux kernel 6.13.4
• Boost 1.87.0
• ZStd 1.5.7
• move to openmpi5

Staging projects are well occupied – testing these changes/updates:

• KDE Plasma 6.3.2
• Linux kernel 6.13.5
• GCC 15: We will run the well-tested 2-phase approach from previous years: first, switch the used libraries to the ones generated by gcc15 (the phase we are currently working on), then later switch to GCC 15 being the compiler.
• glibc 2.41: please help work out the errors in https://build.opensuse.org/project/show/openSUSE:Factory:Staging:O
• Python 3.13 as the default Python interpreter: Pending issues can be seen at https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A. Just 1 more package to go: CEPH!

AI’s latest escapade into software piracy has left Microsoft scrambling, but let’s be honest; why even go through the hassle? If people are looking at not paying for an operating system, they don’t need to look far when alternatives like openSUSE exist?

With Linux distributions like openSUSE, there are no activation codes, no shady workarounds, no costs; just a fully functional, open and freely available operating system so users don’t have to break the law to break free from Windows’ licensing fees.

The Financial Benefits of Moving to Linux

Millions of computer users face a financial decision as they prepare for the end support for Windows 10 in October 2025; upgrade their operating systems at a cost depending on the users location, purchase new hardware with an OS installed or explore alternatives. Or, as Copilot seems to suggest, they could just ask an AI how to pirate Windows; because nothing says “secure computing” like taking legal advice from a chatbot.

For those feeling the pinch of rising costs due to stagflation, Linux distributions, particularly openSUSE’s Leap and Tumbleweed, offer a compelling, cost-effective alternative.

With no licensing fees, extended hardware compatibility and an abundance of software applications, Linux operating systems provide a compelling solution to reduce expenses while maintaining productivity, security and extending hardware lifespans to reduce electronic waste.

As part of our Upgrade to Freedom! campaign, this write-up focuses on the financial benefits of switching to openSUSE or another Linux operating system.

No Licensing Fees

One of the most immediate savings people notice when switching to Linux is the elimination of licensing fees. Licensing fees for some commercial operating systems can cost more than $100 USD per device. Enterprise solutions often incur additional costs for maintenance and upgrades.

Instead, people can save that money by going to get.opensuse.org and downloading an operating system without needing any codes or paying any money.

This zero-cost licensing model translates to significant savings to individual users, small businesses and large enterprises.

Investing in Linux is investing in one’s knowledge; it’s an investment into freedom. People get a professional-grade operating system without recurring costs using openSUSE.

Extend the Life of Your Hardware

Newer versions of Windows may require specific hardware features like TPM 2.0 and Secure Boot. For many older devices, this could render these devices incompatible and force users to purchase new machines.

The cost of a new laptop can run $350 USD or more, which is a substantial expense in a struggling economy. For a business, multiple devices could come at a hefty cost.

By contrast, openSUSE is optimized to run efficiently on a wide range of hardware, which includes older machines. Leap provides long-term stability, while Tumbleweed offers the news software updates to ensure devices remain relevant and functional for years to come. Members of the openSUSE community can also recommend using distributions like Slowroll, Aeon and Kalpa.

By switching to Linux, users may extend the life of their existing hardware and avoid contributing to any unnecessary e-waste; a cost that is much more precious than financial savings.

Apps and Open-Source Software

The financial benefits of Linux extends well beyond the operating system itself. The distributions provide access to a vast library of free, open-source applications that can replace costly proprietary software.

• Office Suites: LibreOffice is a powerful alternative to office suites that charge a premium.
• Creative Tools: GIMP and Inkscape provide robust alternatives to graphic design and image editing software, which can cost upwards of $600 per year for subscriptions.
• Development Tools: Developers can access free Integrated Development Environments like Visual Studio Code, JetBrains’ IntelliJ IDEA Community Edition and Eclipse.

For users who require specific Windows applications, tools like Wine, Bottles and Proton can help run those programs on Linux, which eliminates the need for additional software purchases. Linux systems are renowned for stability and security along with the reduction of time and money spent on IT support and maintenance.

Set up tools like YaST and advances with Agama provide intuitive ways to manage systems, updates, configurations and software installations, which can make it easy for non-technical users.

For businesses, the cost savings of switching to Linux can be immense. Companies running Windows often incur costs for server licenses and client access licenses (CALs). By moving to open-source solutions like openSUSE and its enterprise-focused sibling, SUSE Linux Enterprise, businesses can significantly reduce their IT expenses.

Small and medium-sized businesses can save thousands of dollars annually by adopting Linux. It’s not just about the initial savings but an ongoing reduction to operational costs.

As Windows 10 nears its expiration date, users and businesses have a choice: switch to openSUSE for a free, reliable solution; or start asking AI for sketchy workarounds and hope for the best.

Here is a step-by-step guide to start installing openSUSE.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.

Agama development goes on at good pace and, approximately one month after our latest blog post, we have more news for you. Not only a new version of Agama with a completely refreshed user interface and other significant changes, but also some information about the future.

New visual appearance​

Let's start with the most obvious change introduced at Agama 12. You may know that the Agama web interface relies on the Patternfly framework, the same design system used by Cockpit. In this version of Agama, we migrated to the latest major version of Patternfly (v6), which brings several improvements and quite noticeable visual changes. Moreover, we took the opportunity to align with the SUSE branding guidelines regarding aspects like typography, colors, etc.

More than ever, in this case a picture is worth a thousand words.

But the changes on the user interface go far beyond cosmetic aspects and general usability improvements. On top of that, some sections went through an overhaul.

Revamped Storage section​

In previous Agama releases, the section of the user interface used to configure the storage devices (partitions, LVM, etc.) was very powerful. It allowed to create complex setups over single or multiple disks based on partitions and/or LVM volume groups, to use hard disks directly formatted (without partitions), to reuse existing partitions or volume groups (optionally re-formatting them) and much more. But it had some problems.

On the one hand, most users failed to discover how to access to all those features. The interface was not self-explanatory enough. On the other hand, we were struggling to find a way to add more functionality (especially software RAIDs) in a consistent way. To make things a bit more problematic, the configuration generated by that user interface was not fully aligned with the usual mindset of our users currently relying on profile-based configuration (ie. unattended installation).

Thus, a couple of months ago, we decided to change the approach of that user interface. But it took us some time to reach a point in which the new interface is functional enough for basic configurations.

The new section is still far from its final form and also from providing all the possibilities of the previous interface. So expect significant updates on future releases, like bringing back the support to define LVM volume groups. Meanwhile, you can read about its existing and future capabilities at the corresponding section of the Agama user documentation.

Changes in authentication management​

Security is a topic that demands constant re-evaluation. When it comes to a Linux system, one of the first aspects of security is the way to organize users, privileges and authentication. SUSE and openSUSE have been reconsidering lately how to approach that and it seems clear that the traditional role of the root user and the default configuration of sudo are going to change in future releases of SLE and openSUSE Leap.

Agama 12 already takes the first steps to adapt to the new situation, removing the mandatory step to set a password for the root user and introducing a new Authentication section instead of the former Users one.

This is just the first iteration for a part of Agama that will receive several improvements regarding usability and wording in upcoming releases.

Post-partitioning script​

Not all changes at Agama 12 affect the user interface. Unattended installation also received a bunch of improvements, including the ability to execute scripts right after setting up the storage layout.

As you may know, both AutoYaST and Agama offer the possibility to specify custom scripts that can be executed at several points of the installation workflow. In previous versions Agama already offered the so-called pre-installation scripts, post-installation scripts and init scripts. But now Agama 12 offers also post-partitioning scripts that can be used, among many other things, to deploy configuration files before the packages are installed, modifying with that the behavior of the scripts included at RPM packages.

Information about AutoYaST compatibility​

And talking about unattended installation, we cannot forget one of the main features of Agama - its backwards compatibility with AutoYaST. Such a compatibility is not perfect and never will be, due to the difference in scope between both Agama (focused on installation) and AutoYaST (a more general configuration tool).

Now when Agama reads an AutoYaST profile it informs the user about the sections that will be ignored, making a difference between those sections that will be supported soon by Agama and those that are considered to be out of its scope even for the future.

The report can be disabled by specifying agama.ay_check=0 as a boot parameter.

We also took the opportunity to update the corresponding information at the AutoYaST compatibility reference document. What is even better, we introduced some mechanisms to generate such a document based on the same information used by Agama to generate the compatibility report during execution, so we can make sure the documentation is in sync with the actual implementation.

Improvements at the Live ISO​

Most users will execute Agama using the default installation media for SUSE or openSUSE distributions, which we unsurprisingly call Agama-live (since it is just a live Linux system running Agama).

Although the installation media is relatively independent from Agama itself, we take every Agama release as an opportunity to announce some of the latest improvements. In this occasion that includes some tweaks to the underlying window manager (IceWM), less aggressive settings for both power saving and the screensaver and the ability to open a terminal emulator by pressing ctrl+alt+t.

Find the latest version of the openSUSE Agama Live ISO image, including Agama 12, at its usual location.

A glance into the future​

This time we will use the release of Agama 12 as an opportunity to announce something else. We decided to add a Roadmap section to the Agama home page.

They say "plans are useless, but planning is indispensable". That may be the case of the Agama roadmap. We have a clear goal in the mid term, but we are constantly re-evaluating our priorities and the next steps to be taken. As such, you can expect that document to be updated often. Do not carve it into stone!

See you soon!​

As you can see in the mentioned roadmap, we plan to release Agama 13 by the end of March. And of course that will mean another blog post for you to enjoy the YaST Team adventures.

Meanwhile, you can also find us at SUSECON 2025, which will take place at Orlando (USA). Part of the team will be there to meet our beloved users and conduct a couple of sessions about Agama.

If you cannot be there in person, you can of course meet us at our usual online channels, like the Agama project at GitHub and the #yast channel at Libera.chat.

Have a lot of fun!

During CES Nvidia announced a new AI desktop supercomputer: Project DIGITS. Starting at $3000 it puts AI processing capabilities on the desktop what just recently needed multiple servers and a few more zeroes at the end of the price tag.

As an IBM Champion for POWER my first thought was that Project DIGITS is nice, but I’d love to see something based on POWER. Of course it’s just a game of thoughts, as IBM left the workstation business many years ago, both for x86 and POWER. So, even if I had some ideas, I did not care much about them. However, at FOSDEM someone described almost the same dream AI system. It means that I’m not alone, and it’s worth sharing this idea :-) And, of course, even if it is never implemented as a workstation, the technologies are interesting to learn about.

POWER 10 already has some extra instructions related to AI, making it efficient at AI tasks even without using a GPU. You can read more about it in the IBM blog at https://developer.ibm.com/blogs/run-ai-inferencing-on-power10-leveraging-mma/. Power 11 is coming this year, and will be include these instructions while being both faster and more energy efficient.

At IBM it’s not just Power CPUs when it comes to AI. They are also working on a dedicated AI accelerator card, called Spyre. I’m an environmental engineer by degree, so I very much appreciate IBM’s approach here. They focus on energy efficiency. If a single card does not provide you with enough processing capabilities, you can use multiple easy to cool cards, which also helps to reduce hardware failure rates.

After all this introduction I guess you could figure out our idea: a Power 11 + Spyre AI accelerator workstation. Just the smallest Power 11 CPU coupled with a single Spyre AI accelerator card and an entry level graphics card, all nicely packed in a well sealed silent case. The GPU here is just to drive the screen, not for AI. It could lower the entry barrier to AI on Power, and make developers more passionate about their jobs.

Why a workstation, and why do I mention passion? Having a workstation is not a requirement to develop for an architecture. However, I know from talking to people at FOSDEM, many other conferences or on-line, that most developers have more passion working on things on a machine on / under their desk. In the open source world, many important developments are born due to passion, in spare time, even by paid developers. Having a Power workstation with AI also could help in keeping POWER relevant in the open source world.

This month delivered multiple snapshots and a wide range of updates plus a major default change highlighted in mid-February and a major version update of the Mesa 3D Graphic Library. GIMP 3.0.0~RC3 appears close to being final with GTK 3.24.48 integration. KDE Plasma 6.3 enhances fractional scaling, introduces a refined zoom effect, and overhauls drawing tablet settings. Meanwhile, KDE Gear 24.12.2 refines usability, gdb 15.2 improves debugging efficiency and fwupd enhances firmware update handling. Other notable updates include postgresql 17.3, Ruby 3.4.2, and critical security fixes in OpenSSL 3.4.1.

As always, be sure to roll back using snapper if any issues arise.

Happy updating and tumble on!

For more details on the change logs for the month, visit the openSUSE Factory mailing list.

New Features and Enhancements

Mesa 25.0: This release introduces Vulkan 1.4 support on radv/gfx8+, along with multiple new Vulkan extensions for panvk, including VK_KHR_dedicated_allocation, VK_KHR_global_priority, VK_KHR_multiview, VK_KHR_shader_float16_int8, VK_EXT_image_robustness, and more. Initial GFX12 (RDNA4) support is also added for radv. Performance optimizations were made for radv, anv, and panvk, improving stability across different applications. Additional fixes improve Wayland and X11 compatibility, correct video decoding issues, and resolve memory leaks affecting various games and workloads.

GIMP 3.0.0~RC3: The latest RC finalizes GTK 3.24.48 integration, resolves crashes in Wayland and improves Right-To-Left text rendering. Image graph enhancements prevent unnecessary bit-depth conversions, which preserves detail in non-destructive edits. Thread-safe projection fixes eliminate crashes from multi-threading conflicts. The Script-Fu Application Programming Interface introduces a new named-argument syntax to make scripts more flexible and readable. Official AppImage distribution ensures a clean, upstream-supported package for Linux users. GEGL optimizations refine filters and floating-point operations. With only a few remaining bug fixes, GIMP 3.0 is nearly ready for release.

KDE Plasma 6.3: KDE Plasma 6.3 refines fractional scaling in Window Manager and Wayland Compositor KWin to provide sharper visuals and align elements to the pixel grid. The zoom effect provides a pixel-perfect magnification with a grid overlay that can be useful for designers. The Drawing Tablet settings receive a major overhaul with stylus pressure curve adjustments and better calibration. The system monitor improves CPU tracking while using fewer resources; its Info Center now displays GPU details and battery cycle counts. App store Discover enhances security by highlighting permission changes in sandboxed apps, and the Weather widget adds Deutscher Wetterdienst as a data source. Usability tweaks include touchpad auto-disable for mouse users, a reorganized launcher menu, and a refined kickoff behavior that switches categories only on click. Customization options expand with panel cloning, scriptable opacity adjustments, and flexible launcher icons.

gdb 15.2: This major version update improves startup performance with background DWARF reading and refines debugging features, including new commands for missing debug handlers and thread management. GDB now generates sparse core files, provides better error messaging, and supports configurable timeouts for inferior function calls. Changes in GDBserver simplify debugging options, and new Python API functions enhance scripting capabilities. The update also deprecates MPX-related commands and refines existing commands for clarity and consistency.

fwupd: This update introduces new features such as fwupdtool efiboot-hive for setting the nmbl cmdline, improved inhibition reason handling in fwupdmgr, and USB-provided hidraw support for DS-20 descriptors. Bug fixes include proper dbx deployment on MSI hardware, Lenovo version parsing corrections, improved Logitech HID++ detection, and performance optimizations. Additionally, support has been added for HPE Gen10/Gen10+ devices using Redfish, along with better handling of future Huddly devices and more reliable Logitech Rallybar updates.

KDE Frameworks 6.11.0: KDE Frameworks 6.11.0 improves Baloo’s database handling by propagating failure reasons and reducing manual management of m_env. Breeze Icons introduces a 12x12 version of the open-link icon and updates close icons to black X symbols. KConfig now reads defaults from the Windows registry and improves nested group value handling. Kirigami refines SwipeListItem’s keyboard navigation and fixes deep nesting in ActionsMenu. KIO addresses symlink path resolution in file properties and enhances file dialog undo behavior. KTextEditor improves bookmark cycling and refines theme config margins. KSVG enhances render cache thread safety, and KWallet removes unused functions for a leaner codebase.

KDE Gear 24.12.2: KDE’s Dolphin improves icon scaling and overlay handling, while Kdenlive fixes crashes, enhances effect stacking and improves rendering progress visibility. KMail and Kontact streamline account management, preventing duplicate entries when deleting accounts. KTrip and KWeather clean up unused strings for a smoother mobile experience. Kate ensures proper selection handling and fixes search match exports. Okular prevents hangs in forms with numerous choice fields and correctly responds to palette changes.

postgresql 17.3: This update addresses various security fixes and performance improvements. A key security fix strengthens encoding validation in PQescapeString and related functions to prevent potential SQL injection risks. Connection privilege checks and limits are now properly enforced for parallel workers. Several bug fixes improve database stability, including preventing catalog corruption during vacuum operations, fixing race conditions in parallel queries, and resolving unexpected transaction errors. Other enhancements include improved handling of SQL/JSON deparsing, better collation consistency in UNION queries, and optimizations for VACUUM and indexing.

Ruby 3.4.2: Key fixes for this package address segmentation faults in ripper, stack consistency errors in -ne, and unexpected behavior in Array#sum and Numeric subclasses. Parsing issues in prism and parse.y have been resolved, including recursion depth inconsistencies and handling of unnamed forwarding variables. Other fixes include improved compatibility with GNU Compiler Collection 15, corrections for Module#autoload? performance, TCPSocket error handling, and ensuring encoding consistency in ENV.inspect. Additionally, a TLS fix for ARM64 has been backported, and various syntax inconsistencies have been addressed.

wireplumber 0.5.8: This update introduces support for handling UCM SplitPCM nodes in the Advanced Linux Sound Architecture monitor and improves PipeWire channel remapping via loopbacks. New functions enable marking WpSpaDevice child objects as pending, which enhances the handling of asynchronously created loopback nodes. ALSA node name deduplication has been improved, which prevents unnecessary .2, .3 suffixes. Fixes include resolving duplicate Bluetooth SCO (HSP/HFP) sources in UIs, correcting stream-restore behavior for device loopback nodes, and addressing issues in wp_lua_log_topic_copy(). Additionally, test scripts have been updated for improved object identification consistency.

python-cryptography 44.0.0: This major pypi update drops support for LibreSSL < 3.9 and deprecates Python 3.7, which will be removed in a future release. Linux wheels are now compiled with OpenSSL 3.4.0. The update enforces RFC 5280 rules preventing empty extended key usage extensions, allows timestamp extraction for MultiFernet, and relaxes Authority Key Identifier requirements on root CA certificates. Support for Argon2id KDF is added when using OpenSSL 3.2.0+, along with support for the Admissions certificate extension. Additionally, PKCS7 decryption, including S/MIME 3.2, is now supported via new decryption functions.

python-pyOpenSSL 25.0.0: This major pypi update removes deprecated APIs, including CRL, Revoked, dump_crl, and load_crl, and transitions users to cryptography.x509 for CRL functionality. The sign and verify functions have been removed in favor of cryptography.hazmat.primitives.asymmetric signature APIs. Deprecated features include OpenSSL.rand (use os.urandom() instead), X509Extension, and elliptic curve functions. Future deprecations are planned for X509 and PKey objects, with users encouraged to migrate to cryptography.x509.Certificate and cryptography private keys. The update also introduces an as_cryptography argument for get_certificate and related functions, allowing cryptography.x509.Certificate objects to be returned.

Key Package Updates

Kernel Source 6.13.4, 6.13.3, 6.13.2: These updates includes various fixes and improvements across multiple subsystems. It addresses issues in Btrfs, including a lockdep splat fix and better handling of transaction aborts. Security improvements address x86 SRSO mitigation for missing IBPB on VM-Exit, HID device handling fixes for winwing and thrustmaster, and multiple pinctrl bug fixes. The updates also refined DRM and AMD display components, improving HDMI, DSC passthrough, and backlight quirks. Additional fixes improve schedulers, IRQ handling, logging, and filesystem stability. Various DRM bridge, panel, and connector updates enhance ELD handling and synchronization. Other enhancements improve safesetid policy checks, WiFi drivers, and device-specific optimizations.

curl 8.12.1: This update includes various security fixes, such as resolving password leaks between hosts, HSTS cache entry overwrites and an eventfd double-close vulnerability. Enhancements include support for PKCS#11 keys, QUIC 0RTT with GnuTLS, improved HTTP authentication tracking, and extended error handling for connection reuse. Notable bug fixes address TLS upgrade issues, DNS resolution improvements, HTTP retry handling, and performance optimizations across multiple protocols.

selinux-policy 20250211: This update sets SELinux as the default Linux Security Module (LSM) for all new installations. While AppArmor remains available, SELinux will be in enforcing mode by default on fresh installs, including the minimalVM variant. SELinux updates will continue refining the implementation in the coming weeks.

sdbootutil: This update introduces improvements to PCR 15 measurements, including a validator service and predictive capabilities for crypttab changes. The update also refines cryptographic device ordering when using FIDO2 keys and removes the .conf suffix from grubenv. Additional fixes ensure proper generator behavior when /etc/crypttab is missing and improve logging output for PCR validation.

GStreamer 1.24.12: This update resolves shader compilation failures in d3d12 and corrects framerate handling in decklinkvideosink. The gst-libav module now avoids crashes in audio encoders with insufficiently aligned input data and restores compatibility with FFmpeg 4.2. Other fixes include improved seeking and duration handling in oggdemux, PTS wraparound detection in tsdemux, and race condition fixes in vtdec on macOS. Enhancements were made to qtdemux for better matrix transformation and flipping support, while webrtc now prevents duplicate payload types when using RTX and multiple video codecs. Additional refinements were applied to wpe, x264enc, and win32-pluginoader, along with various memory leak and stability fixes.

XFSProgs 6.13.0: This update introduces significant improvements, including enhanced support for realtime volumes, quota handling, and metadata directories. The mkfs tool now allows recursive subvolume deletion and improved protofile parsing. xfs_repair adds support for quota inodes in metadata directories, while xfs_scrub accelerates phase 8 processing using histograms. Additional fixes address error reporting, device encoding, and concurrency improvements for realtime allocation groups. Various build, documentation, and tooling enhancements further refine the XFS ecosystem.

kdump 2.0.16: This update improves reliability with a fix for KDUMP_AUTO_RESIZE, addressing issues in crash dump resizing. The update also resolves a critical bonding configuration bug in dracut, which previously caused network failures in kdump initrd. The issue stemmed from improper parsing of bond device parameters, where MAC address colons led to errors. The fix ensures kdump correctly filters out problematic bond keys, preventing parsing failures.

Bug Fixes and Security Updates

Several key security vulnerabilities were addressed this month. Common Vulnerabilities and Exposures this month are:

qemu:

• CVE-2023-2861: Fixed a flaw in the 9p passthrough filesystem (9pfs) implementation that could allow a malicious client to escape the exported 9p tree by creating and opening a device file in the shared folder.

curl:

• CVE-2024-11053: Fixed a credential leak when using .netrc files in combination with HTTP redirects.
• CVE-2024-9681: Resolved an issue where HSTS subdomain entries could overwrite parent domain cache entries, potentially leading to incorrect HTTPS enforcement.
• CVE-2025-0665: Addressed a double close vulnerability with eventfd, which could lead to undefined behavior or application crashes.

emacs:

• CVE-2025-1244: Details about this CVE are currently unavailable. For the latest information, please refer to the official Emacs news page.

OpenSSL 3.4.1:

• CVE-2024-12797: Fixed an issue where clients using RFC7250 Raw Public Keys (RPKs) might not detect server authentication failures, potentially exposing TLS/DTLS connections to man-in-the-middle attacks.
• CVE-2024-13176: A timing side-channel vulnerability in ECDSA signature computations could allow attackers to recover private keys. This primarily affects the NIST P-521 curve and requires local access or a high-speed, low-latency network connection to exploit.
• CVE-2024-9143: Fixed an out-of-bounds memory access issue in low-level GF(2^m) elliptic curve APIs, which could lead to memory corruption or crashes.

postgresql 17.3:

• CVE-2025-1094: Fixed an SQL injection vulnerability in the psql interactive tool caused by improper neutralization of quoting syntax in certain functions.

ffmpeg:

• CVE-2025-22921: Addressed a segmentation violation in jpeg2000dec.c, preventing potential crashes.
• CVE-2025-22919: Fixed a reachable assertion in handling crafted AAC files, mitigating denial-of-service risks.
• CVE-2025-0518: Resolved a stack-based buffer overflow allowing remote authenticated attackers to execute arbitrary code.
• CVE-2025-25473: Fixed multiple vulnerabilities enabling authenticated remote attackers to execute arbitrary commands.
• CVE-2024-12361: Addressed a flaw in certificate data handling that could lead to denial-of-service conditions.

grub2:

• CVE-2024-45781: Fixed a strcpy overflow in the UFS filesystem.
• CVE-2024-56737: Resolved a heap-based buffer overflow in the HFS filesystem.
• CVE-2024-45782: Addressed a strcpy overflow in the HFS filesystem.
• CVE-2024-45780: Fixed an overflow issue in TAR/CPIO handling.
• CVE-2024-45783: Corrected a reference count overflow in the HFS+ filesystem.
• CVE-2025-0624: Fixed an out-of-bounds write during the network boot process.
• CVE-2024-45774: Resolved a heap overflow in the JPEG parser.
• CVE-2024-45775: Addressed a missing NULL check in the extcmd parser.
• CVE-2025-0622: Fixed a use-after-free issue when handling hooks during module unload in command/gpg.
• CVE-2024-45776: Corrected an overflow in .MO file handling.
• CVE-2024-45777: Fixed an integer overflow in the gettext function.
• CVE-2025-0690: Resolved an integer overflow that could lead to an out-of-bounds write via the read command.
• CVE-2025-1118: Ensured the dump command is blocked when GRUB is in lockdown mode.
• CVE-2024-45778: Removed the BFS filesystem from lockdown-capable modules.
• CVE-2024-45779: Fixed a heap overflow in the BFS filesystem.
• CVE-2025-0677: Addressed an integer overflow leading to an out-of-bounds write when handling symlinks in UFS.
• CVE-2025-0684: Resolved an integer overflow leading to an out-of-bounds write when handling symlinks in ReiserFS.
• CVE-2025-0685: Fixed an integer overflow leading to an out-of-bounds write when handling symlinks in JFS.
• CVE-2025-0686: Corrected an integer overflow leading to an out-of-bounds write when handling symlinks in ROMFS.
• CVE-2025-0689: Fixed a heap-based buffer overflow in UDF that could lead to arbitrary code execution.
• CVE-2025-1125: Addressed an integer overflow leading to an out-of-bounds write in the HFS filesystem.
• CVE-2025-0678: Resolved an integer overflow leading to an out-of-bounds write in SquashFS.

libtasn1 4.20.0:

• CVE-2024-12133: Fixed inefficient handling of specific certificate data, which could allow an attacker to send a specially crafted certificate, causing a denial of service attack.

libxml2 2.13.6:

• CVE-2025-24928: Fixed a stack-based buffer overflow in the xmlSnprintfElements function, which could be exploited during DTD validation of untrusted documents, leading to denial of service or code execution.
• CVE-2024-56171: Resolved a use-after-free vulnerability in the xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables functions, potentially leading to arbitrary code execution when processing crafted XML documents or schemas.
• CVE-2025-27113: Addressed a NULL pointer dereference in the xmlPatMatch function, which could cause application crashes when processing certain inputs.

gnutls 3.8.9:

• CVE-2024-12243: Addressed a flaw where decoding certain DER-encoded certificates could cause excessive resource consumption, leading to denial-of-service conditions.

mozjs128 128.7.0:

• CVE-2025-1009: Fixed a use-after-free vulnerability in XSLT that could lead to an exploitable crash.
• CVE-2025-1010: Resolved a use-after-free issue in the Custom Highlight API, potentially leading to a crash.
• CVE-2025-1011: Addressed a bug in WebAssembly code generation that could result in a crash and possible code execution.
• CVE-2025-1012: Fixed a use-after-free during concurrent delazification, which could lead to a crash.
• CVE-2024-11704: Corrected a potential double-free vulnerability in PKCS#7 decryption handling.
• CVE-2025-1013: Resolved an issue where private browsing tabs could be opened in normal browsing windows, leading to a potential privacy leak.
• CVE-2025-1014: Fixed improper certificate length checking when added to a certificate store.
• CVE-2025-1016: Addressed multiple memory safety bugs that could potentially be exploited to run arbitrary code.
• CVE-2025-1017: Resolved additional memory safety bugs present in the browser engine.

webkit2gtk3:

• CVE-2025-24143: Fixed a vulnerability that could lead to arbitrary code execution when processing maliciously crafted web content.
• CVE-2025-24150: Resolved an issue where visiting a malicious website may lead to address bar spoofing.
• CVE-2025-24158: Addressed a memory corruption issue that could allow an attacker to execute arbitrary code.
• CVE-2024-24162: Fixed a vulnerability where processing maliciously crafted web content could lead to arbitrary code execution.

Python311:

• CVE-2025-0938: Fixed improper URL parsing in urllib.parse functions, which accepted invalid domain names with square brackets, potentially leading to security issues.

PAM-PKCS 0.6.13:

• CVE-2025-24032: Fixed an issue where an attacker could create a token with a user’s public certificate and a known PIN, allowing unauthorized login without requiring the private key.
• CVE-2025-24531: Addressed a potential authentication bypass in error situations when using smart cards for login.

krb5:

• CVE-2025-24528: Resolved a flaw where an authenticated attacker could cause kadmind to write beyond the end of the mapped region, leading to potential security risks.

Users are advised to update to the latest versions to mitigate these vulnerabilities.

Conclusion

KDE users will notice a more polished and efficient experience with the latest KDE Gear, Frameworks and Plasma updates. Beyond the visible improvements, Tumbleweed continues to strengthen its foundation with essential security patches for curl, mozjs128, grub2 and PostgreSQL, along with optimizations in XML processing through libxml2. These ongoing enhancements ensure Tumbleweed remains a dependable, high-performance open-source platform for developers and users alike.

Slowroll Arrivals

Please note that these updates also apply to Slowroll and arrive between an average of 5 to 10 days after being released in Tumbleweed snapshot. This monthly approach has been consistent for many months, ensuring stability and timely enhancements for users.

Contributing to openSUSE Tumbleweed

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

One Identity Active Roles allows you to easily and securely manage Active Directory (AD), Entra ID and M365 Identity objects. While Active Roles stores its log messages into Windows Event Log, most log management and log analytics applications expect to receive log messages over the syslog protocol. This is where syslog-ng Premium Edition (PE) can help you. The syslog-ng Windows Agent can collect and forward Active Roles log messages from Windows Event Log, while the syslog-ng server can collect, process, store and forward Active Roles log messages to multiple destinations.

Installing syslog-ng PE together with Active Roles has many advantages, one of which is central log collection. This means that you do not have to log in to individual hosts to check logs, but instead can view logs from every host in a single location. This also enhances security, as logs are available even when they disappear from the original location due to a hardware failure or security incident.

From this blog, you can learn how to configure the syslog-ng Windows Agent to collect and forward Active Roles log messages from Windows Event Log, and how to parse and store the incoming log messages on the syslog-ng server side.

Read the rest at https://www.syslog-ng.com/community/b/blog/posts/collecting-active-roles-logs-centrally-using-the-syslog-ng-windows-agent

Dear Tumbleweed users and hackers,

This week was interesting from an engineering point of view and involved some under-the-hood work—like reworking the kernel-firmware packet into more than 30 smaller source packages. The benefit is for the users: finally, only the kernel—* package with the relevant blobs needs to be rebuilt and distributed. Before, they were all just the outcome of one large build and their build counters were in sync. So updating firmware in package A resulted in also rebuilding B – and having users update this, despite not having a single change.

As part of the 4 published snapshots (0216, 0217, 0218, and 0219) there were also some more user-visible – or admin-relevant – updates, like:

• cURL 8.12.1
• Pipewire 1.3.82
• Linux kernel 6.13.2 & 6.13.3
• KDE Frameworks 6.11.0
• SELinux 3.8
• openSSL 3.2.4
• Zypper 1.14.84: aborts dup in case of repositories not being available
• PHP 8.3.17
• PostgreSQL 17.3; PostgreSQL 12 has been removed from the repository
• Qemu 9.2.1
• Ruby 3.4.2
• systemd 257.3
• openSSH 9.9p2

The items being worked on, based on the Staging area, are:

• KDE Plasma 6.3.1
• MariaDB 11.7.2
• Mesa 25.0.0
• Boost 1.87
• ZStd 1.5.7
• move to openmpi5
• glibc 2.41: please help work out the errors in https://build.opensuse.org/project/show/openSUSE:Factory:Staging:O
• Python 3.13 as the default Python interpreter: Pending issues can be seen at https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A. Just 4 more packages to go!

Table of Contents

• 1) Introduction
• 2) History of Privileged File Operations in KDE
  • KTextEditor File Saving Operation
  • KIO Framework for Privileged File System Operations
  • The kio-admin Back End
  • Integration of kio-admin into the Dolphin File Manager
• 3) Assessment of Security Concerns
• 4) Rationale for Accepting kio-admin into openSUSE
• 5) Recommendations for Users of kio-admin or gvfs
• 6) Next Steps for Inclusion of kio-admin
• 7) References

1) Introduction

kio-admin is a KDE component which allows to perform privileged file operations in GUI applications. It implements a D-Bus service running as root and uses Polkit for authentication. A typical use case of kio-admin is found in KDE’s Dolphin file manager, which allows to enter an admin mode, in which file manager operations are carried out as root instead of as the unprivileged user.

The initial 2022 request to add kio-admin to openSUSE was rejected by us due to security concerns. Some time ago we have been asked to revisit this package to see if it could be added now. The security assessment of kio-admin is a difficult one, nonetheless we decided to accept it into openSUSE this time since the probability of actual exploits is low. The following sections explore the history of privileged file operations in KDE up to kio-admin, the rationale for accepting it into openSUSE at this point and recommendations for safely performing privileged file operations in complex scenarios.

2) History of Privileged File Operations in KDE

KTextEditor File Saving Operation

Historically, for performing privileged operations in GUI applications, the complete application had to be executed as root. Doing so is generally discouraged, since GUI programs are complex and not always written with potential security issues in mind. Also the inner workings of the X11 protocol and X server implementations have been a reason for security woes when running graphical applications with raised privileges.

One way out of this “all or nothing” approach was the introduction of Polkit, which allows to define individual actions for privileged operations. These actions are authenticated by the polkitd daemon. Applications are then typically separated in two parts. An unprivileged graphical application which contains the majority of the code communicates with a back end to execute the privileged operations. The back end is much smaller in size and runs as root.

This approach works well when the nature of the privileged operation has a clearly defined scope like “enable a VPN connection” or “connect to a Bluetooth device”. Problems arise, though, when this is not the case. This happened in KDE in 2017, when a D-Bus service with Polkit authentication was added to KTextEditor. This service is part of a feature which allows an unprivileged user to save a file to a privileged file system location after entering the root password. From the end user’s point of view this makes perfect sense: why shouldn’t the user of a typical single-user desktop system be allowed to change configuration files this way?

Former security team member Sebastian Krahmer was kind of outraged by this idea, though, because the Polkit action lacked a well-defined scope. Writing arbitrary data to arbitrary files on disk can lead to all kinds of problematic situations. Let’s consider a few scenarios:

• a file is saved in a system configuration directory owned by root, like /etc/fstab. This is likely the typical use case considered by the upstream developers.
• a file is (accidentally) saved to an unprivileged location the user controls anyway like /home/$USERNAME/some_file. The privilege escalation would not even be necessary in this case, but acting with root privileges in this location is dangerous.
• a file is saved to a configuration or state directory owned by an unprivileged service user like /var/lib/chrony. Now three different user accounts are involved: the unprivileged user providing the file content and asking for the operation, the root user performing the privileged operation and the service user chrony which actually controls the file system location where the write is about to happen.
• a file on a pseudo file system like /proc or /sys could be changed this way. Pseudo files often have special semantics with regards to the way data is written to them. Without being aware of this, the privileged KTextEditor helper component could cause side effects or simply not fulfill correctly what the user had in mind.
• a target path might not yet exist. Should it be newly created? What ownership and mode should be applied to such a newly created file?
• a target path might exist, but have a special file type. By naively accessing such files, the write could be redirected to unintended locations (by following symbolic links) or denial-of-service could occur (by blocking on a FIFO pipe). What should be done in this case: should the write operation fail, should the special file be silently replaced or should the user be asked interactively what to do?

We can see from this list that many different situations can result from what looked like just a simple “file save” operation in the beginning. We reviewed the code for this KTextEditor feature more closely and discovered CVE-2018-10361, a local root exploit when the privileged back end attempts to save a file in a directory owned by another unprivileged user.

After the finding was fixed by upstream we asked for a number of improvements before we would accept this D-Bus service into openSUSE:

• the destination path should be added to the Polkit authentication message (bsc#1147035). Currently it would only show a generic message about manipulating a privileged file. To prevent potential accidents or even spoofing, the message should clearly state what is being authenticated.
• the target file ownership and mode should be completely defined either by the back end, or by the front end (bsc#1147038). Currently the front end could optionally pass the file owner and group, but not the mode. For creating new files, the GUI part should ideally actively ask the user for the desired file properties. This is because neither the back end nor the front end can reliably guess the mode for new files. Should it be world readable or not? Should it be controlled by root, or by a service account or even another interactive user? This is something that can only be answered by the user asking for the operation to be performed.
• the back end should not replace anything except regular files. Symlinks should not be followed, any other special files should not be accessed or replaced (bsc#1147041).
• when writing to a directory not owned by root, then the back end component should drop privileges to the owner of the directory before performing file operations within it (bsc#1147043).
• a restriction on destination file systems should be implemented, e.g. to prevent the operation on pseudo file systems (bsc#1147045).

We never heard back from upstream or our KDE maintainers on any of these points, therefore this part of KTextEditor is still not enabled on openSUSE. Implementing most of the changes we requested would have been well within reach; only the dynamic authentication message involved some obstacles, because the Qt and KDE framework libraries for Polkit did not fully support this at the time.

KIO Framework for Privileged File System Operations

While there was no progress with the requested improvements of the “save file to an arbitrary location” feature in KTextEditor, developers of the KIO framework around the same time attempted to extend the concept of privileged file operations via D-Bus and Polkit even further. There was an effort to make a full range of privileged file operations available to GUI applications: chmod(), chown(), unlink(), mkdir(), rmdir(), open(), opendir(), rename(), symlink() and utime(). We were asked to participate in design discussions about this feature.

The resulting D-Bus service ended up being something like a mini kernel in user space, offering all kinds of file system APIs. Some of the problems observed in KTextEditor became even worse in this approach. While in KTextEditor it is at least clear that only regular files are supposed to be accessed, nothing is known about the context of the file operations in KIO. All the individual operations are detached from each other. Applications typically need to perform a specific task covering a certain range of file operations that are logically related. One such task might be to atomically replace a file in a privileged location by a new version of the file. This would require a sequence of calls like open() for the new file to be created, a chown() to assign the desired ownership to it and finally a rename() to replace the old file by the new file. The KIO D-Bus service did not have this additional context information and thus could not clearly inform the user about what is going to happen.

Only a single Polkit action “org.kde.kio.file.exec” was used to authenticate any of these privileged file system operations. The authentication message displayed to users is, like in KTextEditor, a generic one. Users won’t be able to determine exactly what kind of file operation they are authenticating. The user will either be presented with multiple authentication requests for a single task (auth_admin Polkit setting) or the D-Bus service will cache authentication for some time (auth_admin_keep Polkit setting) thereby allowing an unknown amount and range of file operations to be performed for an indefinite time span. In both cases the scope of what is authenticated is unclear to an average end user.

Since a generic D-Bus service that offers file operations cannot know what the logical goal of a client application is, the service basically needs to expose all variants of file system operations and the flags influencing them to applications. Modelling this on D-Bus correctly and completely is a difficult task. Such an approach also puts a burden on the applications that now need to implement complex sequences of system calls indirectly via an asynchronous D-Bus IPC interface.

Another approach to make an interface like this work in a robust and safe way could be to implement some form of transaction handling. The application would request a task like “replace /etc/fstab” and register a sequence of calls that are logically related for this task like: open /etc/fstab.new, chmod /etc/fstab.new, rename /etc/fstab.new to /etc/fstab. The back end would then only authenticate and allow these file operations on the requested paths. This again would lead to a highly complex interface, however.

Securely operating in arbitrary file system locations with raised privileges is already a highly difficult task when doing so using plain system calls. The program has to take into account the necessity to perform a privilege drop to the owner of a directory, it needs to avoid following symbolic links in many situations, it might need to open files using the O_PATH flag to avoid accessing dangerous special files unwittingly. The task just seems too complex to cover it generically using an abstract IPC interface. Polkit as an authentication mechanism is also not suited well for such a kind of generic API.

As a consequence of the involved complexities, after long discussions, upstream abandoned this feature. The code is still present in the KIO repository, but the privileged file_helper is not installed.

The kio-admin Back End

With this we arrive at kio-admin. We were asked for inclusion of this D-Bus service in 2022. It is another variation on the “privileged file operation” theme. Only this time it is not an integral feature of the KIO framework, but a separate component running as root that acts as a regular client towards KIO.

We decided not to accept kio-admin for mostly the same reasons as we have stated previously regarding KTextEditor and the KIO framework feature above. In 2024 we have been asked to revisit kio-admin, to check if it improved in the meantime.

Sadly the situation did not change much. The range of file operations offered is very similar to what was proposed for KIO: chown(), chmod(), mkdir(), listing directory contents and so on. In some respects the API is even worse than what was proposed for KIO earlier, because all operations are performed on paths, not on file descriptors. There is less control over individual operations with regards to following symbolic links and other behaviour of system calls. The implementation of the D-Bus service is more complex, requests are asynchronously forwarded by kio-admin to KIO. The kio-admin D-Bus API also uses URIs like “file:///etc/fstab” instead of plain paths.

Again there exists only a single Polkit action “org.kde.kio.admin.commands” which uses a generic authentication message for authorization of any of the offered operations. The scope of the request that gets authenticated remains again unclear to users.

The actual implementation of the file operations found in the KIO framework is often naive with respect to occurrence of symbolic links and also subject to race conditions, should a third user account in the system have control over the directory in which the operations take place.

Integration of kio-admin into the Dolphin File Manager

One of the main use cases of the kio-admin component is found in the Dolphin file manager “admin mode” feature. This is a mode in which all file operations are forwarded to the kio-admin back end, to perform them with raised privileges.

The way this feature is implemented in Dolphin is actually well thought out. There are clear warnings and a visible red bar at the top as long as the “acting as admin” mode is active. Also Dolphin rejects changing symbolic link targets and correctly displays that link permissions cannot be changed.

This cannot completely fix things like race conditions on part of the kio-admin back end, however. When Dolphin sees a regular file for example, and triggers a request at kio-admin to operate on it, the path could be replaced by some other file type by the time the KIO framework starts operating on it.

3) Assessment of Security Concerns

The concerns we have about privileged file operations exposed via D-Bus APIs affect local system security. These days it is often argued that nearly all Linux desktop systems are single-user desktops and thus local system security is not important. The attack surface found in kio-admin can still affect defense-in-depth, though. Consider file operations taking place in directories owned by unprivileged service users or by nobody. If such an account is compromised, then attack vectors like symlink attacks can lead to full privilege escalation. In this sense, every Linux system could be considered a multi-user system, even if no other human interactive users are present.

The general purpose nature of such APIs makes it hard to judge what future uses might look like. Once such an API is accepted into the distribution, it is difficult to keep track of additional consumers of the API. The proliferation of its use, maybe also in the area of non-interactive background tasks, could increase the dangers we already identified.

For these reasons we rejected the inclusion of the kio-admin API into openSUSE up until now.

4) Rationale for Accepting kio-admin into openSUSE

We have dealt with these types of APIs in KDE since 2017 without achieving any notable improvements. As we are responsible for product security we tried to protect our users from potentially harmful components. At this point, though, we don’t believe that this situation will change anytime soon. Meanwhile users still want to use features like the one found in Dolphin, and don’t understand why openSUSE does not include them.

We realize that using non-robust APIs is still an improvement over running graphical applications completely as root. Also in its current form, the likelihood that an operation interactively performed via kio-admin is actually exploited, is low.

There also exists a GNOME desktop component called gvfs which is very similar to kio-admin. It was accepted into openSUSE in 2017 without looking in detail at its purpose and API design. In the context of the discussions about KTextEditor we performed a second more in-depth review, during which we found problems closely resembling the concerns about kio-admin discussed in this article. Still, we decided to keep it in openSUSE, due to historical reasons.

Thus, on the grounds of equal treatment and to allow for a good user experience on openSUSE, we have now decided to set aside our concerns about kio-admin and admit it into openSUSE. This feels like the pragmatic choice to us given the circumstances. We would have liked to see a more robust and transparent API design, however. We hope that upstream developers find ways to better address our concerns in the future, meanwhile we still recommend end users to be careful when using these features and take heed of the recommendations we give in the next section.

5) Recommendations for Users of kio-admin or gvfs

Unfortunately there are many pitfalls when performing privileged file operations. We assume that even power users tend to make mistakes when running shell commands as root operating in directories controlled or influenced by non-root users, like in /tmp. Following is some general advice that can help to avoid such mistakes.

For a start, APIs like kio-admin and gvfs are usually safe to use when file operations happen in directories owned by root, like in /etc (note that sub-directories of /etc can again be owned by non-root users). Special care should be taken when changing files in directories controlled by another user, like another user’s home directory or files owned by a service user account.

In such scenarios it is safer to perform the operations in a root shell, and one should be very careful not to follow symbolic links while doing so. Many file management utilities offer specific switches to avoid following them. The chmod utility, for example, will by default follow symbolic links in the target file path unless the -h switch is passed to it.

Even these switches only protect against symbolic links in the final component of a path. Consider the command chmod -h 644 /var/lib/chrony/sub-dir/target. /var/lib/chrony is controlled by the chrony service user account. Thus the unprivileged chrony user can turn sub-dir into a symbolic link pointing to a privileged location like /etc. If /etc/target existed then the command above would make this file world-readable.

Therefore an even better approach to editing files owned by another account is to assume their identity, for example by invoking sudo -u <user> -g <group> /bin/bash. This way no elevated privileges that could be abused by a compromised account are present in the first place.

6) Next Steps for Inclusion of kio-admin

Documenting our concerns in this blog post is the first step of the process to add kio-admin to openSUSE. We will reference this blog post and some hints in dedicated README files added to the kio-admin and gvfs packages. We will also document this in the openSUSE wiki. When all of this is done we will perform the necessary steps to allow kio-admin into openSUSE Tumbleweed, which we believe will happen within the next two weeks.

7) References

• kio-admin Git Repository
• Dolphin file manager Git repository
• KTextEditor Git repository
• GNOME gvfs wiki page

Data breaches and cyber threats are becoming increasingly common and securing your personal and professional information has never been more critical.

Users transitioning from Windows to Linux through the Upgrade to Freedom campaign can use openSUSE’s tools to protect sensitive data, which include full disk encryption (FDE).

Full disk encryption during installation ensures maximum security. It safeguards all data on your hard drive by encrypting it and makes it unreadable without an decryption key. This level of protection is vital for preventing unauthorized access if your laptop or desktop is lost or stolen.

FDE with openSUSE is both user-friendly and powerful. The setup with advanced security features is easy.

For users seeking feature parity with Windows BitLocker, openSUSE offers Full Disk Encryption (FDE) secured by a TPM2 chip or a FIDO2 key. This advanced setup enhances security by storing encryption keys within the TPM, which ensures that only a trusted system configuration can unlock the disk. For a step-by-step guide on enabling this feature, read the Quickstart in Full Disk Encryption with TPM and YaST2 article.

Here’s a step-by-step guide to set up FDE on your system:

Step 1: Download and Boot openSUSE

• Visit get.opensuse.org to download the latest version of openSUSE Leap or Tumbleweed.
• Create a bootable USB drive using tools like balenaEtcher or another image writer.
• Restart your computer and boot from the USB drive to begin the installation process.

Step 2: Configure Encryption During Installation

• Once the installer starts, select your preferred language and keyboard layout.
• In the partitioning setup, choose Guided Setup with Encrypted LVM.
• Set a strong passphrase for encryption. This passphrase will be required every time the system boots. Use a mix of upper and lower case letters, numbers and special characters for optimal security.
• Proceed with the installation as directed by the installer.

Step 3: Verify Encryption Settings

After installation is complete and the system restarts, you’ll be prompted to enter your encryption passphrase. Once entered, openSUSE tools will decrypt the disk and boot normally. To confirm encryption is active:

• Open a terminal or console.
• Run the command lsblk -f to verify that your disk is listed with the encryption type (e.g., crypto_LUKS).

The output might look something similar to the following:

NAME        FSTYPE      FSVER LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                     
├─sda1      ext4        1.0     4a83v1e1-e8d2-4e38-815d-fd79j194f5   25G    30%    /
└─sda2      swap        1           d2e18c23-9w4b-4d26-p1s2-cm2sd64tx9de                
sdb                                                                                     
└─sdb1      crypto_LUKS 1           10bb2vca-81r4-418b-a2c4-e0f6585f2c7a                
  └─luks    ext4        1.0         8a9wka1b-7e9c-1a1f-a9f7-3c82x1e4e87f   150G    10%    /mnt/data

Step 4: Regular Backups

While FDE protects your data, it does not prevent data loss from hardware failure or accidental deletion. Regularly back up your data to an encrypted external drive or a secure cloud service to ensure its safety.

Post-Installation Encryption If you want to encrypt an existing partition after installation, visit the openSUSE wiki page about encryption.

Enhanced Security for Modern Challenges

Setting up full disk encryption on openSUSE not only protects your data but also aligns with the Upgrade to Freedom campaign’s mission of empowering users to maintain control over their hardware and privacy. By combining open-source software with good security practices, openSUSE ensures that users can confidently embrace a more secure digital future.

For additional guidance and community support, visit the openSUSE forums or join discussions at your local Linux user group.

Please be aware that some hardware configurations may require additional drivers or BIOS settings adjustments for full disk encryption to fully function properly. Check your device’s compatibility and update your firmware before proceeding.

The Reproducible-openSUSE (RBOS) project, which is a proof-of-concept fork of openSUSE, has reached a significant milestone after demonstrating a usable Linux distribution can be built with 100% bit-identical packages.

Reproducible builds ensure software can be rebuilt in an identical, bit-for-bit manner anywhere at any time using the same tools. This means that someone rebuilding the software from the same source code will get exactly the same results.

Why is this important? Because it’s a crucial aspect for supply-chain security.

This milestone for RBOS, led by openSUSE member Bernhard Wiedemann, advances software supply-chain security.

Reproducible builds allow us to confirm that the binaries used are correct, which ensures software has not been tampered with during the build process. By comparing identical outputs from different build environments, developers can detect issues such as accidental errors or malicious alterations. Without it, developers have to trust the build-process blindly or review binary-diffs manually, which is hard and time consuming.

In practice, reproducible-builds have found dozens of bug from race-conditions to compiling for incompatible CPUs with flags like via -march=native. Since Linux is a major component that operates the Internet, which is not only servers and routers but also client machines, improving security is vital.

The nice people at the nlnet foundation’s NGI0 Entrust fund sponsor open-source initiatives that improve the security of the internet. Wiedemann took on this 4-month-long project to create a fork of openSUSE that has 100% bit-reproducible packages. So far ring0 (aka bootstrap) and ring1 with 3,300 software packages have all successfully been patched and tested. Overall, the 16,000 source packages in openSUSE Factory have around 300 packages with issues left and information about this can be found in the following links:

• https://en.opensuse.org/openSUSE:Reproducible_openSUSE
• https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part1
• https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part2

Approximately 40 patches were needed and some more were completed before this project. Usually half of these patches are upstreamed.

With this, it is now possible to do a change in a toolchain package, rebuild everything and see exactly what changed as a result of the change.

RBOS does not receive security updates, so it is not recommended for productive use; it does however demonstrate how a full-bit-reproducible OS could be produced.

As patches make their way into openSUSE Factory, it should become easier to create a refresh in a year or two. Maybe it will become so little effort that each of the monthly Slowroll snapshots can be adapted into an RBOS-snapshot.

Ongoing work on a git-based OBS workflow could further support this effort, as tools like ‘git rebase’ can streamline and automate the process of integrating and updating patches.

How to test:

Grab the altimagebuild VM image with:

wget https://download.opensuse.org/repositories/home:/bmwiedemann:/reproducible:/distribution:/ring1/standard/src/altimagebuild-1-1.1.src.rpm

or

wget https://rb.zq1.de/RBOS/ring1/_build.standard.x86_64/altimagebuild/altimagebuild-1-1.1.x86_64.rpm

and run it as documented in https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part2#How_to_run_a_VM

Where does reproducible builds not help?

• bugs + backdoors in the source (e.g. xz-5.6.0) need source-code reviews
• backdoors in used build tools can be found with diverse-double-compilation = https://dwheeler.com/trusting-trust/ or be avoided with bootstrapping = https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/. Both of these methods only help if you have reproducible builds.

The milestone RBOS reached is an ongoing effort to provide more transparent, verifiable and secure software.