Fieles a los periodos cuatrimestrales que los propios desarrolladores se han marcado, acaba de ser anunciado el calendario de lanzamientos KDE Gear 26.04, el síntoma inequívoco de la continua evolución de la Comunidad KDE y su compromiso por la constancia y mejora continua.

Tener un plan de trabajo pre-establecido es algo fundamental para que los equipos funcionen. Este calendario de trabajo debe contener la respuesta a dos preguntas muy explícitas: qué hay que hacer y cuándo debe estar hecho. Además, en sus aplicaciones internas se responde a otra pregunta que también es sumamente importante: quien lo va a hacer.

Esta metodología de trabajo la tienen perfectamente clara y establecida los desarrolladores de KDE que, como viene siendo habitual, no solo se lo marcan en sus agendas sino que lo hacen público. De hecho, esta entrada es un calco de la que hice hace ya mucho tiempo con KDE Aplicaciones 20.04, KDE Gear 23.08, KDE Gear 25.04, etc.

Calendario de lanzamientos KDE Gear 26.04 de KDE

Si tenéis un calendario a mano y tenéis interés en los lanzamientos de KDE Aplicaciones os aconsejo que  anotéis en él las fechas principales de lanzamientos de KDE Gear 26.04. Hay que destacar que en esta ocasión se ha querido simplificar mucho el proceso en aras de ser más claros y efectivos. En anteriores lanzamientos ha resultado bastante acertado.

De este modo tenemos:

• Jueves, 5 de Marzo de 2026:  Congelamiento de KDE Gear 26.04, marcado y lanzamiento de la primera beta
• Jueves, 27 de Marzo de 2026: Marcado y lanzamiento de KDE Gear 26.04 RC (Versión Candidata)
• Jueves, 9 de Abril de 2026 Marcado de KDE Gear 26.04
• Jueves, 16 de Abril de 2026: Lanzamiento de KDE Gear 26.04 definitivo

En fin, un equipo incansable que nos ofrece la colección de aplicaciones más útil, integradas y funcionales para el escritorio libre más bello, funcional y dinámico que puede habitar en tu PC o portátil… y esperemos que pronto en otros dispositivos.

Más información: KDE Techbase | TSDgeos’ blog

La entrada Calendario de lanzamientos KDE Gear 26.04 de KDE se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Completion of systemd v258 Code Review
• 3) D-Bus Issues in Unreleased plasma-setup KDE Package
  • org.kde.initialsystemsetup.createnewuserautostarthook
  • org.kde.initialsystemsetup.setnewuserhomedirectoryownership
  • org.kde.initialsystemsetup.setnewusertempautologin
  • Upstream Fixes
• 4) Discussion about Granting setgid Privileges to the plocate Binary
• 5) Local Root Exploit in OpenStack’s non-production virtualbmc Project
  • Lack of Authorization and Input Validation in vbmcd
  • Reproducer
  • Further Concerns
• 6) Revisit of the snapd Package Manager
• 7) Conclusion

1) Introduction

The winter season has already begun for most of the people in our team and with the Christmas holidays behind us, which granted us some well-earned rest, we want to take a look back at what happened in our team during the autumn months. During this time we already published a few dedicated review reports:

• trivial local Denial-of-Service in the OpenSMTPD mail transfer agent.
• unauthenticated D-Bus API in the scx scheduler project allowing for a major local Denial-of-Service.
• minor privilege escalation from lightdm to root in lightdm-kde-greeter leading to major improvements of its D-Bus code.
• major local vulnerabilities in the D-Bus interface of smb4k, resulting in upstream fixing a series of long-standing issues in the affected component.

In this post, as usual in the spotlight series, we will look into some topics that did not justify dedicated reports. First we will discuss our continued efforts to review privileged components found in the systemd v258 release, which involved diving deep into some low-level aspects of the Linux kernel API. Section 3 looks at D-Bus issues we found in plasma-setup, a new component for the KDE desktop. Section 4 covers recent discussions about granting special setgid permissions to the plocate package. Section 5 gives insight into security issues found in the virtualbmc OpenStack project, which turned out to be for testing purposes only. Section 6 discusses revived efforts to bring the Snap package manager to openSUSE.

2) Completion of systemd v258 Code Review

We already discussed our systemd v258 review efforts in the previous spotlight edition. At the time we found a local root exploit in the systemd-machined API, which could be fixed before the final release of v258. For the addition of this new major version of systemd to openSUSE Tumbleweed, we still needed to look more closely into a number of other D-Bus and Varlink services that have been added.

During autumn we completed the review of changes in systemd-mountfsd and systemd-nsresourced. Some of the changes introduced with these services allow unprivileged users to perform a number of container-related operations without requiring special privileges.

The io.systemd.MountFileSystem.MountDirectory API call in mountfsd, for example, allows to obtain a mount file descriptor for a directory owned by the calling user, on which a user and group ID mapping is applied corresponding to a user namespace file descriptor also owned by the caller. Some newer, little-known Linux system calls like open_tree() and mount_setattr() are used to achieve this. This niche topic and the low-level nature of the involved APIs result in quite complex code which needed careful reviewing. We are happy to report that we could find no issues in this area, however.

The nsresourced service, among other features, allows unprivileged users to obtain a dynamic range of user and group IDs for use with user namespaces. The tools newuidmap and newgidmap already allowed this for a longer time based on static configuration files. The nsresourced service applies dynamic limits and ID ranges to processes in the system, however, which makes things quite more complicated. This even includes an EBPF program, which keeps track of the uses of the resulting user namespace file descriptors. Despite this complexity we could not find any issues in this component either.

What kept us busy for a longer time was logic invoked by mountfsd to obtain the user and group ID mapping tied to the user namespace file descriptor passed by the unprivileged client. To retrieve this information, the utility function ns_enter_and_pin() forks a short-lived child process which joins the user namespace provided by the client. The parent process then reads the child’s uid_map and gid_map nodes from /proc/<child-pid>.

The mountfsd daemon runs with root privileges (although some sandboxing is applied to it as well), which will be inherited by the short-lived child process. Once the child process joins the user namespace provided by the unprivileged client, the security domain of this process changes, however, because the client owning the namespace is supposed to have full control over processes associated with it.

One consequence of this is that the owner of the user namespace can send arbitrary signals to the short-lived systemd process, e.g. to kill it. This would only result in a kind of Denial-of-Service against the client itself and should not cause any security issues.

We expected another important ramification of this to be in the area of the ptrace() system call. The following is stated in the “ptrace access mode checking” section of the ptrace(2) man page:

(3)  Deny access if neither of the following is true:

            •  The real, effective, and saved-set user IDs of the target
               match the caller's user ID, and the real, effective, and
               saved-set group IDs of the target match the caller's group
               ID.

            •  The caller has the CAP_SYS_PTRACE capability in the user
               namespace of the target.

According to the second item, the unprivileged client, which owns all capabilities in its user namespace, should be able to trace the short-lived systemd process which joins the client-controlled user namespace. This ability would have allowed for an interesting privilege escalation, because tracing capabilities also include the ability to modify the target process, e.g. to change its code and data. While trying to reproduce this, the kernel always denied ptrace() access to this short-lived process, however, and we were not sure why. Unclarity in such aspects is not a good thing when it concerns security, thus we set out to get to the bottom of this.

After diving deep into the Linux kernel’s ptrace() code, we found the commit which is responsible for the rejection of tracing access in this scenario. The background of this commit actually is to prevent owners of unprivileged user namespaces from accessing the executable of processes created in the initial namespace. ptrace() access to the target PID is now only allowed if the target process performed an execve() while being a member of the newly joined user namespace. In summary this means the following:

• if a process only performs fork() and setns() to join a user namespace, then ptrace() access to this process is denied to the owner of the user namespace.
• if a process performs fork(), setns() and execve(), then ptrace() access to this process is granted to the owner of the user namespace.

This detail is not documented in the ptrace() man page and it took us a while to fully understand what was going on. With this well understood we could finally move on, knowing that the logic in mountfsd is robust.

3) D-Bus Issues in Unreleased plasma-setup KDE Package

This new KDE component was first named KISS (KDE initial system setup), but meanwhile has been renamed to plasma-setup. Its purpose is to perform initial system configuration based on a graphical wizard, when a Linux system has been freshly installed.

Our openSUSE KDE packagers asked for a review of this new component, expecting it to be part of a major KDE release in autumn. It turned out that this had not been planned by upstream after all (or plans changed). Still the review we performed turned out to be useful, since we identified various security problems in the existing code which could be fixed by upstream before the new component had seen production use.

The following report is based on the plasma-setup source code as of upstream commit 08ed810e0e7. While the graphical components of plasma-setup run with low privileges, there exists a D-Bus helper service running as root, kde-initial-system-setup-auth-helper, which allows to perform a number of operations with elevated privileges. These operations are guarded by Polkit authorization rules. The dedicated user account kde-initial-system-setup is allowed to invoke any of these actions without authentication. Beyond this, any locally logged-in users are also allowed to invoke the operations without authentication. The latter is quite problematic, as will be outlined below.

The implementation of the D-Bus callbacks for these actions is found in src/auth/authhelper.cpp. The following sub-sections discuss issues in a couple of these actions.

org.kde.initialsystemsetup.createnewuserautostarthook

This action receives a “username” parameter from the unprivileged D-Bus client. The username is not verified by the privileged helper, it only needs to be convertible to QString. The helper then creates all the directory components of /home/<username>/.config/autostart. After this, the file /home/<username>/.config/autostart/remove-autologin.desktop is created and fixed data is written into it.

This action allows local users to create arbitrary world-readable directories owned by root. This can be achieved by passing a string like ../../my/desired/path as “username”. Furthermore, by placing a symlink at the expected location of remove-autologin.desktop, arbitrary files in the system can be overwritten, leading to a local Denial-of-Service.

The implementation of the action also causes the created directories and files to be owned by root:root, and not by the user that actually owns the home directory, which is unclean.

Suggested Fixes

Apart from restricting access to the helper to the kde-initial-system-setup user, the implementation of this action should verify whether the passed-in username actually exists. Furthermore, the home directory of this account should be obtained via the getpwent() API, instead of assuming that /home/<username> will always be the correct home directory.

When the execution of this helper is actually limited to the initial setup context, it could be technically acceptable to operate as root in the newly created user’s home directory. For reasons of prudence and giving a good example, we still recommend to drop privileges to the target user account before actually writing the .desktop file in the user’s home directory.

org.kde.initialsystemsetup.setnewuserhomedirectoryownership

The method call associated with this action also receives a “username” parameter which is not verified. The following command line is invoked based on the “username” parameter:

chown -R <username>:<username> /home/<username>

This is on the verge of a local root exploit, save for the fact that chown expects a valid user and group account to give the ownership to, which at the same time needs to result in the proper path to operate on. A username containing path elements will fail, because the necessary characters like / are by default denied in usernames.

This action still allows to potentially change ownership of all files of arbitrary other users’ home directories. Fortunately the recursive chown algorithm is not subject to symlink attacks these days. If somebody would be able to place a symlink in place of their home directory in /home/<username>, then the symlink would still be followed, however.

The username could also be interpreted as an arbitrary command line argument to chown, thwarted only by the fact that the <username>:<username> argument is constructed here instead of just passing <username>, which will prevent proper command line arguments from being passed.

Suggested Fixes

As for the previous action, the implementation should verify if the username is valid and determine the proper home directory and group via getpwent(). The assumption that username and group are equivalent is also problematic here.

Why this operation would be needed at all for a newly created home directory is questionable. When new user accounts are created, file ownership should already be correct. If this action is supposed to fix the ownership of files created by other plasma-setup actions in the home directory as root (as is seen in the createnewuserautostarthook action), then this is only a hack which should be removed in favor of not creating files as root in unprivileged users’ home directories in the first place.

org.kde.initialsystemsetup.setnewusertempautologin

Again this method receives a “username” parameter which is not verified. The implementation writes the following content to the file /etc/sddm.conf.d/99-kde-initial-system-setup.conf:

[Autologin]
User=<username>
Session=plasma
Relogin=true

This SDDM configuration snippet is supposed to automatically login the given user account. For some reason that we did not investigate more deeply, the configuration was not effective during our tests on openSUSE Tumbleweed. We could verify that the configuration file created this way was parsed and evaluated in SDDM, however, so something else must have been amiss.

The automatic login is supposed to work, though, and if it does, then any local user account can call this action with root as username, which should cause an automatic login of the root user the next time SDDM runs.

By passing crafted strings for “username”, the content of the drop-in configuration file can even be fully controlled by local users. The following “username” would create a General section with a crafted “RebootCommand”, for example:

user\n[General]\nRebootCommand=/home/myuser/evil

Provided the configuration snippet is actually in effect in SDDM, this action allows for a local root exploit.

Suggested Fixes

As for the other actions, the implementation should verify whether the passed “username” is valid and does not equal root.

Upstream Fixes

We privately approached KDE security on 2025-09-22 with a detailed report about these findings. As a result we established contact with the plasma-setup developer and discussed fixes for the issues. It was decided to perform the bugfix in the open, since the component was not yet part of a stable release of KDE. We reviewed an upstream merge request during the course of two weeks and upstream managed to arrive at a much improved version of the KAuth helper component.

As of commit e6eb1cd9a8d the privileged helper carefully scrutinizes the input parameters received via D-Bus, and it also drops privileges to the calling user before operating in the unprivileged user’s home directory. Also the KAuth actions provided by the helper are now restricted to the plasma-setup service user and no longer accessible to all locally logged-in users. The latter would still be problematic, since it would allow to setup automatic login for arbitrary other users in the system, for example.

4) Discussion about Granting setgid Privileges to the plocate Binary

An openSUSE community member approached us about granting special setgid privileges to the plocate binary. plocate is a modern and fast replacement for the classic locate program. Upstream supports operation of the plocate program with the setgid bit assigned to the plocate group. This means that the program is granted plocate group privileges during execution.

When updatedb, locate’s utility for indexing files, would be invoked with full root privileges, then the database in /var/lib/plocate would contain information about all files in the file system. This way locate would grant all users in the system read access to this information, resulting in an information leak, because users can see paths that they would not normally be allowed to list, like all the files stored in the /root home directory. For this reason the plocate-updatedb system service on openSUSE Tumbleweed runs as nobody:nobody, resulting in a system-wide plocate database which only contains information about publicly accessible paths in the system. For being able to locate their own private files, users need to create their own user-specific databases instead.

The purpose of the setgid privilege is to address this locate database access issue. plocate supports a mode in which updatedb is invoked with full root privileges, but the ownership of the central database is changed to root:plocate and file mode 0640. When plocate is installed as setgid-plocate then it is still allowed to access the central database. The program drops the special group credentials quickly again, right after opening the database. The program then ensures that the calling user will only be able to retrieve information about files that it is allowed to access based on its real credentials.

There is a minor security issue found in this approach. Since the plocate database does not contain metadata about the files it indexed, the plocate program needs to check the ownership of files in the file system at the time the search query runs. This is a sort of a TOCTOU (time-of-check time-of-use) race condition. There can be situations when the verification in plocate yields wrong results:

root# mkdir --mode=1777 /shared
root# mkdir --mode=0700 /shared/secret-dir
root# touch /shared/secret-dir/secret-file
root# updatedb

# root will be able to locate any files in secret-dir
root# locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

# non-root cannot locate the secret-file
user$ locate /shared/se
/shared/secret-dir

# now consider root deletes the secret-dir again
root# rm -rf /shared/secret-dir

# now the unprivileged user takes ownership of this path
user$ mkdir --mode=0755 /shared/secret-dir

# this only works before `updatedb` is called again, because then it will
# notice that secret-file no longer exists and delete it from the database.
#
# when the unprivileged user calls locate this time, the secret-file will show
# up, since the "secret-dir" is now controlled by the unprivileged caller.
user$ locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

This problem likely cannot be easily fixed in the plocate code, since it would require changing the database format radically, increasing database size as a result, only to fix an unlikely problem.

The information leak is minor and should rarely be exploitable. For this reason we left it up to the openSUSE plocate package maintainer whether the setgid-plocate approach should be used, or not.

5) Local Root Exploit in OpenStack’s non-production virtualbmc Project

By way of our efforts to monitor newly introduced systemd services in openSUSE Tumbleweed, the python-virtualbmc package caught our attention. The program allows to emulate a board management controller (BMC) interface for use with libvirt.

Part of the package is a daemon running with full root privileges, listening for ZeroMQ API requests on localhost. A number of unauthenticated API calls in this context raised our suspicions, which is why we scheduled a full review of this package. A closer look showed that the unauthenticated API calls were indeed problematic, even allowing for a full local root exploit.

We filed a detailed private bug report on LaunchPad for the OpenStack project, but had difficulties getting a response. After some weeks we reached out to an individual member of the OpenStack security team and learned from the reply that the virtualbmc project was not intended for production use at all, but is rather a utility intended for use in testing environments. This is also documented in the repository’s README, which was overlooked by us. As a result we filed a delete request for the python-virtualbmc package in openSUSE Tumbleweed, and the package has already been removed.

For completeness, a detailed report of the security issues in the virtualbmc daemon follows below.

Lack of Authorization and Input Validation in vbmcd

When the virtualbmc systemd service is started, then /usr/bin/vbmcd runs with full root privileges. It offers a ZeroMQ-based network API, listening on localhost port 50891 by default. Any local user in the system can talk to the daemon this way.

A simple request which can be sent to the daemon (in JSON format) is the following stop command, for example:

{
        "command": "stop",
        "port": 1234,
        "domain_names": ["../../home/myaccount/mydomain"],
}

The domain_name passed here will be used by the daemon to lookup a supposedly trusted per-domain configuration file, which is by default located in /root/.vbmc/<domain>/config. Since the daemon does not scrutinize the input domain_name, a local attacker can include directory components in the name, to trick the daemon into accessing an attacker-controlled configuration file.

In the context of the stop command used here, the daemon will try to update the domain’s configuration file in case a change of domain state is detected. The path for writing out the updated configuration file will be constructed using the domain_name found in the input configuration file. Thus the local attacker can place data like this into /home/myaccount/mydomain/config:

[VirtualBMC]
domain_name = ../../etc/sudoers.d
port = 1234
active = true
address = some
  evil stuff
  myaccount ALL=(ALL:ALL) NOPASSWD: ALL

The daemon will now believe that the domain’s state changed, because the input configuration file contains active = true, while the daemon was asked to stop the domain. This will trigger logic to write out an updated configuration file with the new state of the domain configuration. The logic for this is found in the _vbmc_enabled() member function.

Since the domain_name found in the crafted configuration file is set to ../../etc/sudoers.d, the daemon will write the new configuration file into /root/.vbmcd/../../etc/sudoers.d/config. To get an advantage from this, the attacker must get the daemon to write out at least one valid sudoers configuration line into the new configuration file.

The attacker has only a limited degree of freedom at this stage, because the daemon will write out the new configuration file via the Python configparser module and will only consider the [VirtualBMC] section as well as any of the configuration keys listed in the VBMC_OPTIONS list defined in the daemon’s code.

To help with the exploit, the configparser multiline syntax comes to the rescue: any lines following an assignment which are indented will be accepted as part of the configuration value. When writing the settings out to a new configuration file, these multiline settings will be preserved. This is put to use in the example above, which contains a final line myaccount ALL=.... This line will now appear along with the rest of the configuration data in /etc/sudoers.d/config.

As a result, when the attacker now invokes sudo su -, a couple of sudoers parsing errors will appear, but in the end, access is granted and a root shell will be obtained by the attacker.

This approach of using a sudoers drop-in configuration file is just one of the more obvious approaches that came to mind. There’s a lot of different ways to exploit this, however, for example by overwriting shell scripts or script snippets in /etc or /usr/bin and then waiting for a privileged process to run them. This would be even easier, because shell scripts have less strict syntax requirements compared to the sudoers configuration file. The effect would not be immediate, however, like in the sudoers approach.

Reproducer

We offer a Python script for download, which is a Proof-of-Concept (PoC) to reproduce the local root exploit in the context of an arbitrary unprivileged user on the system, when vbmcd is running with its default configuration. sudo needs to be installed, naturally, for the exploit to work.

Further Concerns

In general, the API offered by vbmcd on localhost is missing input sanitization and authorization. Authorization seems only to be performed indirectly via libvirt. In this context clients can also pass crafted libvirt_uri parameters, for example, which seem to make it possible to let the daemon connect to arbitrary URLs via SSH. There also is no isolation between different users’ domain configurations, e.g. the “stop” command used above can be issued for any domain configured by another user in the system.

To make this API safe, we believe there needs to be an ownership model for each domain’s configuration, a verification of the client’s credentials in some form (a UNIX domain socket would allow this more easily) and sanitization of all input parameters to avoid any unexpected side effects.

Since the daemon listens on an unprivileged port on localhost, other unprivileged users can try to bind to this port first and provide a fake vbmcd service. Since the API requests can also contain secret credentials, this would pose a major local information leak. For safe operation, the API would need to bind to a privileged port on localhost instead.

6) Revisit of the snapd Package Manager

In 2019 we received a request to add the snapd package manager to openSUSE, which involved a review of the setuid-root program snap-confine. At the time we were generally satisfied with the code quality and design of the program, but still found a few low to medium severity security issues and gave recommendations on how to improve the code in some spots. The packagers have meanwhile been busy with other topics and we never saw an updated openSUSE package containing the necessary changes, which is why we closed the related bugs after a period of inactivity.

In August we received a follow-up request for addition of an updated snapd package. We revisited the privileged components and again provided feedback to upstream. This time all remaining issues could be resolved and the new package has been allowed to become part of openSUSE Tumbleweed. We are happy to see these old efforts not going completely to waste, and welcome the possibility to use Snap packages on openSUSE Tumbleweed in the future.

7) Conclusion

Again we hope we’ve been able to give you some additional insight into our efforts to maintain the security of SUSE distributions and open source software. We are looking forward to the next edition of the spotlight series, which will be published in about three months from now.

Hoy ha sido lanzada la beta de Plasma 6.6. Así que, para los que disfruten de probar cosas nuevas es el momento de probar esta versión y reportar los errores que se encuentren. ¡No pierdas la oportunidad de contribuir al desarrollo de Plasma!

Lanzada la beta de Plasma 6.6

Tras los habituales meses de vida, Plasma 6.5 empieza ver languidecer su reinado. Es el momento de probar la versión de escritorio que la va a sustituir. En otras palabras, ha sido lanzada la beta de Plasma 6.6 y estas son algunas de sus mejoras extraídas de los artículos «Esta semana en Plasma»

• Inhibición de suspensión con mando: el sistema ya no entrará en modo de suspensión ni bloqueará la pantalla automáticamente mientras estés usando un controlador de videojuegos.
• Soporte nativo para sensores de luz ambiental: en los portátiles modernos (como el Framework 13 o equipos con AMD Ryzen) ahora pueden ajustar el brillo de la pantalla automáticamente según la luz de la habitación.
• Mejoras críticas en HDR: se han corregido problemas de color en juegos de Windows ejecutados a través de Wine, Proton y Steam Play, logrando que el HDR se vea con la fidelidad esperada.
• Conexión WiFi mediante código QR: ahora se puede escanear un código para conectarse a una red inalámbrica sin escribir contraseñas.
• Teclas Lentas (Slow Keys) en Wayland: implementada esta función de accesibilidad que permite definir cuánto tiempo se debe mantener pulsada una tecla para que sea válida, evitando pulsaciones accidentales.
• Efecto Zoom con puntero centrado: ahora el efecto de lupa ahora incluye un modo donde el puntero siempre se mantiene en el centro físico de la pantalla, evitando la desorientación en monitores grandes.
• Acciones globales multimedia: se han añadido nuevos atajos configurables para avanzar o retroceder (5 o 30 segundos) en cualquier reproductor multimedia compatible con el protocolo MPRIS.
• Fijación de widgets (Pins): los widgets de «Navegador Web» y «Volumen de Audio» ahora incluyen un botón de chincheta para mantener sus ventanas emergentes abiertas mientras interactúas con ellas.
• Reflejo de pantalla (Mirroring) robusto: soporte para duplicar pantallas en Wayland ha sido rediseñado para ser fluido y fiable, eliminando los fallos visuales de versiones anteriores.
• Tono de piel en Emojis: el selector de emojis permite ahora predefinir un tono de piel preferido para todos los emojis de personas y manos, evitando tener que elegirlo manualmente cada vez.

Si queréis la lista de cambios completa solo tenéis que ver el changelog.

Más información: KDE

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 6.6 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

La entrada Lanzada la beta de Plasma 6.6 se publicó primero en KDE Blog.

Me alegra compartir con todos vosotros la quinta actualización de Plasma 6.5, finalizando así una serie de revisión de software que ha dotado de más estabilidad, mejores traducción y resolución de errores este entorno de trabajo. 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.

Quinta 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 13 de enero de 2026, varios meses después de liberar el código de Plasma 6.5 , la Comunidad KDE presenta su quinta 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 Quinta actualización de Plasma 6.5 se publicó primero en KDE Blog.

While testing the latest Elasticsearch release with syslog-ng, I realized that there was already a not fully documented elasticsearch-datastream() driver. Instead of fixing the docs, I reworked the elasticsearch-http() destination to support data streams.

So, what was the problem? The driver follows a different logic in multiple places than the base elasticsearch-http() destination driver. Some of the descriptions were too general, others were missing completely. You had to read the configuration file in the syslog-ng configuration library (SCL) to configure the destination properly.

While preparing for syslog-ng 4.11.0, the OpenSearch destination received a change that allows support for data streams. I applied these changes to the elasticsearch-http() destination, and did a small compatibility change along the way, so old configurations and samples from blogs work.

Read more at https://www.syslog-ng.com/community/b/blog/posts/changes-in-the-syslog-ng-elasticsearch-destination

Este juego multiplataforma de coches, derrapes, y carreras ha llegado a la versión 1.0.0 con nuevos circuitos, nuevos coches y control en las carreras

Después de un tiempo sin nuevos lanzamientos (la anterior versión 0.26 es de septiembre de 2024) Aurelien Gateau, el desarrollador del juego, ha publicado el pasado 21 de diciembre de 2025 la versión 1.0.0 de PixelWheels, un juego de carreras de coches muy divertido y adictivo.

Carreras, derrapes, giros vertiginosos, diferentes tipos de coches para escocger y mucho más en un juego con aire retro que puedes disfrutar en tu PC (Linux, MacOS y Windows) y en tu sistema Android.

Lo primero a destacar en este nuevo PixelWheels 1.0.0 es que consta de 3 niveles de dificultad, llamados Ligas: Casual, Pro y Legendario. La principal diferencia entre ellos es la velocidad a la que pueden conducir los vehículos.

«Legendario» es la velocidad a la que conducían los vehículos hasta ahora. «Pro» es un poco más lento. «Casual» es el más accesible. Con estas novedades, el desarollador espera que esto haga que el juego sea menos frustrante para los nuevos jugadores, hasta que desarrollen la habilidad suficiente para mantener el coche en la carretera sin problema.

Además continuando con el tema de hacer que el juego sea más agradable de jugar, también ha ajustado la configuración de dirección, aceleración y turbo para que los vehículos sean más fáciles de controlar.

Además se ha añadido algún coche nuevo para escoger a la hora de correr. Pero para tener todos esos coches didponibles, tendrás que ir desbloqueándolos para ponerte al volante de coches míticos.

Si te animas a jugarlo puedes hacerlo obteniéndolo para diferentes plataformas. Puedes tenerlo disponible desde Flathub, itch.io, F-droid o Google Play, para diferentes plataformas.

Tienes el anuncio oficial con más detalles y enlaces a las diversas plataformas:

• https://agateau.com/2025/pixelwheels-1-0/

El juego está publicado bajo una licencia GPL 3.0 y alguna otra licencia libre. Y está disponible en diferentes idiomas, entre ellos el español, ya que desde hace tiempo colaboro manteniendo la traducción del juego al español.

¿Quieres tenerlo disponible en otro idioma y colaborar con la traducción? No dudes en contactar con el desarrollador para hacerle llegar tu petición o hacerle un pull request en su repositorio en GitHub.

A la hora de publicar este artículo ya se ha publicado la versión 1.0.1 con alguna corrección menor.

¡Descarga el juego y haz chirriar los neumáticos sobre el asfalto!

Enlaces de interés

• https://agateau.com/projects/pixelwheels/
• https://agateau.com/2025/pixelwheels-1-0/
• https://agateau.com/projects/pixelwheels/#get-it
• https://github.com/agateau/pixelwheels
• https://github.com/agateau/pixelwheels/releases

Estas navidades apenas he hablado de la parte lúdica de Linux, solo dediqué una entrada repasando las novedades de Heroic. Hora de enmendar este error presentando un vídeo con 3 juegos nativos RTS para linux que demuestra que no solo se puede jugar sino que además, se puede hacer de forma 100% libre.

3 juegos nativos RTS para linux

De la mano de Planeta Tecno os presento el siguiente vídeo donde nos presenta 3 juegos RTS excelentes para instalar de forma nativa en Linux. Para los que no lo sepan, RTS es el acrónimo de Real Time Strategy, o Estrategia en Tiempo Real para los que no les gusta la imposición anglosajona.

Se trata de Wazone 2100, OpenRa y 0 A.D. (Zero A.D.), los dos últimos han aparecido en el blog, en la serie Juegos Linux del blog, así que ya tengo objetivo para analizar a fondo con el primero.

Como es habitual en este tipo de juegos están disponibles en múltiples formatos: flatpak, snap, deb y en código fuente. Además, los chicos de Planeta Tecno (que además tienen una web) comentan que estos juegos funcionan perfectamente incluso en equipos antiguos (portátil de hace 13 años, por ejemplo) y son una excelente opción para quienes buscan estrategia clásica sin costo en Linux, manteniendo su dispositivo alejado de software privativo.

Sin más, os dejo con el vídeo.

Aunque he dicho arriba que he dedicado artículos a dos de ellos no me resisto a poner una breve reseña de cada uno de ellos:

Warzone 2100

Tras un desastre nuclear, los jugadores lideran «El Proyecto» para recuperar la tecnología y reconstruir el orden mundial frente a facciones enemigas. Este juego está realizado en 3D, con lo que podemos llegar a tener un gran nivel de zoom.

Una de sus características más destacadas es su árbol tecnológico con más de 400 tecnologías combinables, lo que permite crear unidades personalizadas y variadas.

OpenRA

En realidad no es un solo juego, sino un motor que incluye «mods» oficiales que recrean clásicos de la estrategia con mejoras para sistemas modernos.

De esta forma nos encontramos con la posibilidad de jugar a clásicos como:

• Red Alert: Basado en una realidad alternativa donde la Unión Soviética expande su poder tras la desaparición de Hitler.
• Tiberian Dawn: El clásico Command & Conquer original
• Dune 2000: Basado en el universo de la novela Dune

Las ventajas de utilizar este motor es que mejora los gráficos originales (estilo 2.5D), corrige errores de compatibilidad y tiene una comunidad muy activa que organiza torneos multijugador.

0 A.D. (Zero A.D.)

Este proyecto está considerado un «juego insignia» de Linux, siendo muy similar a la saga Age of Empires pero desarrollado de forma abierta por la comunidad, de forma que es software libre, multiplataforma y tiene un sistema de Inteligencia Artificial (Petra Bot) que aprende del estilo del jugador.

En el juego podemos manejar civilizaciones antiguas (500 a.C. al 500 d.C.: Helenos, Imperios Diádocos, Celtas, Romanos, Persas, Íberos, etc.) y destacando por su excelente calidad gráfica y atención al detalle.

Recientemente ha mejorado mucho su modo campaña para un solo jugador y, para finalizar, comentar que existen mods oficiales y de la comunidad (como Millennium AD o Han Ascendant) que añaden civilizaciones adicionales como los Han (Chinos), los Zapotecas o facciones de la Edad Media.

Contribuye al avance del Software Libre: difunde el conocimiento

Si os gusta el vídeo no dejéis pasar la oportunidad de pagar a su creador Planeta Tecno, en esta ocasión, utilizando las forma que te permite la plataforma de vídeos Youtube:

• Subscríbete a su canal.
• Ponle un comentario
• Comparte en redes sociales
• O cualquier otra forma que se te ocurra.

Hoy es un buen día para insistir que ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

La entrada 3 juegos nativos RTS para linux se publicó primero en KDE Blog.

¿Necesitas configurar un temporizador para recordarte una tarea? ¿Necesitas una alarma diaria? ¿Necesitas saber la hora local y de otras localizaciones? Con Plasma de KDE estás cubierto

Estaba cocinando mientras estaba con el portátil, echo lo necesario a la olla a presión, cierro y en 20 minutos debería estar listo. No quería que me pasara que el timeline de Mastodon me hiciera perder la noción del tiempo y que se me pasara más tiempo del necesario echando a perder la comido o algo peor…

Quise establecer un temporizador que me recordara en mi portátil que en 20 minutos tenía que hacer caso a la olla. Algo tenía que haber seguro. Así que tras una breve búsqueda por la red encontré Kclock que hacía justamente lo que quería… y ¡mucho más!

Kclock (¿de verdad no se puede cambiar el nombre de la aplicación a algo como Klock, que empieza por K y no es tan extraño?) es una aplicación de KDE que nos ofrece un reloj y muchas cosas más.

Para instalarlo en openSUSE con un simple sudo zypper in kclock es suficiente. Nos instala el propio paquete y el de idiomas y ya está disponible en nuestro sistema. Lo buscamos en el menú de aplicaciones, pero con el nombre reloj (¿?), y lo ejecutamos.

Hora

Lo primero que nos aparece es una ventana con la hora local de nuestro sistema. Y además podemos añadir horas de otros países muy útil si por nuestro trabajo o por necesidad necesitamos saber la hora de diferentes usos horarios.

Temporizador

En otra pestaña podremos configurar diferentes temporizadores (¡lo que buscaba!). Añadimos un nuevo temporizador y podremos escoger entre valores ya preconfigurados: 1, 5, 10, 15, 30 minutos, o adaptarlo al tiempo que queramos. También podremos ponerle un nombre, por ejemplo: «¡Retirar la olla del fuego!».

Establecido el temporizador podremos iniciarlo cuando lo queramos y al término del tiempo configurado saldrá una notificación y un sonido para indicarnos el fin.

Lo bueno es que aunque cerremos la aplicación, el temporizador que esté iniciado continuará su cuenta atrás. Otra cosa buena es que el temporizador que hemos creado se queda disponible para ponerlo en marcha cuando lo necesitemos de nuevo. Y si no lo queremos reutilizar siempre lo podremos borrar.

Cronómetro

También podremos poner en marcha un cronómetro si lo necesitamos. Que se puede también manejar con el teclado. Podremos ponerlo en marcha, pausarlo o gestionar diferentes tiempos parciales siguiendo con el total.

Alarmas

En un portátil quizás no tiene mucho sentido, pero también podremos establecer alarmas que sonarán a la hora especificada el día seleccionado. Igual que las alarmas que configuramos en nuestros dispositivos móviles para que nos despierten.

Podremos configurar la hora, el día, el modo de posponerla, etc.

Realmente era lo que estaba buscando y no sé cómo es que Plasma no incluye esta aplicación de manera predeterminada.

Una cosa que me confunde bastante y que envié un correo a sus desarrolladores es el nombre. Partiendo de que Kclock creo que habría que cambiarlo, pero no es a eso a lo que me refiero.

Me refiero a que hay un poco de lío con el nombre en general. Si lo busco en los repositorio para instalarlo debo buscar por Kclock. Al buscarlo en el menú de aplicaciones debo buscarlo como reloj. Y una vez lanzado, en la barra de títulos superior el nombre de la aplicación es clock. ¿Vaya poca consistencia, no?

Pues eso, que si necesitas un temporizador o una alarma o un cronómetro en Plasma de KDE con Kclock tienes todo lo que necesitas.

Enlaces de interés

• https://cubiclenate.com/2024/11/16/clock-from-the-kde-community/

A photo posted to Reddit and followup media coverage about computers being discarded in large amounts due to software policies should ignite public concern on the use of taxpayer money being used responsibly.

The image shows a large pallet of PCs that were thrown out because they were not upgraded to a newer operating system.

The post highlights a growing concern among critics of government technology policy where public hardware is being retired not because it has failed, but because it no longer aligns with policy requirements.

Seeing stacks of computers that are still capable of using Linux operating systems like openSUSE and others raises a lot of questions about how tax money is being spent, especially in a country with uncontrollable runaway debt ($38.6 trillion at the time of publication). Migrating to open-source solutions could be an easy win for cost savings and government efficiency. The Government Accountability Office (GAO) report notes the federal government spends more than $100 billion annually on IT and cybersecurity, which includes thousands of software licenses that do not isolate Windows alone.

Extended support for Windows 10 ends on Oct 13, 2026, according to endof10.org. End of 10 is an information campaign focusing on reducing unnecessary e-waste driven by software policy decisions.

The image illustrates how public policy choices can contribute to waste of taxpayer funds even when they appear in the form of discarded hardware. Serviceable computers are being retired not because they are broken, but because public institutions are locked into closed, inflexible software decisions.

Advocates for fiscal responsibility can point to Europe’s Public Money, Public Code principle, which is championed by the Free Software Foundation Europe, as an example to emulate. The Public Money, Public Code effort began as an information campaign that argued publicly funded software should remain open, adaptable and reusable, which extends the useful life of public hardware.

Supporters of the approach say open, publicly owned code can reduce costs by allowing agencies to reuse software rather than rebuilding similar systems repeatedly. They also argue that shared development spreads costs across governments, improves transparency through independent review, and extends the useful life of computer hardware.

A Federal Source Code Policy directed US agencies in 2016 to release at least some custom code as open source, but it has not mandated an “open-by-default” approach to mirror the logic of Public Money, Public Code.

This lack of policy further extends government debt and enriches shareholders through transferring wealth from the taxpaying public to private equity shareholders.

Though the Public Money, Public Code campaign originated in Europe, its goals can resonate with the taxpaying voter and it is a more responsible approach for the environment and usage of taxes. Environmental advocates like Joanna Murzyn, who spoke at the KDE Akademy conference in 2024, warns about the increasing problem of electronic waste (e-waste). Analysts are estimating that tens of millions of PCs are being scrapped as a result of software lifecycle decisions, which are equally reflected in government policies.

E-waste, which includes discarded laptops, desktops and other electronics, releases toxic substances like lead, mercury and cadmium into the environment, according to Murzyn. These substances can contaminate soil and water as well as cause long-term harm to ecosystems and human health. Murzyn urged people to resist the urge to “upgrade” to new hardware and instead explore solutions like Linux that extend the life of existing devices.

Join End of 10 to learn how extending the life of existing computers can reduce waste, lower public costs and promote more responsible technology policies.

This is part of a series on End of 10 articles where we offer reasons to transition from Windows to Linux.

La desaparición del soporte de Windows 10 es una gran oportunidad para que los usuarios vean la luz y se pasen a GNU/Linux. La Comunidad no es ajena a este hecho y no paran de organizar jornadas como las que comparto hoy. Si estás por Almería el lunes 19 de enero en El Ejido que se celebra un taller que tiene por título «Actualiza tu Windows 10, cambia a GNU/Linux». Concretamente a las 19 horas en el Centro Asociativo Municipal. ¡No te lo pierdas!

Actualiza tu Windows 10, cambia a Linux

Para los que todavía no lo sepan, el soporte de Windows 10 finaliza el 13 de octubre de 2026. Eso significa que tu ordenador va a necesitar actualizarse ya que de no hacerlo va a empezar a darte problemas: no recibirá parches de seguridad, no tendrá nuevas funcionalidades, tu navegador dejará de poder acceder a páginas web, algunas aplicaciones dejarán de funcionar, no podrá utilizar de forma sencilla el hardware que adquieras, etc.

Pero actualizarse al nuevo Windows acarrea un par de problemas graves. El primero es que va forzar el hardware de tu equipo ya que ese sistema operativo es más exigente, de forma puede seguramente irá más lento.

Por otra parte, parece ser que Windows 11 es todavía más intrusivo en tu privacidad, llenando tu experiencia informática de anuncios personalizados no deseados.

Todo esto nos lleva a una conclusión inevitable: Microsoft quieres que te compres un ordenador nuevo. Algo que está bien si realmente fuera necesario pero es que en la mayoría de las ocasiones no lo es ya que es posible mantener tu ordenador actual y que incluso sea más rápido, seguro y respetuoso con tu privacidad.

Si tras leer todo esto te interesa, si estás por Almería el lunes 19 de enero en El Ejido que se celebra un taller que tiene por título «Actualiza tu Windows 10, cambia a GNU/Linux» donde te ayudarán a dar el paso y a tener el control de tu equipo informático.

Los datos concretos son los siguientes:

Día: Lunes, 19 de enero.

Hora: 19 horas.

Lugar: Centro Asociativo Municipal.

Más información: participacion.elejido.es

La entrada Actualiza tu Windows 10, cambia a Linux se publicó primero en KDE Blog.