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

Me alegra compartir con todos vosotros la cuarta actualización de Plasma 6.5, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Cuarta actualización de Plasma 6.5

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 9 de diciembre de 2025, casi dos meses después de liberar el código de Plasma 6.5 la Comunidad KDE presenta su cuarta actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.5

Aprovecho para realizar un listado de las novedades generales de Plasma 6.5:

• Cambio automático entre tema claro y oscuro
• Paneles desplazables para widgets y accesos
• Nuevo asistente de configuración inicial (KISS)
• Almacenamiento global de contraseñas Wi-Fi
• Mejoras de rendimiento en KWin al reproducir vídeo
• Configuración de diales en tabletas de dibujo
• Mejoras en la gestión de colores para monitores HDR
• Uso de la tecla Enter en las acciones de apagado del menú Kickoff
• Filtro de accesibilidad para escala de grises
• Ajustes visuales con bordes redondeados en menús

Más información: KDE

La entrada Cuarta actualización de Plasma 6.5 se publicó primero en KDE Blog.

Utilizo Plasma de KDE y todo su ecosistema desde hace más de 15 años y en este tiempo he encontrado un software y una comunidad que siguen haciendo mi uso de la informática cómodo, atractivo visualmente y sobre todo libre.

La comunidad de KDE me ha ofrecido a mi y a miles de usuarios en todo el mundo, las herramientas necesarias para mantenernos libres y aún así poder presumir de un entorno de escritorio funcional y bonito.

Un ecosistema lleno de aplicaciones útiles y funcionales y un entorno de escritorio llamado Plasma repleto de funcionalidades y estilo que es la tendencia de otros sistemas operativos privativos (sí Microsoft, te estoy mirando a tí).

El próximo año 2026 KDE cumplirá 30 años, y Kai Uwe ha compartido en su blog 30 razones por las que a él Plasma de KDE le ha robado el corazón. Tienes el artículo original en inglés publicado bajo licencia CC-by-sa en este enlace:

• https://blog.broulik.de/2025/12/30-reasons-i-love-kde-plasma/

Me han parecido unas grandes razones con las que coindía por completo, así que he querido traducirlas y compartirlas en mi blog. Seguro que tu también coincides en gran parte con muchas de estas razones y quizás descubras algunas que no sabías.

Entre paréntesis y cursiva he añadido, cuando lo he creído conveniente, algún comentario propio sobre la razón en cuestión.

1. Cuando suspendo mi portátil, cualquier video o música deja de reproducirse
2. Puedo usar tres dedos en mi panel táctil para cambiar de escritorio virtual
3. Recibo una notificación cuando mi mouse inalámbrico está a punto de quedarse sin energía
4. Puedo hacer clic con el botón central en una ventana en la barra de tareas para cerrarla
5. Puedo tener una nota adhesiva en mi panel para usarla como bloc de notas
6. Puedo hacer clic con el botón central en el icono de notificación para activar el modo «no molestar»
7. Hay un pequeño y práctico plasmoide de selección de color para mi panel.
8. Puedo colocar el cursor en la esquina de la pantalla para echar un vistazo a mi escritorio
9. Puedo mantener cualquier ventana siempre arriba cuando lo necesito
10. Puedo crear un código QR de cualquier cosa que copie en mi portapapeles
11. Cuando tomo una captura de pantalla, puedo arrastrarla a donde la necesito
12. Puedo cambiar el brillo de la pantalla moviendo el mouse sobre el ícono de brillo
13. Puedo arrastrar una ventana a la parte superior de la pantalla para maximizarla
14. Puedo enviar una ventana a diferentes escritorios virtuales usando un acceso directo global
15. Hay un pequeño medidor de volumen en vivo en cada control deslizante en la ventana emergente de volumen.
16. Puedo abrir una pequeña ventana de lupa alrededor del cursor del mouse.
17. Puedo dibujar líneas rojas en la pantalla usando un efecto de escritorio. (aunque todavía no sé muy bien en qué me puede eso servir).
18. Puedo usar los botones de avance/retroceso del mouse en la barra de tareas para cambiar pistas de música
19. Cuando muevo el mouse, el cursor se hace cada vez más grande, ¡y no hay límite!
20. La luz nocturna reconforta mis ojos en las horas por la noche.
21. KRunner encuentra pestañas del navegador entre cientos de pestañas que tengo (y muchas otras cosas, y funcionalidades)
22. Puedo subir el volumen del altavoz por encima del 100% cuando sea necesario
23. Puedo mover la barra de título de una ventana para cambiar su opacidad y comparar cosas rápidamente
24. Puedo hacer que la tecla Copilot de mi teclado haga algo útil (no tengo tal cosa, pero sí he redefinido algunas teclas para darles otra funcionalidad que necesito)
25. Puedo usar reglas de ventana para forzar que las aplicaciones se abran exactamente como quiero. (amen, qué útil es eso para mí)
26. Puedo agregar atajos globales personalizados para casi cualquier cosa
27. System Monitor muestra una gran cantidad de información (que también puedo copiar en modo texto para añadirlo en un reporte de bug, en un foro, etc)
28. Puedo acelerar la reproducción de prácticamente cualquier vídeo desde el controlador multimedia de Plasma.
29. Puedo usar Meta clic izquierdo para mover y Meta clic derecho para cambiar el tamaño de una ventana en cualquier momento (sin necesidad de tener una puntería extraordinaria para encontrar el tirador de la ventana para hacerlo)
30. Puedo acceder rápidamente a archivos recientes abiertos en una aplicación haciendo clic derecho en la entrada de la barra de tareas

Y la lista podría extenderse en un número muuuucho mayor ¿Te animas a hacerlo? Usa en los comentarios tus otras razones por las que amas a Plasma de KDE y comparte con la comunidad.

Y para seguir haciendo Plasma y todas las aplicaciones cada vez mejor, no dudes en hacer un pequeño donativo para que la comunidad de KDE pueda seguir desarrollando su gran trabajo en libertad e independencia:

• https://kde.org/es/donate/

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! 🦎🌏

Hace ya muchas semanas que fue lanzado el nuevo entorno de escritorio de la Comunidad KDE y todavía no he tenido tiempo para difundirlas todas como se merece. Finalizo hoy la serie con las mejoras en HDR, ventanas y rendimiento de Plasma 6.5, un extenso repaso a todo el gran trabajo del equipo de desarrolladores de KDE.

Las mejoras en HDR, ventanas y rendimiento de Plasma 6.5

Estar a la última en cuanto a tecnología es duro y cuesta estar al día, es por ello que otro de los objetivos de la Comunidad KDE es la de ofrecer la mejor calidad de imagen utilizando HDR, y por esta razón los desarrolladores han trabajado con ahínco para lograrlo. Poco a poco parece que se va logrando.

En esta nueva versión de Plasma 6.5 , la curva de mapeo de tonos que usa KWin se ha afinado para cuando se muestre contenido HDR, que ahora se ve mejor que nunca. Algo que lamentablemente no veré a menos que conecte mi portátil a mi televisor (todavía no lo he hecho y se me acaba de ocurrir una gran idea).

Además, Plasma 6.5 es compatible con una versión experimental del protocolo «imagen sobre imagen» de Wayland que promete que aplicaciones como Firefox puedan mostrar finalmente ventanas PiP correctas que permanezcan sobre otras de forma automática.

Los desarrolladores también están trabajando en mejorar el rendimiento pensando tanto en equipos nuevos como en los más viejos, así se ha añadido compatibilidad con «planos superpuestos», lo que promete reducir el uso de la CPU y el consumo de energía al mostrar contenido a pantalla completa usando una GPU compatible.

También se ha optimizado el código de la pantalla de bienvenida, reorganizar algunos pasos del arranque y reducir la duración de la imagen de inicio de sesión, hemos conseguido que el escritorio se cargue más rápidamente, haciendo que la experiencia con Plasma sea más ágil.

Más información: Plasma 6.5

La entrada Las mejoras en HDR, ventanas y rendimiento de Plasma 6.5 de Plasma 6.5 se publicó primero en KDE Blog.

この記事は openSUSE Advent Calendar 2025 の8日目です。

openSUSE 16.0 から linux-pam のバージョンが1.7.0 になりました。オリジナルサイト

https://github.com/linux-pam/linux-pam

の最新は1.7.0 なので openSUSE は最新に追いついたと言えます。

openSUSE 15.x の pam は 1.3.0 だったのでかなり新しくなります。そのためいくつか違いがあるようです。どう違っているかを調べるため、マニュアル等を見てみることにしたのですが、オリジナルのマニュアルは xml なので、コンパイルして読みやすくしてみることにしました。

環境の準備

ソースを引っ張ってきてコンパイルするだけですので、わざわざそのために新しく環境を作るのは大変です。そこで、Proxmox VE の LXC コンテナを使うことにしました。単純なコンパイルとかはこれで十分です。フットプリントも小さいですし。
そして、とてもありがたいことに、 opensuse-15.6 のテンプレートがあります。それを使えばサクッと LXC 上の環境を作ることができます。
ただ、提供されているテンプレートはとても基本的なものなので、外から入ることができません。そこで、インストール後は zypper update し、さらに openssh-server、git と nano を入れます。また作業用のユーザも作っておきます。

ソースをダウンロード

git clone https://github.com/linux-pam/linux-pam.git

でソースをダウンロードします。

meson を使う

linux-pam のコンパイルには、meson が必要です。以前は autotools だったらしいですが。このため、いろいろ入れないと動きません。最低限コンパイラが必要です。今回は gcc を使います。

% cd linux-pam

で作業ディレクトリに移り、

% meson build

で configure を作り、さらに、

% meson -C build

で一応ビルドはできるようになります。ただし出来るのはバイナリだけ。マニュアルは出てきません。マニュアル作成には結局

libxslt-tools
docbook_5
docbook5-xsl-stylesheets

を追加インストールすることで、できるようになりました。

で、build/modules 配下ににある各モジュールディレクトリ中にマニュアルが、man 形式で生成されます。

ちなみにbuildした時点では、ディスク容量は 884M しか使っていませんでした。コンテナだと本当にフットプリント小さいですね。

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.

Me congratula presentaros el episodio 60 de KDE Express, titulado «Triplete de Valve + KDE Slimbook» donde David Marzal nos informa del gran anuncio de la compañía de videojuegos que teóricamente no sabe contar hasta tres pero que anuncia sus lanzamientos por tríos, sin olvidar el gran lanzamiento de la compañía valenciana,

Episodio 60 de KDE Express: Triplete de Valve + KDE Slimbook

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos 60 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En palabras de David:

Valve se ha marcado una jugada impresionante y eso se merece que os la contemos aunque aún falte bastante tiempo para tener todos los datos. También os avisamos de que ya tenemos disponible el nuevo KDE Slimbook y con descuento si os dais prisa.

Probamos a grabar en movilidad (pese a lo hostil de las ciudades con coches), para ver qué os parece intercalar más episodios cortos, de menos temáticas, a la periodicidad «habitual».

Triplete de Valve

Especificaciones : https://store.steampowered.com/sale/hardware

Valve anuncia su Steam Machine, gafas VR y mando nuevo : https://www.muylinux.com/2025/11/13/valve-steam-machine-controller-frame/

Bazzite no es una Steam Machine : https://www.linuxadictos.com/hay-gente-asegurando-que-ya-te-puedes-montar-tu-propia-steam-machine-con-bazzite-discrepo.html

KDE Slimbook VII

Articulo de Muy Linux : https://www.muylinux.com/2025/11/19/kde-slimbook-vii/

Especificaciones y oferta : https://slimbook.com/

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Episodio 60 de KDE Express: Triplete de Valve + KDE Slimbook se publicó primero en KDE Blog.

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!