Table of Contents

• 1) Introduction
• 2) Overview of the qSnapper D-Bus Service
• 3) Security Issues
  • 3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)
  • 3.2) Path Traversal via configName Parameter (CVE-2026-41046)
  • 3.3) Information Leak via “diff” Methods (CVE-2026-41047)
  • 3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)
  • 3.5) Defense-in-Depth Issues when Restoring Arbitrary Files
  • 3.6) Other Issues
• 4) Upstream Bugfixes
• 5) Disclosure Process
• 6) Timeline
• 7) References

1) Introduction

qSnapper is a GUI frontend for the snapper utility for managing Btrfs filesystem snapshots. In April we received a review request for qSnapper, because it contains a privileged D-Bus service and Polkit policies.

Normally, Btrfs snapshots can only be managed with root privileges. qSnapper aims to provide more user-friendly and fine-grained access to snapshot management features, based on a privileged daemon which utilizes D-Bus and Polkit. Our review of the service uncovered various security issues, which led to a longer coordinated disclosure to allow upstream to develop bugfixes, which are part of upstream release 1.3.3.

The full details of the security issues will be covered in the sections below. The original review was performed on qSnapper release 1.1.3. Since bigger upstream changes appeared in the meantime this report is based on qSnapper release 1.3.2, however.

2) Overview of the qSnapper D-Bus Service

The qSnapper project contains a daemon named qsnapper-dbus-service, which runs with full root privileges. The daemon provides the D-Bus interface “com.presire.qsnapper.Operations” on the system bus; some of its methods are provided to arbitrary users in the system without authentication, while the majority of them is protected by Polkit authentication checks. The implementation of the various D-Bus methods offered by the service is found in snapshotoperations.cpp. All of the security issues outlined below are located in this compilation unit.

3) Security Issues

3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)

The SnapshotOperations::checkAuthorization() function uses Polkit’s UnixProcess subject in an unsafe way to authenticate clients. The code obtains the client’s PID from the active D-Bus connection, which leads to a race condition. At the time the Polkit daemon (polkitd) checks the provided PID, the process in question can already have been replaced by another, privileged process. This is a well-known class of Polkit authentication bypasses which was assigned CVE-2013-4288.

In effect this means that clients may be able to bypass all Polkit authentication checks performed by qSnapper, although the attack is somewhat complex and might need multiple attempts to succeed. There is nothing stopping a local attacker from doing that, however. In combination with the configuration path traversal in D-Bus methods like WriteSnapperConfig() described below, this can be used to achieve a full local root exploit.

To fix this, we suggested to use Polkit’s SystemBusName subject instead. With this subject, the D-Bus daemon obtains the client’s UID in a race-free fashion from the UNIX domain socket the client used to connect, and polkitd cannot be fooled by recycled PIDs.

3.2) Path Traversal via configName Parameter (CVE-2026-41046)

All the D-Bus methods accepting a configName parameter (that is nearly all of them) suffer from a path traversal vulnerability. This string parameter is directly passed to snapper::Snapper(), which is part of the libsnapper API, without checking its safety. libsnapper expects a basename here to look up a configuration file in /etc/snapper/configs. In the context of qSnapper this string can contain additional path components like ../../path/to/crafted.cfg. This allows clients to use arbitrary configuration files as input to libsnapper.

When looking at the writeSnapperConfig() D-Bus method, which requires admin authentication, this path traversal allows to write largely attacker-controlled data to arbitrary locations. Combined with the Polkit authentication bypass described earlier in section 3.1, this would allow for a full local root exploit.

In case of other D-Bus methods which use the “list-snapshots” Polkit action, the path traversal is also accessible to locally logged-in users without any authentication. Luckily the libsnapper configuration file format offers no features that lead to a trivial local root exploit in this context. The impact of the vulnerability can be any of the following, however:

• local Denial-of-Service (DoS): by pointing libsnapper to a special file like /dev/zero, the daemon will consume the maximum amount of memory and be killed by the kernel. By pointing libsnapper to a named FIFO special file, the daemon will block indefinitely.
• information leak from parsing of private files: by pointing libsnapper to a private file like /etc/shadow, libsnapper will parse the sensitive data from the file as configuration data. If any logging features are active and the logs can be accessed by unprivileged users, then private data from such a file might leak into the unprivileged context. We are not aware of such an information leak in default installations, however.
• by providing crafted configuration data further attacks can be carried out:
  • SUBVOLUME can be pointed to arbitrary mounts in the system. Luckily libsnapper is conservative in its file operations here, and quite strictly verifies the validity of this path; it verifies if it is really a mount point and is backed by the expected block device and file system etc.
  • ALLOW_USERS and ALLOW_GROUPS can be set to arbitrary users and groups, allowing them officially to control the Snapper configuration.
  • The SYNC_ACL setting causes libsnapper to apply ACL entries to the .snapshots directory of the volume path, granting the users and groups from ALLOW_USERS and ALLOW_GROUPS to access the snapshot data. Thus this is a major local information leak.

libsnapper is using different backends depending on the file system type. Different code is used for each backend, which means that the exploitability of some aspects of the vulnerability depends on which backend is used. On openSUSE only the Btrfs and LVM thin volume backends are compiled-in by default, which only offer little additional attack surface.

To fix the issue, we suggested to upstream to verify the configName parameter in all cases and reject it if any / or .. components are found in it.

3.3) Information Leak via “diff” Methods (CVE-2026-41047)

The Polkit action “list-snapshots” is allowed for locally logged-in users without authentication, and is used by multiple qSnapper D-Bus methods which are likely considered “read-only” operations not harmful to the system. In version 1.1.3 of qSnapper the following methods are relying on this Polkit action:

• ListSnapshots()
• GetFileChanges()
• GetFileDiffAndDetails()

In version 1.3.2 of qSnapper these additional methods are using the action:

• GetFileChangesBetween()
• GetFileDiffBetween()

These methods allow to obtain information about metadata changes of arbitrary files between snapshots or between snapshots and the live filesystem. The newer GetFileDiffBetween() method even offers full file content diff output. These are major local information leaks, since unprivileged users can get a diff e.g. of the /etc/shadow file between different system states, or changes from root’s home directory which could leak sensitive data like passwords or private keys.

To fix this, we suggested to upstream that all methods providing non-public information get restricted by auth_admin Polkit checks. Alternatively, a check could be implemented whether the files to be diffed are normally accessible to the caller by using checks similar to the access() system call; such an approach would likely be rather complex and error-prone, however.

3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)

In version 1.2.1 of qSnapper an m_authenticated flag was introduced to the daemon’s code, which caches authentication once a client has passed certain Polkit action authentication checks. This cached authentication is shared between the methods DeleteSnapshot(), RestoreFiles() and RestoreFilesDirect(). There are two issues with this approach:

• DeleteSnapshot() uses the “delete-snapshot” action, while the other methods use the “rollback-snapshot” action. If a caller can authenticate for “delete-snapshot” then it is also implicitly authenticated for “rollback-snapshot” and vice versa. This is not how Polkit is intended to be used. If a system administrator decides to relax the authentication requirement for “delete-snapshot”, then this automatically implies the “rollback-snapshot” action now, which are two very different impacts to the system. We assigned CVE-2026-41048 for this aspect of the issue.
• The implementation of the caching logic assumes that a single interactive client is talking to the daemon. In fact, arbitrary users can invoke these methods. If a legitimate client is authenticated for one of the affected actions once, then arbitrary other users like nobody are now also considered authenticated and Polkit will not be invoked anymore. This authentication bypass allows for a full local root exploit in the context of the RestoreFiles() methods, as outlined below in section 3.6. We assigned CVE-2026-41049 for this aspect of the issue.

We suggested to upstream to drop this form of authentication caching, or alternatively implement an authentication cache tied to each user and each Polkit action in question to avoid the issues.

3.5) Defense-in-Depth Issues when Restoring Arbitrary Files

This section discusses Defense-in-Depth issues which remain once all the more tangible issues discussed above are fixed. The restoreFiles() D-Bus method accepts arbitrary filePaths as parameter to be restored from a version found in a snapshot. Clients need to authenticate as an administrator to do this, so there is no direct attack surface. Let’s consider the path /var/lib/colord/mapping.db to be restored, however:

# On openSUSE Tumbleweed this directory is owned and writable by `colord`
$ ls -lh /var/lib/colord
drwxr-xr-x 3 colord colord 4.0K Mar 6 2024 .

At the time the qSnapper service performs the chown() system call, the colord service user can stage a symlink attack in the colord directory and cause arbitrary files in the system to receive colord ownership, allowing a colord to root exploit. A similar issue affects the copyRegularFile() function, where a file on the live file system is newly created.

This issue is hard to fix, given the many different file system situations that the restore operation can end up in. The basic algorithm to address the problem would need to use low-level system calls like openat(), fchown() and fstatat() to safely traverse file system paths and inspect any symbolic links on the way. Given the complexity of the bugfix and limited impact, we agreed with the upstream author that this fix does not need to be prepared during the coordinated disclosure period but can be developed in the open afterwards.

Given the amount of front-line security issues already found in qSnapper in the course of this review, we refrained from assigning a dedicated CVE for these Defense-in-Depth issues in this case.

3.6) Other Issues

This section covers a number of other issues that are not fully-fledged security issues, but still represent weaknesses or possible hardenings for the qSnapper implementation.

• the D-Bus method RestoreFiles() implements complex file operations to rollback changes of a file path to the state found in a snapshot. These file operations allow authenticated clients to achieve nearly arbitrary file operations:
  • recursive deletion of arbitrary paths
  • copy of arbitrary files to arbitrary locations
  • change of ownership of files to arbitrary users
  • change of the file mode to arbitrary values

  This is because the method is not verifying whether the claimed file exists in the snapshot in the first place and whether the filePaths contain any ../ directory components to escape the snapshot directory. While this method is protected by Polkit’s auth_admin setting, any D-Bus method should be written conservatively and in such a way that the intended purpose of the method cannot be bypassed. The very similar method RestoreFilesDirect() has the same issues and also contains a lot of duplicate code which should be merged with the other method’s code.

• the Quit() method can be called by anyone in the system without authentication. This is kind of a local DoS against an active qSnapper daemon in use by other users in the system.
• the logfile created in /var/log/qSnapper will be world-readable, which could leak sensitive information. For hardening purposes it could be made private to root.

4) Upstream Bugfixes

The upstream author closely followed our suggestions to fix the security issues described in this report. Version 1.3.3 of qSnapper contains the following bugfixes:

• commit a6caf538 addresses the following issues:
  • the Polkit UnixProcess subject is replaced by the SystemBusName subject to avoid the race condition during authentication (issue 3.1).
  • the configName parameter in all D-Bus methods is now carefully verified and rejected if it allows path traversal (issue 3.2).
  • the authentication caching is removed (issue 3.4).
  • the RestoreFiles methods reject path traversal attempts (see section 3.6).
• commit f375b74c addresses the following issues:
  • a new view-diff Polkit action is introduced to generate file diffs which requires auth_admin authentication to prevent information leaks (issue 3.3).
  • the unauthenticated Quit D-Bus method was dropped (see section 3.6).
  • log files are now created without world-readable bit (see section 3.6).

The more complex defense-in-depth issues outlined in section 3.5 will be addressed by upstream in the open at a later time.

5) Disclosure Process

Once we established contact with the upstream author, we had a very constructive discussion of the coordinated disclosure process. Upstream quickly acknowledged the issues, opted for coordinated disclosure and communicated a time schedule when bugfixes were expected to be available for review and when a bugfix release of qSnapper would be published. When we agreed on the final bugfixes in the middle of May, we agreed on choosing an earlier publication date than originally intended.

We want to thank the upstream author for handling this report in a very professional fashion and for greatly improving the security and robustness of qSnapper.

6) Timeline

7) References

• qSnapper GitHub repository
• qSnapper 1.3.3 bugfix release
• openSUSE review bug for qSnapper

Breaking New Ground: Mobile Linux Hackday #1 in České Budějovice Outperforms Prague! If you’ve been following the Mobile Linux journey in Czechia, you know we’ve built a fantastic routine in Prague. We have a really successful series behind us consisting of 7 monthly hackdays, always hosted at the Prague SUSE office. But when the stars […]

The post MobileLinux Hackday #1 in České Budějovice Outperforms Prague! appeared first on SUSE Communities.

GNOME には操作性等を拡張するための、種々の拡張機能が用意されています。このうち、Windows のように、デスクトップ上にファイルを直におけるようにする、Desktop icons NG(DING) は、GNOME 環境での操作性を大きく改善するため、よく使われている拡張機能です。
しかし、openSUSE 16 の GNOME に、この拡張機能をインストールしても、そのままでは動作しません。インストールはできますが、設定メニューが動かないのです。

調べてみたところ、/var/log/messages に

2026-05-25T10:11:38.899231+09:00 16gnm gnome-shell[5172]: Launching DING process
2026-05-25T10:11:39.088697+09:00 16gnm gnome-shell[5172]: DING: (gjs:12931): Gjs-CRITICAL **: 10:11:39.087: JS ERROR: Error: Requiring GLibUnix, version 2.0: Typelib file for namespace ‘GLibUnix’, version ‘2.0’ not found

というエラーが出ていました。そこで調べてみたところ、ものは
https://docs.gtk.org/glib-unix/unix.html
のようです。openSUSE の場合はどうやら typelib-1_0-GLibUnix-2_0 のようなので、これをインストールすると正常に動作するようになりました。

Hoy quiero dar eco a una entrada bastante importante para entender como funciona el desarrollo de las distribuciones y por qué entender los conceptos es clave para hacer buenas elecciones. Bienvenidos a la entrada en la que Nate Graham (creador de los artículo de Esta Semana en Plasma) intenta explicar que soporte a largo plazo no significa lo que crees de una forma clara y sencilla. Algo que muchos ya sabemos pero que vale la pena recordar.

Soporte a largo plazo no significa lo que crees

De nuevo me hago eco de una entrada del blog Adventures in Linux and KDE de Nate Graham, en el que desgrana el significado real de «»Soporte a largo plazo» ( «Long Time Suport» o «LTS», en sus acepciones en inglés). Algo que nos pone sobre la mesa lo que es y lo que no es respecto a este concepto

Para empezar Nate nos quiere dejar claro que “Long-Term Support” no promete un sistema libre de fallos, sino una versión de software que recibe actualizaciones durante varios años, sobre todo parches de seguridad y, a veces, mantenimiento adicional.

Esto pinta bien: sistema robusto y a prueba de fallos, pero el mundo del Software es algo más complicado. Una cosa es el sistema pero otras son sus aplicaciones, que en este sistema suelen quedar fijadas a una versión concreta del software, sin nuevas funciones ni mejoras de interfaz durante su ciclo de vida. Los errores mayores serán solucionados pero los menores no. Las numerosas mejoras que lleguen para las aplicaciones no nos llegan a los LTS.

De esta forma la idea central es que una LTS es más bien una promesa de mantenimiento prolongado, no una garantía de estabilidad perfecta ni de soporte personal. Según subraya Nate, en una LTS pueden seguir existiendo bugs, crashes, problemas no corregidos y límites de compatibilidad con hardware nuevo, porque eso no forma parte de lo prometido .

Así que hay que tener claro si una LTS encaja con nuestro forma de utilizar nuestro sistema. Si quieres software más nuevo, mejores correcciones rápidas o mejor soporte de hardware suelen estar mejor en distribuciones de actualización rápida, mientras que una LTS favorece minimizar cambios e inconsistencias entre paquetes. No hay nada perfecto, si quieres estabilidad olvídate de novedades, si quieres novedades olvídate de estabilidad. Ambos conceptos están en los extremos de una balanza.

Nate también nos explica que existen las LTS gratuitas y la que vienen de la mano de un soporte comercial real. Según el artículo, si lo que se busca es una garantía fuerte de resolución de problemas y atención directa, eso ya entra en productos de pago como Ubuntu Pro, RHEL o SUSE con soporte empresarial . Si no es así, debes conformarte con una LTS comunitaria como Ubuntu LTS, Debian Stable o openSUSE Leap.

Para finalizar, Nate nos comenta que un buen complemento a las LTS en cuanto a tener aplicaciones a la última son los aplicaciopnes Flatpak o Snap, las cuales están actualizadas sin depender tanto del ritmo de la distro. Eso ayuda a tener software más nuevo, pero no elimina los inconvenientes de los formatos universales, como integración desigual, tamaño mayor o diferencias de comportamiento respecto a paquetes nativos.

Este último párrafo, junto uno de los comentarios que aparece en la entrada nos lleva a KDE Linux y lo que quiere conseguir: un sistema base pequeño y estable, compuesto por un cargador de arranque, el kernel, systemd y los controladores de dispositivos; mientras que todo el software de la interfaz gráfica se distribuiría entonces mediante la versión “flatpak-next” de Flatpak, que está en desarrollo y que, al parecer, resolverá todos los problemas que tenemos con la implementación actual.

¿La cuadratura del círculo? ¿Estabilidad y novedad en una misma distribución? Esperemos que si, el tiempo lo dirá.

La entrada Soporte a largo plazo no significa lo que crees se publicó primero en KDE Blog.

El mundo de las aplicaciones de la Comunidad KDE es casi infinito. Hace cuatro años que presenté Haruna, otro reproductor multimedia que se une a las alternativas KDE como Dragon Player o Kaffeine y que sigue su desarrollo. Por eso me complace compartir con vosotros que ha sido lanzado Haruna 1.8, que llega cargado de novedades.

Lanzado Haruna 1.8, nueva versión de este reproductor multimedia de KDE

Siempre es de agradecer tener varias opciones para cualquier funcionalidad básica de nuestro sistema, y en eso el Software Libre es sobresaliente, y es que en ocasiones podemos tener problemas con uno de ellos o que simplemente nos guste uno más que otro.

Tenemos a nuestra disposición decenas de reproductores multimedia como VLC o SMPlayer, y la Comunidad KDE te ofrece incluso un par dentro de su ecosistema, los ya nombrados Dragon Player o Kaffeine.

A este elenco se unió hace años Haruna, un reproductor de vídeo de código abierto construido con libmpv que destaca por su integración con Youtube y que sigue evolucionando a su ritmo dado que hace poco ha llegado a su versión 1.8.

Entre sus novedades destacan:

• Posibilidad de abrir múltiples archivos desde la línea de comandos y no todos los de la carpeta.
• Acción de detener,disponible en la reproducción.
• Añadido ajuste para activar el progreso en la barra de tareas.
• Mostrar el nombre del archivo/título en el OSD (visualización en pantalla) al abrir un archivo.
• MPRIS: buscar y establecer la portada desde un archivo de imagen externo para archivos de audio sin portadas internas.
• Animación de carga personalizada.
• Ajuste para la propiedad sub-border-style de mpv.

Respecto a la Lista de reproducción también tenemos nuevas funcionalidades

• Elemento de menú para abrir el archivo en la aplicación MediaInfo ( si está instalada).
• Permitir la ordenación ascendente/descendente para la opción «Ninguna» (None).
• Indicador de la posición de reanudación de la reproducción debajo de la duración.
• El tirador para arrastrar elementos ahora se muestra al pasar el cursor por encima (hover).

Haruna, otro reproductor multimedia de KDE

Las principales características de Haruna son las siguientes:

• Posibilidad de poner una lista de reproducción automática.
• Atajos de teclado configurables.
• Reproducción de vídeos en línea a través de youtube-dl/yt-dlp
• Saltar automáticamente los capítulos que contengan determinadas palabras
• Asignación de acciones a los botones del ratón: clics simples y dobles a la izquierda, al centro y a la derecha, así como desplazamiento hacia arriba y hacia abajo
• Salto rápido al siguiente capítulo haciendo clic en el centro de la barra de progreso.
• Posibilidad de cambiar los esquemas de color así como los estilos de los widgets/controles.

Más información; Haruna

La entrada Lanzado Haruna 1.8, nueva versión de este reproductor multimedia de KDE se publicó primero en KDE Blog.

El incansable trabajo de promoción que está realizando Nate (ahora con ayuda de otros desarrolladores) en su blog sigue su ritmo. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y desde hace un tiempo que le voy a siguiendo semana tras semana, traduciendo sus artículos al castellano utilizando los magníficos traductores lo cual hará que la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «Soporte para el controlador Xe y mejoras en Discover» de «Esta semana en Plasma«. Espero que os guste.

Soporte para el controlador Xe y mejoras en Discover – Esta semana en Plasma

Nota: Artículo original en Blogs KDE. Traducción realizada utilizando Perplexity. Esta entrada está llena de novedades de la Comunidad KDE. Mis escasos comentarios sobre las mejoras entre corchetes.

Mejoras en la interfaz de usuario

Plasma 6.7

Vaciar el portapapeles cuando hay elementos marcados con estrella ya no pregunta si también quieres borrar los elementos marcados; ahora nunca se borran automáticamente, y tienes que hacerlo manualmente, con la lógica de que, si los marcaste, ¡probablemente quieres conservarlos! (Tobias Fella, plasma-workspace MR #6583) [Bien pensado].

Cuando el widget Discos y dispositivos aparece después de conectar un disco, ya no parpadea brevemente con el icono de notificación. (Bohdan Onofriichuk, KDE Bugzilla #495141) [Es una pequeña mejora de la eficiencia del sistema].

Plasma 6.8

Cuando Discover te pide borrar los datos y la configuración de una aplicación Flatpak que ya no está instalada, al hacerlo ahora todo eso se envía a la papelera en lugar de eliminarse de forma inmediata e irreversible. (Nate Graham, KDE Bugzilla #520220) [Bien para restaurar errores].

Se han reorganizado las secciones de la página principal de Discover para colocar la sección “Elección del editor” más cerca de la parte superior. (Raresh Rus, discover MR #1333)

Se ha reducido la cantidad de saltos visuales en la interfaz del indicador de “progreso total” de Discover durante las actualizaciones del sistema. (Taras Oleksyn, KDE Bugzilla #510282)

La búsqueda en la página de Actualizaciones de Discover ahora no distingue entre mayúsculas y minúsculas. (Tobias Ozór, discover MR #1328) [Mucho mejor, las mayúsculas en los nombre de aplicaciones es un poco caótico (¿Eh, digiKam?)].

Corrección de errores importantes

[No comento las correcciones de errores ya que son bastante evidentes].

Plasma 6.6.6

Se corrigió un caso en el que Plasma podía bloquearse al cambiar de Actividades usando el widget Activity Pager. (Marco Martin, KDE Bugzilla #520065)

Se aplicó una solución temporal a una regresión de Qt que hacía que las notificaciones de progreso de tareas permanecieran visibles en pantalla hasta cerrarlas manualmente. (Kai Uwe Broulik, KDE Bugzilla #520120)

Se corrigió un fallo que rompía la opción para recordar tus aprobaciones en el diálogo de permisos de screencasting. (David Redondo, KDE Bugzilla #517454)

Se corrigió un problema que renderizaba mal los temas de decoración de ventanas no predeterminados al usar un factor de escala inferior al 100%. (Vlad Zahorodnii, KDE Bugzilla #520272)

Se corrigió un fallo que rompía la capacidad de Temas globales para añadir y colocar widgets como se esperaba. (Marco Martin, KDE Bugzilla #512005)

Plasma 6.7

Se corrigieron algunos casos en los que Plasma podía bloquearse al conectar o desconectar pantallas. (Marco Martin, KDE Bugzilla #468430)

Se aplicó una solución temporal a un problema de Qt que a veces hacía que la propia herramienta de informes de fallos entrara en un bucle de bloqueos. (Harald Sitter, KDE Bugzilla #517353)

Se corrigió un fallo que a veces podía hacer que Discover se bloqueara al instalar una app Flatpak desde un archivo .flatpakref descargado. (Tobias Fella, KDE Bugzilla #520371)

Se corrigió un caso en el que Plasma podía bloquearse mientras el widget Weather Report comprobaba actualizaciones del tiempo. (David Edmundson, kdeplasma-addons MR #1051)

Se corrigió un extraño problema que podía hacer que el widget Kickoff Application Launcher creciera verticalmente en X11 justo después de abrirlo, tras cambiar a otro widget y volver, inmediatamente después de iniciar sesión. (Harald Sitter, KDE Bugzilla #515116)

Se reforzó el sistema para evitar que aparecieran huecos entre las pantallas en una configuración multimonitor. (Xaver Hugl, KDE Bugzilla #507702)

Se corrigió un fallo en la función de creación de Temas globales que guardaba incorrectamente la configuración de los paneles. (Akseli Lahtinen, KDE Bugzilla #520489)

Se corrigió un fallo en el widget Reloj digital que coloreaba mal los puntos de los eventos del calendario del mes anterior. (Young Lord, plasma-workspace #6587)

Se corrigieron dos problemas del puntero al usar el efecto Zoom de KWin: punteros duplicados al agitarlo para hacerlo más grande y punteros visualmente desincronizados al arrastrar elementos. (Xaver Hugl, KDE Bugzilla #489265 y KDE Bugzilla #513233)

Se corrigió un problema que podía hacer que Discover mostrara estados distintos en diferentes páginas para una app que se estaba instalando o desinstalando. (Oliver Beard, KDE Bugzilla #520028)

Plasma 6.8

Se corrigió un problema que impedía añadir una app a la lista de favoritos inmediatamente después de desinstalarla y volver a instalarla. (Christoph Wolk, KDE Bugzilla #494542)

Frameworks 6.27

Se corrigió un fallo visual que a veces aparecía en la barra lateral de Discover cuando se abría la aplicación. (Nate Graham, KDE Bugzilla #520337)

Mejoras de rendimiento y aspectos técnicos

Plasma 6.7

Se corrigieron un par de fugas de memoria descubiertas en KWin. (Xaver Hugl, kwin MR #9235)

Plasma 6.8

Se añadió compatibilidad con el controlador Intel Xe a la aplicación Monitor del sistema y a sus widgets. (Hunter Hardy, KDE Bugzilla #512866)

Cómo puedes ayudar

KDE se ha vuelto importante en el mundo, y tu tiempo y contribuciones han ayudado a llegar hasta aquí. A medida que crecemos, necesitamos tu apoyo para mantener KDE sostenible.

¿Te gustaría ayudar a preparar este informe semanal? Preséntate en la sala de Matrix y únete al equipo.

Más allá de eso, puedes ayudar a KDE involucrándote directamente en cualquier otro proyecto. Donar tiempo es realmente más impactante que donar dinero. Cada colaborador marca una gran diferencia en KDE — ¡no eres un número ni un engranaje en una máquina! No tienes que ser programador, existen muchas otras oportunidades.

También puedes ayudar haciendo una donación. Esto ayuda a cubrir costes operativos, salarios, gastos de viaje para colaboradores y, en general, a mantener KDE llevando Software Libre al mundo.

KDE

Soporte a largo plazo no significa lo que crees

baltolkien May 25, 2026

Lanzado Haruna 1.8, nueva versión de este reproductor multimedia de KDE

May 24, 2026

Soporte para el controlador Xe y mejoras en Discover – Esta semana en Plasma

May 23, 2026

Workshop: IA Agéntica y Automatización Total en Linux Center València

May 22, 2026

La entrada Soporte para el controlador Xe y mejoras en Discover – Esta semana en Plasma se publicó primero en KDE Blog.

Echemos un vistazo a las novedades de Agama 20 y la recién publicada versión 21 del nuevo instalador para SUSE y openSUSE.

Agama 19 se publicó en marzo de 2026, desde entonces hasta hoy muchas cosas se han estado mejorando. Echemos un vistazo a las novedades de Agama 20 y la recién publicada versión 21 del nuevo instalador para SUSE y openSUSE.

Esta es una traducción/adaptación del anuncio oficial en inglés. El anuncio oficial lo podéis leer en el siguiente enlace:

• Releasing version 21 | Agama

Arrojando algo de luz sobre los escritorios

Y pocas cosas son más visibles en un sistema GNU/Linux que su entorno de escritorio. Durante la instalación, la mayoría de las distribuciones openSUSE ofrecen una amplia variedad de escritorios para elegir. Pero openSUSE no tiene ninguno de esos entornos como opción predeterminada. Como consecuencia, el usuario debe tomar una decisión consciente durante la instalación.

Eso no era lo suficientemente evidente en versiones anteriores de Agama. Como resultado, era muy fácil acabar instalando un sistema sin ninguna interfaz gráfica. Encontrar así el sistema, nada más teminar la instalación podría resultar abrumador para muchos usuarios, especialmente para los recién llegados a openSUSE o GNU/Linux en general.

Ahora la situación se presenta con mayor claridad en la pantalla principal de resumen del instalador y en la sección de selección de software, en la que se muestra una información y una advertencia de que no se ha escogido ningún entorno de escritorio.

También se ha aprovechado para repensar varios aspectos de la forma utilizada para seleccionar patrones de paquetes. Ahora funciona de una manera más coherente con el resto de la interfaz de Agama y presenta la información de una forma más útil.

Además de todo eso, se añadió un recordatorio sobre la posible falta de entorno de escritorio en el diálogo de confirmación para algunas distribuciones como openSUSE Tumbleweed, Slowroll o Leap 16.1.

Mejor gestión de redes en la interfaz web

La interfaz de usuario para configurar la red también recibió un nuevo diseño importante en estas versiones 20 y 21. El resultado más visible es un formulario completamente rediseñado para crear y modificar conexiones de red.

Con el nuevo formulario, se mejora la interfaz web con la capacidad de configurar más tipos de conexiones, además de Ethernet y Wi-Fi. En versiones anteriores, era necesario usar el formato de configuración Agama basado en JSON para establecer una conexión de red, un puente o una conexión VLAN.

Con Agama 21 ahora es posible configurar una conexión de enlace o puente directamente desde la interfaz de usuario. Como siempre, Agama ofrece ajustes predeterminados razonables para cada tipo de conexión, pero también permite configurar manualmente varios aspectos avanzados.

Restringir el acceso a la red al instalador

Hablando de instalaciones y red, Agama permite controlar el proceso de instalación a través de la red desde otro ordenador o dispositivo móvil. Pero esa es una característica que podría tener implicaciones de seguridad en algunos escenarios.

Ahora es posible desactivar el acceso remoto con la opción de arranque inst.remote=0. Cuando se utiliza, el instalador solo puede ser accedido localmente desde la máquina que se está instalando.

Mejoras de usabilidad en las herramientas de línea de comandos

Además de todas las nuevas funciones de instalación mencionadas, la interfaz de línea de comandos también recibió varias mejoras para hacerla más útil para seguir el estado actual del proceso de instalación.

Tanto si automatizas el proceso de instalación como si simplemente prefieres trabajar desde el terminal, las herramientas de CLI mejoradas ofrecen una mejor visibilidad de lo que Agama está haciendo en cada momento. Estas mejoras facilitan la monitorización de procesos de instalación, la resolución de problemas y la integración de Agama en tus flujos de trabajo de automatización existentes.

Todo esto, junto con otras mejoras avanzadas como instalar en una configuración LVM existente, o soporte para systemd-boot, así como enlaces de descarga de la ISO, código, etc. lo tienes disponible en el anuncio oficial:

• Releasing version 21 | Agama

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2026/05/tumbleweed-review-of-the-week-2026-21/

Esta semana se han publicado 6 Snapshots  (0514, 0515, 0516, 0518, 0519, y 0520)

Estos son los cambios más relevantes:

• AppArmor 5.0.0
• KDE Plasma 6.6.5
• fwupd 2.1.3
• GStreamer 1.28.3
• Linux kernel 7.0.6, 7.0.7 & 7.0.9
• Ruby 4.0.4
• Apache 2.4.67
• gpg 2.5.20
• pipewire 1.6.5
• librsvg 2.62.2
• PostgreSQL 18.4

La siguiente snapshot (0514) ya está en control de calidad y, a menos que surja algún problema, debería publicarse hoy mismo.

Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:

• Agama 21
• Gcc16
• Poppler 26.05.0

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–