This year, I was back in Brussels. I visited two conferences: CentOS Connect and FOSDEM. As usual, both events were fantastic, with great talks and nice people. And as usual, they were also exhausting and not just for introverts like me. I stayed to Belgium to recover, but that’s another story… :-)

CentOS Connect

Some people still ask me why I visit Red Hat events, especially because I am a proud openSUSE desktop user, while FreeBSD feels the closest to me when it comes to software design and philosophy – not to mention that it is the OS that I have been using the longest (since 1994). The answer is easy: over 70% of syslog-ng users run syslog-ng on RHEL, CentOS or a compatible operating system. This means that regardless of my OS preferences, I have the strongest connections with the Fedora / RHEL / CentOS & Co. communities. And over the past 15 years, many of these professional relationships evolved into friendships.

As expected, the main topic of CentOS Connect was CentOS Stream 10, EPEL 10 and of course, the upcoming RHEL 10 release. To me, the event’s main message was that version 10 is an evolution and not a revolution. In other words, if a piece of software worked on RHEL 9, then there is a very good chance that it will also work on RHEL 10 without any changes. All components were updated to the latest available versions, but there were no groundbreaking changes like the introduction of systemd a decade ago.

Last year, I started experimenting with Alma UBI / RHEL UBI containers for syslog-ng. This year, I plan to keep going and check these containers in a Kubernetes environment. Knowing our users, the obvious choice would be Red Hat OpenShift. Just as testing and developing on CentOS Stream is recommended for those targeting RHEL, OKD is the way to go for those who want to support a new OpenShift version from day one. I plan to start with OKD.

We already test syslog-ng on Fedora Rawhide and CentOS Stream 9 before each commit: https://www.syslog-ng.com/community/b/blog/posts/rolling-rpm-platforms-added-to-the-syslog-ng-package-build-system Creating automatic tests for OKD / OpenShift will be a bit more challenging, but I hope to start testing them at least manually soon.

As an introvert, I easily get people overdose. Luckily, there was a beautiful botanical garden right next to the CentOS Connect venue:

FOSDEM

This year, I presented syslog-ng in the BSD devroom. As I mentioned earlier, I have a special bond with FreeBSD, as I have been using it for the past 31 years. A few months ago, I was at EuroBSDCon, where I was asked if we could add a syslog-ng source for FreeBSD audit logs. I did it as soon as I got back from the conference: https://www.syslog-ng.com/community/b/blog/posts/freebsd-audit-source-for-syslog-ng I presented this effort at FOSDEM and also added some information on how to make it general, that is how to integrate any application output with syslog-ng. After my talk, I had some great discussions with happy users inspired by my syslog-ng talks and one of our contributors. Expect some news about these in the coming months! :-)

Of course, many FOSDEM rooms operated at full capacity and there were quite a few talks which I will watch once their recordings are on-line. I do not want to list individual talks here, just some major takeaways:

• AArch64 packages are available for everything. There was only one project without it, but even they promised to have it utilized in the next few months. Expect some syslog-ng news on this topic… :-)

• Risc-V is getting popular among developers, but it’s still far from being usable for average users.

• Documentation is an integral part of a software release. Without it, a piece of software is useless and not worth releasing. Previously, I only heard this opinion from users and documentation people, so it was good to hear it from developers as well!

• SBOM (Software Bill of Materials) is becoming a hot topic.

• Both admins and developers are now expected to know Kubernetes. Of course, there were some people who complained about it, but for most, it was normal. For me, this means that it’s time to gather some practical semi-production experience about Kubernetes, instead of just simply learning about it… :-)

To summarize both events as simply as possible: I hope to see you again next year! And maybe I’ll also go to Configuration Management Camp…

Table of Contents

• 1) Introduction
• 2) Discovery of the Issue / Relation to GDM Smart Card Authentication
• 3) The PAM_IGNORE Issue in pam_pkcs11
• 4) Affected Distributions and Configurations
• 5) Possible Workaround
• 6) Bugfix
• 7) Lessons Learned
  • On the use of PAM_IGNORE
  • On the use of PAM_SUCCESS
  • Conservative PAM Stack Configuration
• 8) Timeline
• 9) References

1) Introduction

This report is about a regression in pam_pkcs11 version 0.6.12. In this release the implementation of pam_sm_authenticate() has been changed to return PAM_IGNORE in many exit paths, which can lead to a complete authentication bypass in some scenarios. This report is based on upstream Git tag “pam_pkcs11-0.6.12”. A bugfix is found in release 0.6.13.

Whether this issue can be exploited is a complex question that depends a lot on the system configuration. The following section gives some insight into how we discovered the issue and why its severity can be high in some circumstances. Section 3) looks in detail into the issue found in pam_pkcs11. The rest of the report explores which Linux distributions might be affected by the issue, a possible workaround and the upstream bugfix. Finally we will be taking a look at the lessons that can be learned from this finding.

2) Discovery of the Issue / Relation to GDM Smart Card Authentication

Fellow SUSE engineer Marcus Rückert uses a YubiKey for login at his openSUSE Tumbleweed desktop system. In October 2024 he noticed a change in behaviour in his GDM login setup. By digging a bit deeper he noticed that in some situations login was possible without entering a password or using his YubiKey at all.

While analysing the issue we found that there is a bug (or a feature?) in GDM 3 that causes YubiKeys to be treated as smart cards. This is one ingredient that comes into play here. A number of Linux distributions use a dedicated “gdm-smartcard” PAM stack configuration file for smart card login in GDM. On openSUSE we rely on pam_pkcs11 as the sole (proper) authentication module in this gdm-smartcard PAM stack. It took us a while to understand where exactly this gdm-smartcard PAM stack is used in GDM. The logic to select this PAM stack is found in a wholly different Gnome component, namely gnome-shell. There, some JavaScript is responsible for detecting smart cards via the D-Bus interface of the gnome-settings-daemon, and for changing the authentication mode of GDM.

We reproduced the situation by using smart card emulation in a QEMU Virtual machine, to be able to achieve proper smart card detection in both GDM and pam_pkcs11. As soon as the smart card is properly setup in the system, GDM switches into smart card authentication mode (support for this is enabled by default). A user list is no longer shown in the display manager, instead the username has to be entered manually. After entering the username, the “gdm-smartcard” PAM stack is executed, and with it pam_pkcs11. No password is asked for and login succeeds.

What happens in this test setup, as well as in the real life setup using a YubiKey, is that pam_pkcs11 stops execution after logging “Failed to initialize crypto” and, surprisingly, login succeeds. The reason for this lies in pam_pkcs11, as is described in the next section.

We did not investigate why exactly the “initialize crypto” error occurs, as we don’t believe it is relevant for the security issue. Even when errors occur, the outcome of the PAM stack execution shouldn’t allow authentication without providing credentials.

3) The PAM_IGNORE Issue in pam_pkcs11

The successful login without proper authentication in pam_pkcs11 stems from a change that found its way into pam_pkcs11 version 0.6.12. The issue has been introduced with commit bac6cf8 (note that there seems to exist an artifact in the upstream Git repository: a seemingly identical commit 88a87d5 in the commit log on “master”).

With this change, many exit paths of the pam_sm_authenticate() function now return PAM_IGNORE instead of PAM_CRED_INSUFFICIENT. In particular, the code found at line 284 means that the default return value on error conditions is PAM_IGNORE, if there is no “login token name”:

if (!configuration->card_only || !login_token_name) {
    /* Allow to pass to the next module if the auth isn't
       restricted to card only. */
    pkcs11_pam_fail = PAM_IGNORE;
} else {
  pkcs11_pam_fail = PAM_CRED_INSUFFICIENT;
}

The card_only flag refers to a module parameter, whose meaning seems to have changed over time and is no longer fully conforming to what is documented. It is enabled in the “gdm-smartcard” stack, thus this part of the if condition will not trigger. The background of the login_token_name is that the PAM module contains special logic for unlocking the screen saver, but only if the session login was performed using pam_pkcs11. This will always be false during initial login, and thus this part of the if condition applies in this case.

When a PAM module returns PAM_IGNORE, its outcome should not be used to determine the result of the PAM stack execution. openSUSE uses the required control setting for pam_pkcs11 in its “gdm-smartcard” configuration. In extended PAM syntax required is expressed like this:

    required
        [success=ok new_authtok_reqd=ok ignore=ignore default=bad]

When pam_pkcs11 returns PAM_IGNORE then the “required” control setting no longer results in what the average administrator will expect, namely that authentication fails if no successful smart card authentication is possible.

What happens instead depends on the rest of the modules present in the “auth” section on the PAM stack. When no other PAM module at all is on the stack, then authentication fails, because the PAM library expects at least one decisive return value from any module on the stack. When there is another PAM module on the stack that actually authenticates, then that module will set a failed state if no credentials are provided, thereby preventing successful login.

To judge the situation with the “gdm-smartcard” PAM stack, let’s look more closely at its “auth” section:

auth       requisite                   pam_faillock.so      preauth
auth       required                    pam_pkcs11.so        wait_for_card card_only
auth       required                    pam_shells.so
auth       requisite                   pam_nologin.so
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       [success=ok default=1]      pam_gdm.so
auth       optional                    pam_gnome_keyring.so

There are a lot of other modules configured, alas, none of them is actually authenticating. These are what we like to call “utility modules” in this discussion: they provide support functions. Examples are the pam_faillock module which checks whether excess authentication errors occurred, or pam_gnome_keyring which attempts to intercept the cleartext password used for login to transparently unlock the user keyring. Commonly, such modules return PAM_SUCCESS in most situations. As a result, when pam_pkcs11 returns PAM_IGNORE, the overall outcome of the PAM authentication will become PAM_SUCCESS, supplied by non-authenticating modules in the “gdm-smartcard” PAM stack.

Below the code location in pam_sm_authenticate() function shown above, only two code paths return something other than PAM_IGNORE:

• in line 510 if pkcs11_login() fails
• in line 695 if verify_signature() fails

Both return paths will reset pkcs11_pam_fail to a safe PAM_AUTH_ERR value. The following is a list of all the other return paths which will return PAM_IGNORE:

• line 305: if a user is logging in from remote, or can control the DISPLAY environment variable (e.g. in sudo context).
• line 316: if the crypto_init() call fails.
• line 328: if a screen saver context is detected and no login token is recorded, then an explicit jump to a PAM_IGNORE return is performed.
• lines 343, 357: if loading or initializing the PKCS#11 module fails.
• line 374: if the configured token is not found and card_only is not set. This might be okay in light of the semantics of card_only, but it is still strange. If system administrators want to make pam_pkcs11 authentication optional then they can do so by using the PAM stack configuration already, by using the optional control setting. Changing the module result semantics this drastically through a seemingly harmless module option is unusual.
• line 416: if no smart card is found even after potentially waiting for it. If a smart card is found, but one of various PKCS#11 library functions or certificate checks fail, then further PAM_IGNORE returns can happen if any of the following operations fail:
  • open_pkcs11_session() (line 432)
  • get_slot_login_required() (line 443)
  • when reading in a password fails (line 471)
  • empty password was read without nullok set (line 486)
  • get_certificate_list() (line 522)
  • pam_set_item(..., PAM_USER, ...) (line 597)
  • match_user() (line 613)
  • (no matching certificate found) (line 634)
  • get_random_value() (line 663)
  • sign_value() (line 677)
  • close_pkcs11_session() (line 776)

As this long list demonstrates, it is likely that a local attacker will be able to provoke a PAM_IGNORE return value in pam_pkcs11. For a physical attacker the simplest way is to insert an arbitrary smart card into an existing reader, or attach a peripheral smart card device to the system. The pam_pkcs11 module, if configured, will attempt to access the smart card: if the access fails, then the module returns PAM_IGNORE, resulting in a possible authentication bypass.

4) Affected Distributions and Configurations

The issue was introduced in pam_pkcs11 version 0.6.12, released in July 2021. Any PAM stack that relies on pam_pkcs11 as the only authentication factor will be affected by the issue.

On openSUSE Tumbleweed the issue became apparent only due to the mentioned changes in GDM, which cause YubiKeys to be treated as smart cards in some situations. We believe plugging in any kind of mismatching smart card (or YubiKey) on openSUSE Tumbleweed with GDM as a display manager will allow to bypass login.

Similar situations could occur on other Linux distributions if GDM smart card login is enabled and smart cards are autodetected. Even then, an affected “gdm-smartcard” PAM stack still needs to be in place for the issue to trigger. gdm-smartcard PAM stacks relying on pam_pkcs11 are found in the GDM repository for:

• Arch Linux
• Exherbo Linux
• Linux from Scratch

We tried reproducing the issue on Arch Linux. There the gdm-smartcard PAM stack is installed along with GDM, but there is no pam_pkcs11 package in the standard repositories. It can be installed from the AUR, however. When doing so and also installing the gdm and ccid packages, then the issue becomes basically exploitable as well. We only tested this with a crafted sudo PAM stack, though, since we did not manage to get gdm into smart card authentication mode on Arch Linux. It seems some ingredient was still missing to trigger that.

On Arch Linux we also noticed that the AUR pam_pkcs11 package does not place any default “pam_pkcs11.conf” file into /etc. This also avoids the security problem, because when the slot_num setting is left unconfigured to its built-in default value of -1, then pam_sm_authenticate() will return early with PAM_AUTHINFO_UNAVAIL. On openSUSE we do ship a default configuration of slot_num = 0, however.

Current Fedora Linux does not use pam_pkcs11 for smart card authentication anymore (pam_sss is used instead). Older versions of Fedora might still be affected.

5) Possible Workaround

A quick workaround to prevent login bypass is to use the following PAM stack configuration line instead of what is found e.g. in the gdm-smartcard PAM stacks:

auth [success=ok default=bad] pam_pkcs11.so wait_for_card card_only

Instead of using ignore=ignore as seen in the required control setting shown in section 3), the PAM library will consider ignore (actually any other outcome than success) a bad result for the authentication stack. This will cause authentication to fail even if pam_pkcs11 returns PAM_IGNORE.

6) Bugfix

After extensive discussions about the nature of the problem and potential compatibility issues, upstream arrived at a rather straightforward bugfix which is found in commit 2ecba68d40. Basically the PAM_IGNORE return values have been changed into PAM_CRED_INSUFFICIENT again.

This bugfix is part of upstream release 0.6.13, which also fixes another vulnerability in the PAM module, which has been discovered independently.

7) Lessons Learned

We could not find any clear advice in PAM admin or developer documentation regarding the proper use of PAM_IGNORE. Therefore we try to give an overview of the current situation and suggested best practices in this section.

On the use of PAM_IGNORE

As there have been doubts if pam_pkcs11 is to blame for its use of PAM_IGNORE, we made a survey of other PAM modules packaged in openSUSE. We found one PAM module, pam_u2f, that also had problematic uses of PAM_IGNORE in error situations and we published the issue already in a previous report. This report already resulted in a discussion on the oss-security mailing list about possible structural problems when implementing PAM modules.

Apart from this we found the following uses of PAM_IGNORE:

Core PAM Modules

• pam_wheel: this is only kind of a filter module, such that non-root will be denied, while for root it returns PAM_IGNORE; the actual authentication decision is made by other modules.
• pam_sepermit: returns PAM_IGNORE if users are not listed in the configuration file.
• pam_lastlog: uses PAM_IGNORE if the lastlog file (in a privileged location) cannot be read.
• pam_userdb: returns PAM_IGNORE if no database is configured.
• pam_listfile: returns PAM_IGNORE if the user about to login does not match the configured criteria.

Third Party PAM Modules

• pam_google_authenticator: returns PAM_IGNORE if there is no state file and the nullok option is passed the module.
• nss-pam-ldapd: returns PAM_IGNORE if the user is unknown or no auth info is available, but only if explicitly configured to do so (cfg->ignore_authinfo_unavail, cfg->ignore_unknown_user)
• pam_krb5:
  • returns PAM_IGNORE if the user it not known, but only if options->ignore_unknown_principals is set.
  • returns PAM_IGNORE if a minimum_uid is configured and the user doesn’t match that.
• pam_radius: returns PAM_IGNORE if the network is unavailable and ignore has been explicitly configured via the localifdown option.
• pam_yubico: returns PAM_IGNORE if there are no tokens for the user and the nullok option is passed to the module.

As can be seen from this list, most PAM modules only return PAM_IGNORE if there is an explicit opt-in either through a configuration option or a setting in a privileged configuration file. Most of the time the meaning of the return value is that the authentication mechanism is not configured at all, or not configured for the user that is authenticated. Such configurations can only be used in a safe way if the module in question is an optional authentication mechanism, and a fallback PAM module for authentication is present on the stack.

From the issues seen in pam_pkcs11 and pam_u2f we believe it is especially important for PAM module implementations to take care not to use PAM_IGNORE in unclear error situations, since local or physically present attackers might be able to trigger them.

On the use of PAM_SUCCESS

PAM modules that only serve utility functions but do not actually authenticate could consider not returning PAM_SUCCESS but PAM_IGNORE instead. This would avoid unintended successful authentication in a situation like described in this report. It seems natural to PAM module authors to return PAM_SUCCESS if nothing in their module failed, however. A lot of modules work this way and changing them all would be a big effort.

Conservative PAM Stack Configuration

Sadly PAM can be difficult to understand for non-developers and sometimes even for PAM module authors. Even more so admins and integrators should be careful when writing PAM stacks, especially when less common PAM modules are used as the only authentication requirement. Extended PAM syntax like used in our suggested workaround could be used in such situations for hardening purposes, to make sure no unexpected authentication outcomes can occur.

8) Timeline

9) References

• pam_pkcs11 repository
• pam_pkcs11 GitHub Security Issue Discussion and Advisory
• upstream bugfix for the issue
• upstream bugfix release 0.6.13
• problematic gdm-smartcard PAM stack used in openSUSE
• previous blog post about bad PAM_IGNORE use in pam-u2f

Dear Tumbleweed users and hackers,

It seemed like a quiet week to me. Probably people are getting ready to meet up in Brussels for FOSDEM. Make sure to visit the booth area and talk to the people there. We have managed to release 4 snapshots (0124, 0125, 0127, and 0128)

The most relevant changes delivered this week are:

• Mesa 24.3.4
• Mozilla Firefox 134.0.2
• Drop of nscd
• Systemd 257.2
• FWupd 2.0.4+4
• Wine 10.0
• Removal of python 2

The outlook for the future sounds interesting too:

• Meson 1.7.0
• Timezone 2025a
• RPM 4.20: support for declarative build systems. I started playing with this a little bit using meson.
• KDE Plasma 6.3: beta 2 is currently staged
• Change of default LSM from AppArmor to SELinux is progressing, status is tracked at https://bugzilla.opensuse.org/show_bug.cgi?id=1230118.

Tumbleweed remains a strong example of a reliable rolling release as we step into 2025. This month delivered multiple snapshots and a wide range of updates! Two much anticipated major version updates arrived in snapshots this month; GIMP’s release candidate is giving users a good look into the 3.0 version and libvirt 11.0.0 improves virtualization performance, stability and flexibility. KDE Gear 24.12.1 improves app usability and KDE Plasma 6.2.5 brings some additional stability.

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

GIMP 3.0.0~RC2: This makes a major leap to version 3.0 with significant updates and fixes. The build process is streamlined with improved handling of fonts, such as replacing Bitstream Vera with Google Noto Sans and ensuring stability even when fonts are missing. The Python runtime dependencies and enhanced debugging support with libbacktrace ensure smoother builds and better issue resolution. Experimental features like the Lua plugin are now gated for optional use, and Fedora-imported patches improve system monitor profile defaults, external help browser support, and privacy settings. These updates modernize GIMP’s architecture and prepare it for the final 3.0 release.

KDE Gear 24.12.1: Notable updates in this release were made to Dolphin, which improved behavior on X11, fixed thumbnail updates on renaming, and ensured search box initialization fixes. With Itinerary, enhancements for trip group handling were made; there were also improvement made to weather forecasts and it was optimized for crash prevention. Kdenlive addressed timeline issues, fixed crashes, improved layout handling and restored effects presets. KMail improved search functionalities and KPublicTransport enhanced station name recognition.

KDE Plasma 6.2.5: The Discover app store fixes overlapping update descriptions text and kpipewire fixes issues when streaming fails to update. The plasma update also prevents crashes by adding a dummy clipboard. Some screencasting was resolved with KWin. PowerDevil resolves crashes in unloadAllActiveActions and Plasma Networkmanager reverts fixing an issue with the connection speed tab remaining visible after disconnecting.

Rsync 3.4.1: This update brings critical bug fixes and security enhancements. Key updates include improved handling of the -H flag, resolution of a use-after-free issue in rename logging, and removal of the dependency on alloca() in the bundled popt. Security fixes address multiple vulnerabilities such as CVE-2024-12747, which mitigates a race condition in handling symbolic links, as well as CVE-2024-12084 through CVE-2024-12088, tackling heap buffer overflows, information leaks, and directory traversal risks. The update also introduces protocol version 32 and refines developer tools for improved permissions handling.

libvirt 11.0.0: This major release adds VLAN tagging and trunking support for network interfaces on Linux host bridges and enables domains to use advanced tlbflush Hyper-V features. User-defined aliases for devices in domain XML and virtiofs read-only mode are now supported. Enhanced vGPU migration between mdev and SRIOV VF devices is also introduced. Key fixes address transient domain TPM profile crashes, disk image deletion with snapshots, and post-copy migration recovery errors, alongside improvements in domain XML formatting and CPU model support.

libcdio 2.2.0: The library now uses GNU/Linux’s new ioctl with kernel 5.16+ and incorporates GitHub CI checks for better development workflow. Additionally, the update ensures compatibility with widestring APIs and provides better pkg-config detection.

Amarok 3.2.1 & 3.2.2: Amarok introduces Qt6 and KF6 compatibility, enabling support for gpodder, last.fm, and the Wikipedia context applet. The collection can now be filtered by empty tags, and the context view applet for the current track is displayed by default. Key fixes address crashes during file transfers to MTP devices, Ampache logins, and collection filtering. Additional improvements include reduced MTP device query flooding, refined font size limitations in the context view, and enhanced compatibility across compiler and Qt6 versions. Amarok now depends on KDE Frameworks 5.108, marking a step toward modernized builds and better stability.

libxml2 2.13.5: New features include API additions for more reliable malloc failure reporting and context-specific error handlers, such as xmlCtxtSetErrorHandler. The update introduces the XML_PARSE_NO_XXE parser option, enhancing security by disabling external entity loading. Key bug fixes address regressions in xmlIO, xmlreader, and handling of parameter entities. Additionally, significant optimizations ensure better compatibility with modern systems, improved error handling, and support for new configurations. Deprecated features such as HTTP POST support and legacy FTP functionality are gradually being phased out, which reflects a shift toward streamlined and secure XML processing.

Key Package Updates

Kernel Source 6.12.8, 6.12.10 and 6.13.0: The rolling release was one of the first to update to the 6.13 kernel and notable changes for it include a PCI/DPC quirk for PIO log size adjustments on Intel Raptor Lake-P (bsc#1234623). The update also drops a mainline patch for Nouveau backlight control and includes refreshed configurations. Enhanced USB handling, better support for various arm platforms and multiple bug fixes for IIO devices arrived in a previous kernel update. Key changes address vulnerabilities, improve stability and refine hardware compatibility across various subsystems. Version 6.12.8 had enhancements to ALSA and Bluetooth subsystems to address issues like memory leaks and invalid parameter handling. Btrfs received fixes for race conditions and improvements to power supply drivers were made.

btrfs-progs 6.12: This update includes recursive subvolume deletion for accessible subvolumes and the --subvol option in mkfs to create subvolumes with specific properties (read-only, read-write, or default). Other notable improvements include hard link detection in the --rootdir option, refined verbosity in receive and more accurate handling of compressed extents in check. The release also addresses several bugs, such as false positive checksum reports and improper subvolume iteration in rescue clear-ino-cache.

Systemd 257.2: Key updates in this package include improvements to user@.service. Various patches, such as fixes for TPM2 utilities and initrd_prepare behavior, have been integrated upstream. While the testsuite now requires cloning the systemd repository due to upstream changes; efforts are underway to adapt the sub-package.

Mesa 24.3.3: Fixes in this release include resolving rendering issues in Portal 2 and Half-Life 2, addressing crashes in Artifact Classic, and correcting a regression that broke Wayland on RS480M GPUs. Additional updates fix prop disc rendering in X-Plane 12, improve H264/H265 VAAPI encoding on R6700XT with proper QP value handling, and resolve missing text in Age of Mythology Retold on Arc b580 GPUs.

HarfBuzz 10.2.0: Font handling improvements arrive in this package. Unicode Variation Selectors are now considered during “cmap” table subsetting, while malformed UTF-8 strings are better guarded in hb_cairo_glyphs_from_buffer(). Rendering and parsing see significant fixes, including corrected scaling for “COLR” v1 glyphs and locale-independent double number parsing in the hb-subset tool. New APIs enable advanced font table serialization, repacking, and font variation settings conversion.

Coreutils 9.6: This release addresses multiple bug fixes, such as correcting issues in cp, mv, ls and tail, improving reliability and compliance with POSIX standards. Enhancements include new features like CRC32b support in cksum, indexed arguments in printf, and POSIX:2024 string comparison in test. Performance improvements touch key utilities like wc, cksum and sort to ensure faster operations on modern systems.

PHP 8.3.16: This package delivers a wide range of bug fixes and stability improvements across core features and extensions. Enhancements include addressing issues in DatePeriod, SimpleXML and FFI, resolving memory leaks in components like LibXML and Sockets, and improving compliance with standards such as RFC 6890 for IP filtering. Key fixes span vulnerabilities like use-after-free (UAF) in DOM and Iconv, segmentation faults in Gettext and Phar, and overflow issues in Streams. Developers benefit from improved error handling, compatibility updates, and hardened security measures for critical functions like proc_open().

Flatpak 1.16.0: The latest version has new environment variables like FLATPAK_TTY_PROGRESS, FLATPAK_DATA_DIR, and FLATPAK_DOWNLOAD_TMPDIR offer greater flexibility for configuring runtime behavior, such as progress indicators and alternative directory paths. Notable bug fixes include improved handling of dangling symlinks, corrections to introspection annotations in libflatpak, and resolving regressions with Wayland socket handling. Other refinements ensure smoother operation and compatibility, including fixes for terminal progress indicators and the installation of missing test data.

Bug Fixes and Security Updates

Several key security vulnerabilities were addressed this month:

Rsync 3.4.1:

• CVE-2024-12747: Fixed a race condition in handling symbolic links.
• CVE-2024-12084: Resolved a heap buffer overflow in checksum parsing.
• CVE-2024-12085: Fixed an information leak via uninitialized stack contents, defeating ASLR.
• CVE-2024-12086: Addressed server leakage of arbitrary client files.
• CVE-2024-12087: Resolved an issue allowing a server to make clients write files outside the destination directory using symbolic links.
• CVE-2024-12088: Fixed a bypass for --safe-links functionality.

git 2.48.1:

• CVE-2024-50349: Fixed an issue where crafted URLs could inject ANSI escape sequences, potentially misleading users into sending credentials to malicious hosts.
• CVE-2024-52006: Addressed incorrect handling of line endings in credential helpers, preventing credential exposure.

HPLIP:

• CVE-2020-6923: Fixed a memory buffer overflow vulnerability in HPLIP versions 3.20.8 and earlier, which could allow arbitrary code execution or denial of service.

libxml2 2.13.5:

• CVE-2024-40896: Fixed an out-of-bounds read and write vulnerability when processing HEIF files with forged overlay image offsets.

Raptor:

• CVE-2024-57823: Patch added to fix an integer underflow, which could lead to potential vulnerabilities.

Mozilla Firefox 134.0:

• CVE-2025-0244: Address bar spoofing using an invalid protocol scheme on Firefox for Android.
• CVE-2025-0245: Lock screen setting bypass in Firefox Focus for Android.
• CVE-2025-0246: Address bar spoofing using an invalid protocol scheme on Firefox for Android.
• CVE-2025-0237: WebChannel APIs susceptible to confused deputy attack.
• CVE-2025-0238: Use-after-free when breaking lines in text.
• CVE-2025-0239: Alt-Svc ALPN validation failure when redirected.
• CVE-2025-0240: Compartment mismatch when parsing JavaScript JSON module.
• CVE-2025-0241: Memory corruption when using JavaScript Text Segmentation.
• CVE-2025-0242: Memory safety bugs fixed across multiple versions of Firefox and Thunderbird.
• CVE-2025-0243: Memory safety bugs affecting Firefox, Thunderbird, and ESR versions.
• CVE-2025-0247: Memory safety bugs fixed in Firefox 134 and Thunderbird 134.

openssl-3

• CVE-2024-13176: A timing side-channel vulnerability in ECDSA signature computations could allow attackers to recover private keys.

Conclusion

KDE users will appreciate the refined experience offered by the latest KDE Gear and Plasma releases, with improved usability and bug fixes. Under the hood, Tumbleweed continues to receive critical updates, including security enhancements for Rsync and improved XML processing with libxml2. These updates, along with numerous others continue to make Tumbleweed a secure, stable and useful open-source platform.

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.

Behold, My First RPM

I've written tons and tons of software, but was never much for packaging it. If I did any packaging, it was typically sticking a server into a container.

Yesterday morning I realized it has been something like 25 or 30 years since I wrote any functional C code, so I decided to do a refreshing, with the help of some AI. After reviewing the syntax and pointers, I wrote a CLI version of a Python app that I wrote a while back.

Python GUI Version

The problem is that I travel for work, but when I do, openSUSE doesn't seem to pick up on my new timezone, and it was a complex set of commands that I could not remember easily to set the new timezone. So I wrote a little GUI tool.

CLI C Version

So I basically did the same thing, but for the CLI, and in C. I made sure that I understood all of the code as I wrote, that I have to admit, I sort of glossed over the code for iterating through the directories and files.

This version does basically the same thing, but doesn't require the GUI.

Packaging

But wait! There is more. With some more AI assistance, I was able to put up a package that I can install on my machines.

Conclusion

I fully get that there are "official" ways of setting the timezone. The point is that I was able to go from not having written any C code in decades, to having a package in less than 2 hours! I also think my tool is a bit sweeter than timedatectl, etc...

In 2020, the Python foundation declared Python 2 as not maintained anymore.

Python 2 is really old, not maintained and should not be used by anyone in any modern environment, but software is complex and python2 still exists in some modern Linux distributions like Tumbleweed.

The past week the request to delete Python 2 from Tumbleweed was created and is going through the staging process.

The main package keeping Python 2 around for Tumbleweed was Gimp 2, that doesn't depends directly on Python 2, but some of the plugins depends on it. Now that we've Gimp 3 in Tumbleweed, we are able to finally remove it.

Python 2

The first version of Python 2 was released around 2000, so it's now 25 years old. That's not true, because software is a living creature, so as you may know, Python 2 grew during the following years with patch and minor releases until 2020 that was the final release 2.7.18.

But even when it was maintained until 2020, it was deprecated for a long time so everyone "should" have time to migrate to python 3.

Py3K

I started to write python code around the year 2006. I was bored during a summer internship at my third year of computer science, and I decided to learn something new. In the following months / years I heard a lot about the futurist Python 3000, but I didn't worry too much until it was officially released and the migration started to be a thing.

If you have ever write python2 code you will know about some of the main differences with python3:

• print vs print()
• raw_input() vs input()
• unicode() vs str
• ...

Some tools appeared to make it easier to migrate from python2 to python3, and even it was possible to have code compatible with both versions at the same time using the __future__ module.

You should have heard about the six package, 2 * 3 = 6. Maybe the name should be five instead of six, because it was a Python "2 and 3" compatibility library.

Python in Linux command line

When python3 started to be the main python, there were some discussion about how to handle that in different Linux distributions. The /usr/bin/python binary was present and everyone expect that to be python2, so almost everyone decided to keep that relation forever and distribute python3 as /usr/bin/python3, so you can have both installed without conflicts and there's no confusion.

But python is an interpreted language, and if you have python code, you can't tell if it's python2 or python3. The shebang line in the executable python scripts should point to the correct interpreter and that should be enough like #!/usr/bin/python3 will use the python3 interpreter and #!/usr/bin/python will use python2.

But this is not always true, some distributions uses python3 in /usr/bin/python like Archlinux or if you create a virtualenv with python3, the python binary points to the python3 interpreter, so a shebang like #!/usr/bin/python could be something valid for a python3 script.

In any case, the recommended and safest way is to always use python3 binary because that way it'll work correctly "everywhere".

Goodbye

It's time to say goodbye to python2, at least we can remove it now from Tumbleweed. It'll be around for some more time in Leap, but it's the time to let it go.