Table of Contents

• 1) Introduction
• 2) Overview of the Privileged Mount Helper
• 3) Problems in Smb4KMountHelper::mount()
  • 3.1) Arbitrary Target Directories can be used for Mounting Network Shares
  • 3.2) Arbitrary Command Line Arguments can be Passed to mount.cifs
  • 3.3) Clients can Control the KRB5CCNAME Environment Variable Passed To mount.cifs
• 4) Problems in Smb4KMountHelper::unmount()
  • 4.1) Missing return Statement on Mount Path Verification Failure
  • 4.2) Arbitrary Command Line Parameters can be Passed to umount
  • 4.3) Race Conditions Affecting KMountPoint::currentMountPoints()
  • 4.4) Arbitrary Network Share Mounts can be Unmounted
• 5) Other Remarks
  • 5.1) Superfluous mh_command Client Parameter
  • 5.2) Redundant “online check” Code
  • 5.3) mount.cifs and umount Follow Symbolic Links
• 6) Suggested Fixes
• 7) Upstream Bugfix
• 8) Possible Workarounds
• 9) Reproducers
• 10) CVE Assignment
• 11) Coordinated Disclosure
• 12) Timeline
• 13) References

1) Introduction

smb4k is a KDE desktop related utility which allows unprivileged mounting of Samba/CIFS network shares. The SUSE security team reviewed its privileged KAuth helper component already in 2017 which led to the discovery of CVE-2017-8422 (general KAuth authentication bypass) and CVE-2017-8849 (local root exploit via smb4k mount helper).

This September we were asked to reconsider smb4k for inclusion in openSUSE Tumbleweed. The resulting review showed that the mount helper still lacks input validation, is affected by race conditions and has a bug in its existing verification logic. This leads to local attack vectors which allow Denial-of-Service or even a local root exploit.

Many Linux distributions and also some BSDs are potentially affected by the issues described in this report. We offered coordinated disclosure to upstream and the maximum 90 days non-disclosure period was fully spent to arrive at a patch which addresses all the issues. This patch is found in commit 0dea60194a, which is part of the 4.0.5 bugfix release of smb4k.

The following section provides a short overview of the privileged mount helper. Section 3 looks into the problems found in the helper’s mount method. Section 4 in turn looks into the issues found in the helper’s unmount method. Section 5 contains further remarks on the helper’s code quality and security concerns. Section 6 discusses the fixes we suggested to upstream to address the issues. Section 7 gives details about the bugfix which was finally implemented by upstream. Section 8 suggests possible workarounds that can be applied to avoid the issues found in this report. Section 9 provides reproducers for the issues.

This report is based on smb4k release 4.0.4.

2) Overview of the Privileged Mount Helper

The problematic privileged mount helper component of smb4k is relatively small and can be found in the file smb4kmounthelper.cpp. The helper runs with full root privileges and implements two KAuth actions accessible via D-Bus: mounting and unmounting a network share. Both actions are allowed for local users in active sessions without authentication, based on the Polkit yes setting.

3) Problems in Smb4KMountHelper::mount()

3.1) Arbitrary Target Directories can be used for Mounting Network Shares

The helper does not impose any restrictions on the target directory where the desired Samba share will be mounted. This means the share can also be mounted over /bin, for example. Should the client have control over the contents of the network share, then this allows for a local root exploit by placing crafted binaries e.g. for /bin/bash on the share, which are bound to be executed by privileged processes at some point.

If the share’s content cannot be controlled by the attacker, then this serves as a local Denial-of-Service attack vector, as vital system programs will become inaccessible.

To fix this, we suggest to only allow mounting of network shares in a pre-defined location which is not controlled by unprivileged users.

3.2) Arbitrary Command Line Arguments can be Passed to mount.cifs

The client can specify arbitrary additional command line arguments in the mh_options parameter, which will be passed to the mount.cifs program. The command line constructed by the mount helper looks like this:

/sbin/mount.cifs <URL> <mountpoint> <options>...

All of these arguments, except for the path to the mount.cifs program itself, are actually controlled by the client. It is not the generic mount program which is invoked here, otherwise the client could already perform arbitrary mounts in the system. Instead the attacker is restricted to what the special-purpose mount.cifs binary provides.

The mount.cifs program supports a plethora of mount options. Investigating the effect of each one would go beyond the scope of this report. There is one simple privilege escalation vector, however: passing filemode=04777,uid=0 to the command line results in every file on the network share mount receiving setuid-root permissions. If the content of the network share is controlled by the attacker, then this can easily be used to introduce an attacker-controlled setuid-root program into the system. This would then allow for a local root exploit even if issue 3.1) would be fixed.

Other mount.cifs options like port=<port> could be used to direct the kernel to a CIFS server controlled by the attacker itself, listening on an unprivileged port on localhost. This way a local attacker could provide the necessary crafted network share for executing the exploits described in this report on its own, without relying on external network resources.

To fix this, we suggest to restrict the mh_options to a whitelist of allowed parameters, and also verify the options’ values in case they can contain problematic settings.

3.3) Clients can Control the KRB5CCNAME Environment Variable Passed To mount.cifs

The client can provide an arbitrary path in the mh_krb5ticket parameter; the mount helper will place this path into the KRB5CCNAME environment variable for the mount.cifs child process. This is to allow use of the client’s Kerberos credentials for mounting the network share.

The client can pass a path pointing to file system locations normally not accessible to it. In a multi-user scenario this would allow, for example, to hijack another user’s Kerberos credentials, by passing a path to the credentials cache of the other user. It might also lead to information leaks of files like /etc/shadow, should mount.cifs output file content to the system logs or on stderr (the output of which is returned to the client via D-Bus).

Furthermore, this path could be used for file existence tests or for a local Denial-of-Service attack (by pointing to special files like /dev/zero or a named FIFO pipe).

To fix this, we recommend not to pass a path, but an already open file descriptor from the client to the helper, to avoid the opening of arbitrary files with root privileges.

4) Problems in Smb4KMountHelper::unmount()

4.1) Missing return Statement on Mount Path Verification Failure

This is similar to issue 3.1) above regarding mounting. In smb4kmounthelper.cpp line 177 there is an if block that acts on the situation when the mh_mountpoint path supplied by the client does not match any of the available Samba mounts returned from KMountPoint::currentMountPoints().

The problem is that this if block only sets an error message, but does not actually terminate the function execution with return. This means the verification is ineffective and local users can unmount arbitrary file systems despite the check.

This is a major local Denial-of-Service attack vector, which can lead to a complete system outage. In some special contexts it might even allow information leaks or privilege escalation, when file system locations have been made inaccessible by mounting other file systems on top (we can imagine something like this e.g. in the context of container setups).

4.2) Arbitrary Command Line Parameters can be Passed to umount

Similar to issue 3.2) above, the privileged helper forwards arbitrary command line parameters provided by the client in mh_options to the command line of the umount program. This happens in smb4kmounthelper.cpp line 187. Basically the umount program will be invoked like this:

/sbin/umount <options>... <mount-point>

Assuming issue 4.1) would be fixed, the <mount-point> parameter cannot be chosen arbitrarily by the client, but must match an existing “cifs”, “smbfs” or “smb3” type mount path. As long as such a mount path exists, the client can pass arbitrary additional mount points as “options”, which will then be unmounted as well. This is a lighter variant of issue 4.1), leading to local Denial-of-Service if the described pre-condition is fulfilled.

Apart from this, umount offers various options that can influence the way it operates. One option that sticks out is -N --namespace ns, which causes the program to unmount the file system in an arbitrary mount namespace. This could impact privileged processes, other users’ containers or jailed processes.

To fix this, we suggest to restrict the mh_options to a whitelist of allowed parameters.

4.3) Race Conditions Affecting KMountPoint::currentMountPoints()

This is not directly an issue in smb4k itself, but an issue in the KIO library which implements the KMountPoint API. During our tests we used version v6.17.0 of this library.

The mount helper’s umount() function attempts to verify the input path provided by the client by comparing it against current mounts in the system as reported by the kernel. Only active “cifs”, “smbfs” and “smb3” file system mounts are supposed to be unmounted. To this end the current list of mounted file systems is obtained from

    KMountPoint::currentMountPoints(KMountPoint::BasicInfoNeeded | KMountPoint::NeedMountOptions);

The implementation of currentMountPoints() relies on the libmount library to retrieve a list of mount points. The libmount library provides a proven implementation for safely parsing files like /proc/self/mountinfo, which we reviewed ourselves a few years ago and deemed robust. After safely obtaining the information from libmount, the KIO library performs some actions on top, however, which can lead to security relevant issues.

One minor issue is found in kmountpoint.cpp line 365, where stat() is called on the target mount directory of each mount entry. This potentially accesses untrusted paths, also from FUSE file systems, which could in some cases cause a local Denial-of-Service if stat() blocks. Also, the supposed mount point could be unmounted by the time the stat() call is performed, allowing the path to point to an arbitrary file (also following symbolic links), which would lead to incorrect information in the m_deviceID field of the information returned by currentMountPoints().

Later on the code tries to “resolve GVFS mount points” in line 382. The resolveGvfsMountPoints() function that implements this logic looks for mount entries with “gvfsd-fuse” as source device name. For each of these mount points the function will list the mount’s directory contents and look for directory entries of the form <type>:<label>, where type refers to the file system type that is expected to be found there. The function then synthesizes additional mount entries from this information which will be returned to the caller, appearing as fully-fledged regular mounts.

There are two problems with this. For one, these operations are all subject to race conditions; the mount table entries can change at any time. Secondly, there exists a common way for unprivileged users in Linux systems to create mount points with arbitrary source device names. This is the fusermount setuid-root utility, which is used for mounting FUSE file systems. Local users can create a fake gvfsd-fuse mount point like this:

    $ export _FUSE_COMMFD=0
    $ mkdir $HOME/mnt
    $ fusermount $HOME/mnt -ononempty,fsname=gvfsd-fuse
    $ mount | tail -n1
    gvfsd-fuse on /home/$USER/mnt type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)

The default FUSE configuration prevents the root user from accessing non-root controlled FUSE file systems. To overcome this limitation, an attacker can perform the following steps:

• create a fake gvfsd-fuse mount like shown above.
• trigger the unmount() logic in smb4k’s mount helper.
• attempt to unmount $HOME/mnt after currentMountPoints() obtained the mount information from libmount, but before it calls resolveGvfsMountPoints().
• place directories in this location that match the expected format e.g. something like cifs:mymount. These directories can already be placed there in advance, of course.
• on success, the currentMountPoints() function will return a synthesized entry to the mount helper which lists a CIFS mount in the unprivileged user’s $HOME/mnt/cifs:mymount.

Using this approach, the verification step in the mount helper’s unmount() function can be bypassed even if issues 4.1) and 4.2) would be fixed.

There are further potential issues in the KMountPoint logic, e.g. in finalizeCurrentMountPoint() the source device name is resolved if the KMountPoint::NeedRealDeviceName flag is passed by the caller. This provides another opportunity for unprivileged FUSE mounts with fake source device names to influence the outcome, e.g. to perform file existence tests or otherwise trick the caller of the KIO library.

Due to these problems, the information obtained from currentMountPoints() currently cannot be used to base security related decisions on. Generally root should not perform these additional queries at all. The library could check for geteuid() == 0 to prevent the execution of this dangerous logic in privileged contexts.

For unprivileged applications we could imagine the addition of a flag like KMountPoint::AllowUnsafe, which opts in to the problematic behaviour. Only applications that are aware of the potential problems would then pass this flag.

When we reported this, KDE security at first stated that the problems described in this section would only affect smb4k and no other users of the KMountPoint API. We found it questionable to consider a library’s API secure only based on its supposed current users. Beyond that, even unprivileged processes using this API might fall victim to other users in the system crafting gvfsd mount information. One could argue that there is an issue in the fusermount utility to begin with. The KMountPoint API is explicitly processing a FUSE-based file system, however, and thus it should be prepared to deal with the peculiarities this entails.

When we pointed out our continued concern to KDE security, it was suggested that we create an upstream issue, or ideally provide a bugfix ourselves. While we are happy to help where we can, the issue at hand is a larger API design topic, and we believe it should be dealt with carefully by the responsible upstream developers, allowing them also to learn from this experience. For this reason we only created the upstream issue, as was suggested to us.

4.4) Arbitrary Network Share Mounts can be Unmounted

Even if all the other issues discussed in this section would be fixed, the current mount helper code allows to unmount arbitrary Samba shares, no matter if they have been originally mounted by smb4k itself (for the same user or a different one), or by other components in the system (e.g. via a fixed entry in /etc/fstab).

Similarly to issue 3.1) above, we suggest to restrict smb4k mounts to a pre-defined location not controlled by unprivileged users to address this issue.

5) Other Remarks

5.1) Superfluous mh_command Client Parameter

Both helper actions compare an arbitrary path supplied by the client in mh_command to the trusted “mount” or “unmount” program path returned from findMountExecutable() or findUmountExecutable(), respectively. This is odd. It seems this comparison is a remnant from the attempted fix of CVE-2017-8849. This is superfluous logic that increases the complexity of both client and helper unnecessarily and can cause confusion, at best.

The helper should choose the trusted mount program on its own and stop considering the mh_command parameter at all.

5.2) Redundant “online check” Code

There is a redundant check for online network interfaces in smb4kmounthelper.cpp line 38 and line 205. This code should be placed into a separate function instead, to avoid code duplication and to increase readability.

This online check is also highly heuristic, and it might be possible for unprivileged users to influence its outcome e.g. by creating unprivileged pseudo network devices that appear to be online.

5.3) mount.cifs and umount Follow Symbolic Links

Both mount.cifs and umount follow symbolic links in path arguments. This means that even if the mount helper would try to verify a path pointing to a client-controlled location, this could be replaced with a symbolic link by the time the actual mount.cifs or umount utility runs, and the mount logic would then operate on a completely different location than expected by the helper.

6) Suggested Fixes

Apart from the individual suggestions mentioned in the context of the issues above, we believe the range and severity of the issues uncovered shows that a major redesign of the mount helper utility is necessary to address all the problems in a robust way.

Here are some suggestions regarding a larger redesign:

• the helper should not allow mounting or unmounting of user provided paths at all. A dedicated directory like /mounts/smb4k, only controlled by root, should be used for these purposes. Some form of tracking which mount belongs to which user would be needed (e.g. giving ownership of the mount to the client that requested it). This is more like udisks solves the problem of mounting devices on user request.
• passing through arbitrary parameters from unprivileged clients to mount.cifs or umount won’t work securely. A more abstract interface with well-defined settings for mounting or unmounting would help to restrict the degrees of freedom that a client has. This would also improve the decoupling of the helper’s interface from the concrete implementation, this way the helper could e.g. change the implementation to call the mount() and umount() system calls directly, instead of going through the mount utilities.

7) Upstream Bugfix

During the course of a month we discussed various versions of patches with the smb4k upstream developer, until we arrived at a workable patch just in time for publication of this report after the 90 days maximum embargo period we offered. The main aspects of the bugfix are as follows:

• For mount and unmount the options passed by the client are now more closely scrutinized, and only settings present in a whitelist of options are allowed anymore.
• The filemode mount option, which is still basically supported, is now checked to make sure no special file bits are present.
• The uid and gid mount options can only be set to the UID/GID of the caller, not to arbitrary IDs anymore.
• Network share mounts are now restricted to a directory hierarchy rooted in /run/smb4k. This way, unprivileged users can no longer place symlinks in the mount destination paths. Mounts are placed in per-UID subdirectories such that different clients cannot influence each other’s mounts anymore.
• For passing Kerberos credentials, clients now pass already open file descriptors to the mount helper, thereby avoiding any issues with regards to operating on untrusted paths.
• The problematic KMountPoint API is no longer used and has been replaced by Qt’s QStorageInfo API. Formally the investigation of existing mount points would no longer be necessary at all with the trusted mount tree location, but the upstream developer preferred to keep this extra verification step for the time being.

We want to express our thanks to Alexander Reinholdt, the smb4k upstream developer, for cooperating with us and finishing the patch in time for publication. This way a series of long-standing issues in smb4k could finally be addressed.

8) Possible Workarounds

If the upstream bugfix cannot be used right away, the following suggestions can be considered to remove the attack surface described in this report:

• Raise the Polkit authentication requirements for the mount and unmount helper actions to auth_admin. This way the problematic logic can only be reached by already privileged users. This contradicts the original purpose of smb4k, however, to allow unprivileged mounts and unmounts of network shares.
• Restrict D-Bus access to the mount helper utility to members of an opt-in group like smb4k. Coupled with a security disclaimer, this would allow users that really want to use this feature to opt-in.

9) Reproducers

The KAuth D-Bus interface cannot easily be invoked via utilities like gdbus, because it expects a serialized QVariantMap as input. We offer two C++ programs which can be used to perform standalone tests of smb4k’s mount helper API for the purposes of reproducing the attack vectors described in this report, smb4k_mount.cpp and smb4k_unmount.cpp. There are comments in the source code of the reproducers that explain how to compile and use them.

10) CVE Assignment

Formally the findings in this report could justify a large count of CVEs, but we decided to condense them into the two main aspects that result from the issues:

• CVE-2025-66002: local users can perform arbitrary unmounts via the smb4k mount helper due to lack of input validation.
• CVE-2025-66003: local users can perform a local root exploit via the smb4k mount helper if they can access and control the contents of a Samba network share.

When the end of the 90 days maximum non-disclosure period we offered upstream approached, due to lack of feedback from KDE Security, we assigned these CVEs as we originally suggested them to upstream.

11) Coordinated Disclosure

We reached out to KDE security on September 11 and shared the full details about the issues described in this report, offering coordinated disclosure. For nearly the first two months of the maximum 90 days non-disclosure period, we had difficulties getting clear answers from KDE security about the expected publication date, whether they acknowledged the findings or even whether they wanted to practice coordinated disclosure at all.

We only saw some visible progress at the beginning of November, when the smb4k upstream developer joined the discussion and started developing bugfixes. The progress remained slow, however, due to limited resources on the end of the developer. Still, from this point onwards the discussion turned out helpful and cooperative, and we could finally see that the non-disclosure time was actually being put to use. We managed to agree on a bugfix that addresses all the issues only less than a week before the 90 days maximum embargo period would be reached.

In summary, we are not completely happy about how the coordinated disclosure developed in this case. We perceived an unwillingness on the end of KDE security to communicate and to help in coordinating the disclosure. We believe the issue could have been fixed faster by suggesting a workaround to users and by developing a bugfix in the open, with the help of the rest of the community.

12) Timeline

13) References

• smb4k KDE Project
• smb4k 4.05 bugfix release
• upstream bugfix for the issues in this report
• SUSE Bugzilla review bug for smb4k
• Bug report against the KIO library regarding KMountPoint API issues

A decade has passed since Yogyakarta proudly hosted the first openSUSE.Asia Summit in Indonesia — and in 2026, we are returning to where the excitement first flourished.

Indonesia has a special place in the history of the summit:

• In 2016, Indonesia hosted its first openSUSE.Asia Summit in Yogyakarta
• In 2019, the summit was successfully held again in Bali, offering a memorable community celebration

For a glimpse of the excitement from the 2016 summit in Yogyakarta, you can watch this short video recap on Youtube

We are thrilled to announce that the openSUSE.Asia Summit 2026 will take place in Yogyakarta, the cultural heartbeat of Indonesia. The summit is an annual gathering for openSUSE users, contributors, and FLOSS enthusiasts from across the region. It serves as a platform for collaboration, learning, and sharing experiences about openSUSE and the broader open-source ecosystem.

Yogyakarta, often called the City of Students, is home to dozens of universities and vibrant tech communities. Its young talent and strong academic environment foster innovation and open-source adoption. Beyond education and technology, Yogyakarta is also a living center of heritage — with its royal palace, traditional arts, and world-renowned landmarks such as the temples of Borobudur and Prambanan located nearby. The charm of its cultural richness blends seamlessly with modern creativity and digital progress.

Visitors will not only participate in inspiring sessions, workshops, and community activities — but also experience warm local hospitality, unique cuisine, and a rich artistic atmosphere that makes Yogyakarta unforgettable.

The summit is expected to take place on 3–4 October 2026. Call for speakers is planned to close by the end of June 2026. More information, including venue details, will follow soon — stay tuned for upcoming announcements!

We look forward to welcoming you to Yogyakarta and celebrating openSUSE together once again. See you in Indonesia! 🦎🌏

Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false. So let’s go into how this all works in detail.

One of the new additions to the GNOME 49 wallpaper set is Dithered Sun by Tobias. It uses dithering not as a technical workaround for color banding, but as an artistic device.

Tobias initially planned to use Halftone — a great example of a GNOME app with a focused scope and a pleasantly streamlined experience. However, I suggested that a custom dithering method and finer control over color depth would help execute the idea better. A long time ago, Hans Peter Jensen responded to my request for arbitrary color-depth dithering in GIMP by writing a custom GEGL op.

Now, since the younger generation may be understandably intimidated by GIMP’s somewhat… vintage interface, I promised to write a short guide on how to process your images to get a nice ordered dither pattern without going overboard on reducing colors. And with only a bit of time passing since the amazing GUADEC in Brescia, I’m finally delivering on that promise. Better late than later.

I’ve historically used the GEGL dithering operation to work around potential color banding on lower-quality displays. In Tobias’ wallpaper, though, the dithering is a core element of the artwork itself. While it can cause issues when scaling (filtering can introduce moiré patterns), there’s a real beauty to the structured patterns of Bayer dithering.

You will find the GEGL Op in Color > Dither menu. The filter/op parameters don’t allow you to set the number of colors directly—only the per-channel color depth (in bits). For full-color dithers I tend to use 12-bit. I personally like the Bayer ordered dither, though there are plenty of algorithms to choose from, and depending on your artwork, another might suit you better. I usually save my preferred settings as a preset for easier recall next time (find Presets at the top of the dialog).

Happy dithering!

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

The below featured highlights listed on the community’s blog feed aggregator are from Nov. 29 to Dec. 6.

Blog posts this week highlight a broad mix of community work, from KDE Plasma enhancements and mobile updates to local-AI home projects, syslog-ng Kafka testing, mutation testing in librsvg, news from the Fediverse, FSF, SUSE’s Mobile Hackday and defense even contractors trying to block right to repair.

Here is a summary and links for each post:

Plasma Mobile 6.5 Released

The KDE Blog announces the release of Plasma Mobile 6.5 with several refinements to KDE’s mobile experience. This version adds native Waydroid setup support, making Android app integration easier for users. It also improves the lock screen, notifications, quick settings, and introduces early support for a new virtual keyboard.

Better Hardware Support — This Week in Plasma

The KDE Blog highlights several user-interface refinements and bug fixes for hardware like drawing tablets, printers, and monitors in this week’s update. Changes in Plasma 6.6 let you Alt-click or double-click desktop items to view their properties. Other improvements include clearer driver-missing warnings for tablets, a cancel button in snapshot selection overlays, and various fixes for screen-locking, multi-monitor setups, and system-tray behaviour.

openSUSE Tumbleweed – Review of the Week 49, 2025

Victorhck and DimStar reported on the week’s snapshot for Tumbleweed brings updates including GDM 49.2, libproxy 0.5.12, and XOrg Server 21.1.21. A problematic upgrade to systemd 258 caused significant issues in automated testing that resulted in a snapshot being set aside for more testing and a reversion of a version for a deeper dive into the diagnostics. Upcoming snapshots may include major package updates like Mozilla Firefox 145.0.2, kernel 6.18.0, Mesa 25.3.1, SQLite 3.51.1, and others.

Ragging My Brain – a quick thought dive

A personal blog post by Timo reflects on a detailed experiment with Retrieval-Augmented Generation (RAG) using local LLMs (qwen3-coder, qwen3-embedding) via Ollama. The author built a RAG system on a personal desktop, added features with LLM assistance, created a web interface, and reflects on the challenges of prompting and code quality in AI-assisted development.

LOUVRE: The Art of Cybersecurity — Compilando Podcast

The KDE Blog shares a new short-episode (64) of Compilando Podcast titled “LOUVRE: The Art of Cybersecurity,” inviting reflection on digital security as more than technique. The episode draws an analogy between cybersecurity and art: protecting systems requires not only skill, but also sensitivity, awareness, and a culture of care.

Redmine RAG system

This blog post from Zoltán describes another Retrieval-Augmented Generation personal project where the author extracted all issues from a Redmine instance (including comments) and anonymized the data to build a local ChromaDB-backed RAG system for semantic search and Q&A. The pipeline includes robust error-handling, checkpointing, and retry logic to reliably download tens of thousands of issues, then optionally transform them into embeddings via Ollama for high-quality semantic search. The result is a fully offline, privacy-conscious RAG stack that lets users query historic Redmine data with natural-language queries.

Fediverse and Non-Proprietary Social Networks #Vamonosjuntas

The KDE Blog highlights a talk by David Marzal about the importance of joining the Fediverse, which is a community of decentralized, non-proprietary social networks. The post argues that by using federated networks, people can escape toxic, profit-driven social media and help build a freer, more collaborative internet.

I want to have a hot shower – From Tesseract Troubles to Local VLM

Zoltán describes how he turned a simple 300-liter hot-water heater into a smart, sensor-driven system using a cheap USB webcam, a tiny computer (Raspberry Pi), and a relay switch, so he can monitor and control water heating more efficiently. After struggling with unreliable optical-character recognition (OCR) via Tesseract, he switched to a local vision–language model (VLM) setup via Ollama for reading the boiler’s display, which improved reliability without sending data to the cloud.

Last Two Weeks in KDE Apps – Performance improvements in Krita, Trust and Safety in NeoChat, and file actions in Photos

The KDE Blog reports on recent enhancements across several KDE apps. Some of the performance optimizations were made to Krita, trust and safety improvements in NeoChat, and improved file-handling actions in KDE Photos. The update also highlights ongoing fundraising efforts for the KDE project.

Free Software Foundation News Roundup – December 2025

Victorhck aggregates selected stories from the December 2025 issue of the Free Software Foundation (FSF) newsletter, which marks 40 years since the foundation’s creation. It highlights calls from the Free Software Foundation Europe (FSFE) urging that Germany’s “Germany Stack” public-software initiative be built entirely with free software for genuine digital sovereignty. The roundup also draws attention to global issues, including contractors trying to shoot down US military “right to repair” rules and a major worldwide outage caused by Cloudflare.

Congress esLibre 2026 in Melide

The KDE Blog announces that esLibre 2026 will take place in Melide (Spain) on April 17–18. The event will feature talks, workshops, community-led sessions and exhibitions, hosted at the Centro Sociocultural Mingos de Pita and the adjoining Multiuso building. Attendance is free, but you need to register to participate.

syslog-ng: How to Test Kafka Source by Building the Package Yourself

Peter ‘CzP’ Czanik walks through the testing the upcoming syslog-ng Kafka source by cloning the repo, applying PR #5564 as a patch, building RPM/DEB packages with DBLD, installing them, and configuring syslog-ng to consume from Kafka.

Intel NPU Driver Now Available in openSUSE Versions

The openSUSE Innovator initiative has packaged the driver for Intel’s built-in Neural Processing Unit (NPU), which enables users to run inference workloads, generative-AI tasks, or neural-network workloads without needing a dedicated GPU. The driver supports recent Intel CPUs (like the Core Ultra family) and allows efficient, low-power AI workloads directly on the CPU die.

Mutation testing for librsvg

Federico’s Blog blog post describes how he applied mutation testing to librsvg, which is a popular SVG-rendering library, using cargo‑mutants. He reports that after running thousands of code mutations, hundreds of them (889) were “missed” by the existing test suite. The write-up explains how to run cargo-mutants on a Rust workspace and encourages improving tests (or using mutation testing in CI) to catch such blind spots.

The death of an iPod

Victorhck reflects on the end of their use of an iPod and describes how the device has finally “died.” The article evokes memories about owning and using the iPod, and contemplates how technological progress and streaming services have changed the way we interact with music.

Tumbleweed Monthly Update – November 2025

The openSUSE project reports that November brought a steady cadence of updates to openSUSE Tumbleweed. Key highlights include updates to Plasma 6.5.3 and KDE Gear 25.08.3 for improved desktop stability; GNOME 49.2 for smoother session handling; as well as kernel 6.17.9, Mesa 25.3.0 and PipeWire 1.5.83 to enhance graphics, audio, and hardware support.

App improvements in Plasma 6.5

The KDE Blog describes notable enhancements in many of the apps bundled with KDE Plasma 6.5. The update improves the performance and responsiveness of the software manager Discover as it now launches faster, handles Flatpak + HTTPS URLs, and can show hardware drivers available for installation.

Geekos Japan Blog Post – ribbon/3582

This blog post on the Geeko.jp site talks about Leap 15.6 and about changing settings to receive certain control sequences of the cursor.

4th Linux Mobile Hackday at SUSE Prague

SUSE reports on the fourth edition of Linux Mobile Hackday held in Prague on November 29. Attendees experimented with running Linux on various phones, worked on kernel/device-tree support, reviewed patches, and explored packaging tools for mobile Linux distributions.

openSUSE Tumbleweed – Review of Weeks 47 & 48, 2025

Victorhck covers more than two weeks of Tumbleweed with key updates include Mesa 25.2.7/25.3.0, Linux kernel 6.17.8/6.17.9 (with efidrm and vesadrm enabled), KDE Plasma 6.5.3, Mozilla Firefox 145.0, GNOME 49.2, PipeWire 1.5.83, GStreamer 1.26.8, fwupd 2.0.17, and many core libraries like cURL, Freetype and Samba.

My Plasma Desktop – November 2025 ViernesDeEscritorio

The KDE Blog showcases the author’s personal desktop setup using Plasma in November 2025, as part of their ViernesDeEscritorio (“Friday Desktop”) series. The post highlights their choice of wallpaper, icon theme, plasmoids and overall layout.

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

It’s been almost 2 full years since Linux became a CNA (Certificate Numbering Authority) which meant that we (i.e. the kernel.org community) are now responsible for issuing all CVEs for the Linux kernel. During this time, we’ve become one of the largest creators of CVEs by quantity, going from nothing to number 3 in 2024 to number 1 in 2025. Naturally, this has caused some questions about how we are both doing all of this work, and how people can keep track of it.

Dear Tumbleweed users and hackers,

This week, we have seen only a single snapshot (1127) published, which landed just before the start of HackWeek.

Since then, a few issues have piled up, blocking further releases. First, the update to ICU 78 caused libqt5-qtwebengine the build to fail. Because this package is present on nearly 100% of systems (specifically those installed before the new opensuse-welcome), we could not consider releasing it in that state.

We also encountered significant friction with systemd 258, which triggered several complex issues in openQA. While we have set that update aside for deep diagnostics, we decided to revert to the already shipped version for the immediate future. This specific move should unblock Tumbleweed and get the snapshots rolling again.

Naturally, HackWeek 25 has also played a role here. With many contributors focusing on side projects, resources for regular maintenance have been kept to a minimum.

Snapshot 1127 contained these changes:

• GDM 49.2
• libproxy 0.5.12
• XOrg server 21.1.21

The future will bring you these changes sooner or later:

• Mozilla Firefox 145.0.2
• Bash 5.3.8
• Linux kernel 6.18.0
• PostgreSQL 18.1
• SQLite 3.51.1
• Mesa 25.3.1
• Ruby 4.0 (early preview staged to find out what all breaks)

As part of HackWeek, Santiago has tirelessly improved the test coverage for “Tumbleweed installed using Agama.” We plan to expand this further and minimize the gap between the legacy installer and Agama, with a priority on NET installations.

The Idea

My original idea was to study how to RAG (Retrieval-Augmented Generation) an LLM model by inserting something potentially useful to it.

I chose qwen3-coder as my language model, and qwen3-embedding as my embedding model, both easily available via Ollama.

My current work laptop is not powerful enough for any of this work, so I used my personal desktop computer for the testing, with AMD’s ROCm containers.

In Practice

The LLM vibes brought me to learn a couple of things. First of all, after searching for a couple of alternatives, I found a simple MIT licensed ragging demo to start experimenting with. I changed it to use my local, already downloaded models and cut off the network access to my container. Since I’m pulling all kinds of dependencies from the Internet, I like to both use a container in the first place and also not have the container access network to make sure it’s both safe and provably functional without network.

I realized that I can also experiment with the local Ollama qwen3-coder for the coding part of the RAG at the same time, and used its help to implement a couple of new features - I stored the accumulated vector database into a file, added chat functionality instead of one query, support for “compressing” the history to fit within context window, and even some tests. I found this experience initially quite good, since I didn’t have previous experience on this topic it really helped me with the examples. The problem is mostly the amount of code it generates that needs to be reviewed if it makes any sense or not, but all in all I couldn’t have achieved the same in the same time, because reading documentation and trial and error would have taken more time. Arguably the technical debt is something that offsets any time savings, but for this kind of experimental study purposes, doing something someone else has already done before, it worked well to get quick results.

My 400kB amount of scripts led to a vector database of 440MB in size 🤔 It’ll be interesting how it will be for example if I put 10x of data in, will the database keep on increasing in size in proportion to that?

How’s the actual usage? Well, it does retrieve correctly my knowledge from my own scripts, but OTOH I’m not sure if I’m able to find (old, forgotten) things with this any faster than with grep. I’ll try to integrate this however to my usage so that at some point this is another query feature similar to grep. For that though, I need to accumulate more data to feed to it.

I also added a web interface so that within home network I can query it from a browser.

I Need Moooore AI

I was also looking at moving to ChromaDB for the vector storage. I thought to try OpenCode at the same time, still paired with the qwen3-coder. Oh what an agentic mess it became! It started configuring my already-configured git with its own user name, fetching all kinds of stuff, and committing bloated things that were clearly broken. But, it did all that locally, which is kind of neat.

Some of the end result can be seen at my testing git repo.

At the End

It has been an interesting experiment with ups and downs of LLM usage. I’ve learned things fast at first, but then I’ve already grown hating the need to practice the “art” of prompting and getting to the “maybe next prompt will fix it” phase of developing things.

The Goal

The goal was to extract all issues from a Redmine instance, anonymize the data, and build a local RAG system for semantic search and Q&A.

Just like with the previous experiment with Bugzilla it started with data extraction. I planned to make a simple bulk download via Redmine API. Then came the first problem. Redmine’s API doesn’t return journal entries (comments) when using the project-level endpoint, even with the include=journals parameter. I tried out different ways but nothing worked. The solution was, after all, to change the strategy and fetch each issue individually via /issues/{id}.json. This was much slower but guaranteed complete data including all comments.