Hace mucho tiempo que no dedico un artículo del estilo «te enseño a hacer algo» y hoy es un buen día para romper esa dinámica. Os presento cómo crear un Service Menu para Plasma paso a paso, algo mucho más fácil que nunca gracias a que podemos hacer uso de la IA (una herramienta que bien implementada tiene su utilidad) para nuestros proyectos.

Cómo crear un Service Menu para Plasma

Como me gusta decir este blog tiene dos finalidades: divulgar las bondades del Sotware Libre y ser un diario de las cosas que hago con GNU/Linux de forma que pueda compartirlas con todo el mundo.

De esta forma, este artículo de cómo crear un Service Menu para Plasma nace justamente de mi experiencia al hacer uno para mi uso personal.

Por razones que no vienen al caso, he estado renombrando masivamente muchos ficheros y el renombrador que viene integrado en Dolphin, aunque es muy bueno, no me servía porque utilizaba un carácter especial que él toma como «numero» (la almohadilla), así que debía utilizar uno más potente: krename.

El caso es que para hacerlo, debía abrir krename, seleccionar los archivos, llevarlos a la aplicación, renombrar y volver a empezar. En muchas ocasiones cerraba krename, así que volvía a empezar. Así que pensé: no habrá un Service Menu que seleccionando los archivos que quiera los envíe directamente a krename. No,pues no lo hay. Así que pensé en crearlo yo, con la ayuda de la IA.

De esta forma mataba muchos pájaros de un tiro: solucionaba mi problema, aprendía más sobre el sistema y compartía de una forma didáctica mi experiencia en el blog que paso a relatar a continuación.

Explicación corta

Para empezar debemos copiar en un simple archivo de texto los siguientes comandos.

[Desktop Entry]
Type=Service
MimeType=all/allfiles;inode/directory;
Actions=KRenameSelected
Icon=krename
X-KDE-Priority=TopLevel

[Desktop Action KRenameSelected]
Name=Renombrar con KRename
Icon=krename
Exec=krename %F

Ahora guardamos el archivo con este nombre, krename.desktop, y lo ponemos en la carpeta personal que cambiará según tengamos Plasma 5 o Plasma 6:

Para Plasma 5: /home/nombre_de_usuario/.local/share/kservices5/ServiceMenus/

Para Plasma 6: /home/nombre_de_usuario/.local/share/kio/servicemenus/

Reiniciamos Dolphin y ya lo tendremos. Si no os funciona, comentad y solucionamos el problema.

Explicación larga

Aunque simplemente con lo de arriba ya lo tenemos, no quiero dejar la oportunidad de enseñar a fondo qué hace realmente lo que hace este script, así que comentamos cada una de las líneas:

[Desktop Entry] –> Indica el inicio de la sección principal del archivo .desktop, donde se definen las propiedades del servicio
Type=Service → Declara que esta entrada no es una aplicación normal, sino un servicio integrado en el menú contextual de KDE (service menu)
MimeType=all/allfiles;inode/directory; → Especifica sobre qué tipos de elementos aparece el servicio. En nuestro caso all/allfiles para que sirva para todos los tipos de archivo e inode/directory para que sirva también para directorios, que en este caso sirve para seleccionar los archivos de dentro de los directorios. Alerta que al final de cada opción se debe poner un punto y coma.
Actions=KRenameSelected → Texto que verá el usuario en el menú contextual; es la etiqueta de la acción en español.​
Icon=krename → Indicamos qué icono utilizamos del sistema para mostrar el archivo .desktop. Si no lo ponemos utiliza uno por defecto genérico.
X-KDE-Priority=TopLevel → Indica a KDE que muestre la acción directamente en el nivel superior del menú contextual, en lugar de esconderla dentro de un submenú como “Acciones”.

Esta primera parte define cómo aparece el Service Menu en el menú contextual, ahora vamos a definir la acción que vamos a realizar.

[Desktop Action KRenameSelected] → Comienza la definición de la acción llamada KRenameSelected, cuyo nombre coincide con el listado en Actions
Name=Renombrar con KRename → Indica el nombre de la accioón que aparece en el menú contextual.
Icon=krename → Vuelve a especificar el icono a usar en el Service Menu.
Exec=krename %F → Este es el comando que realmente ejecuta: la aplicación krename se pondrá en funcionamiento con todos los archivos seleccionados (%F). Consulta esta página para más información: https://specifications.freedesktop.org/desktop-entry/latest/exec-variables.html

Con esto ya lo tenemos. Espero que os sea de utilidad. A mi, personalmente, me ha abierto un mundo de posibilidades.

La entrada Cómo crear un Service Menu para Plasma se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Overview of the D-Bus Service
• 3) Security Issues
  • 3.1) Lack of Authentication / Polkit Authentication Bypass
  • 3.2) D-Bus Methods Allowing Privilege Escalation
• 4) Suggested Fixes
• 5) Upstream Bugfixes
• 6) CVE Assignment
• 7) Coordinated Disclosure
• 8) Timeline
• 9) References

1) Introduction

InputPlumber is a utility for combining Linux input devices into virtual input devices. It is mostly used in the context of Linux gaming and is part of SteamOS.

An openSUSE community member packaged InputPlumber which required a review by the SUSE security team, as it contains a D-Bus system service. The first version of InputPlumber we reviewed was completely lacking client authentication, causing us to reject it. A follow-up version contained Polkit authentication, which turned out to be lacking in multiple regards. At this point we approached upstream with a detailed report and established coordinated disclosure. Starting with version v0.69.0 of InputPlumber most (but not all) of the issues in this report have been addressed. SteamOS also published new images for version 3.7.20 containing the fixes.

This report is based on InputPlumber release v0.67.0. The next section provides an overview of InputPlumber’s D-Bus service. Section 3 looks into the security issues in detail. Section 4 discusses the fixes we suggested to upstream. Section 5 looks into the upstream bugfixes to address the issues and aspects that remain unfixed. Section 6 covers the CVE assignments we did for the issues we found. Section 7 provides a summary of the coordinated disclosure process we followed for this report.

2) Overview of the D-Bus Service

InputPlumber is implemented in Rust and the size of the code base is surprisingly high for this type of project, adding up to about 50,000 lines of code overall (not counting vendor code) and about 3,000 lines dedicated to the D-Bus API specifically.

The InputPlumber D-Bus service runs with full root privileges, offering the “org.shadowblip.InputManager” interface on the D-Bus system bus. Additionally various interfaces representing Linux input devices are provided by the daemon, like a keyboard interface. In summary the service provides around 90 different D-Bus properties and about 10 different interfaces on various objects exported by it. The Polkit policy lists over 100 different actions, controlling every aspect of the D-Bus API including read/write access to individual properties.

3) Security Issues

3.1) Lack of Authentication / Polkit Authentication Bypass

Initially we looked into InputPlumber version v0.62.2. In this version there is no Polkit authorization at all for the D-Bus interfaces. There are also no restrictions in the configuration of the D-Bus service, allowing all users in the system to connect to it, even low privilege user accounts like nobody.

We thought about reaching out to upstream already at this point, when we noticed that in InputPlumber version v0.63.0 (which was meanwhile published on GitHub) Polkit authentication had been added via commit 0a80f3d85. Thus we asked our community maintainer to update the package to at least that version for us to have another look.

Due to other priorities we only got around to taking a fresh look at the package at a later time, when the package had already been updated to version v0.67.0, on which this report is based.

Looking into this version we first discovered that the Polkit authentication was still not effective in the package build provided to us. The reason for this was that Polkit support was only a compile-time feature on Rust Cargo configuration level - which was disabled by default. We believe that in this version there is also no canonical way to enable the feature when using the Makefile found in the repository. For this reason we created our own build of InputPlumber and applied a patch to hard-enable the Polkit feature for testing.

In this custom package build of InputPlumber the Polkit authentication triggered as expected. While looking into the implementation of the Polkit authentication wrapper, however, we noticed that the Polkit authentication logic uses the “unix-process” Polkit subject in an unsafe way. It retrieves the caller’s PID from the D-Bus connection and passes this information on to the Polkit daemon. This suffers from a race condition, because the client can attempt to have its PID replaced by a privileged process by the time polkitd gets around to actually look at the credentials of the process.

This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.

In summary none of the versions of InputPlumber we looked into provided sufficient authentication, even if integrators would have managed to actually enable the Polkit layer in versions v0.63.0 and later. Thus all InputPlumber D-Bus methods can be considered accessible by all users in the system without authentication.

3.2) D-Bus Methods Allowing Privilege Escalation

Considering the unprivileged access to the D-Bus methods provided by InputPlumber, the following two methods quickly caught our attention as being problematic:

CreateCompositeDevice(in s config_path)

This method parses the provided input path as YAML to create a CompositeDevice configuration and suffers from the following issues:

• The method allows to perform file existence tests, by passing paths usually not accessible to the caller.
• The method allows for a local Denial-of-Service (e.g. by passing /dev/zero as input file, leading to memory exhaustion in InputPlumber).
• The method allows for an information leak, e.g. from /root/.bash_history:

  user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
      -m org.shadowblip.InputManager.CreateCompositeDevice /root/.bash_history
  Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Unable to deserialize: invalid type: string "cd /etc/polkit-1/rules.d/", expected struct CompositeDeviceConfig at line 2 column 1
  

  The string cd /etc/polkit-1/rules.d is an entry from root’s history file in this case.

CreateTargetDevice(in s kind)

This method allows to create a virtual keyboard input device like this:

user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
   -m org.shadowblip.InputManager.CreateTargetDevice keyboard

Once the virtual keyboard has been created, key presses can be injected into the active user session (login terminal or graphical desktop) like this:

user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/devices/target/keyboard0 \
    -m org.shadowblip.Input.Keyboard.SendKey KEY_R true

All supported key symbols are found in keyboard.rs. Using this ability, any user in the system can inject input to an active desktop session or the active login terminal screen, possibly leading to arbitrary code execution in the context of the currently logged in user, if any.

4) Suggested Fixes

We suggested the following action items to upstream to improve the security of the InputPlumber D-Bus API:

• Use of the “system bus name” Polkit subject to fix the authentication code.
• Enabling of Polkit authorization by default in the build process.
• Passing of file descriptors instead of path names to D-Bus methods. This way the complexity of safely accessing client-provided paths is avoided and various attack scenarios in this area are no longer relevant.
• Addition of documentation pointing out that unauthorized access to the D-Bus service has security implications.
• Addition of hardening to the inputplumber systemd service. By using settings like ProtectSystem=full the service can be tightened to avoid any unexpected side effects when things go wrong at the first line of defense.

5) Upstream Bugfixes

Upstream mostly followed our suggestions and fixed the issues as follows:

• in commit 4db3b20 the Polkit subject used for authentication has been switched to “system bus name”, therefore fixing the Polkit authentication bypass.
• in commit f3854be the “Polkit” Cargo feature is enabled by default.
• in commit 79f0745 systemd hardening is applied to the InputPlumber service.

All of these fixes are contained in InputPlumber version v0.69.0 and later.

Upstream initially wanted to avoid breaking the D-Bus API by switching to file descriptors instead of path names, as we suggested. We strongly recommended to do this, however, to avoid various issues that can occur when clients pass malicious file paths. An upstream developer then created a pull request which introduces file descriptors in the API. We provided feedback that this is going in the right direction, but suggested to also perform checks on the file descriptors passed by clients to make sure they refer to regular files and have no unusual open flags like O_PATH set.

At the time of publication of this report we noticed that the improvements of the D-Bus API to use file descriptors have not been merged yet and are not available in a release. Thus some aspects of the issues described in this report remain unaddressed, although they are now at least protected by proper Polkit authentication. Sensitive methods like CreateCompositeDevice also require admin privileges to be called, thus these are mostly defense-in-depth issues, or only relevant when integrators or admins relax Polkit authentication requirements.

6) CVE Assignment

In agreement with upstream we performed the following CVE assignments corresponding to this report:

• CVE-2025-66005: lack of authorization of the InputManager D-Bus interface in InputPlumber versions before v0.63.0 can lead to local Denial-of-Service, information leak or even privilege escalation in the context of the currently active user session.

• CVE-2025-14338: Polkit authentication disabled by default and a race condition in the Polkit authorization check in versions before v0.69.0 can lead to the same issues as in CVE-2025-66005.

7) Coordinated Disclosure

We informed upstream about the security issues on 2025-11-25 and offered coordinated disclosure. Upstream quickly confirmed the issues and agreed to follow coordinated disclosure. The developers discussed bugfixes with us, which they provided in public GitHub pull requests. This way the information about the issues was not fully private anymore, but we agreed to keep the full report private for a longer time, until new SteamOS images would be published, containing a fixed InputPlumber.

We found out only at the time of publication that not all aspects of the issues have been addressed in the bugfix release.

We want to thank the InputPlumber developers for their cooperation regarding this report.

8) Timeline

9) References

• InputPlumber GitHub project
• InputPlumber Bugfix Release v0.69.0
• SteamOS Images 3.7.20 Beta containing a fixed InputPlumber

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar, un poco tarde, la primera actualización de KDE Gear 25.12 que apareció hace casi un mes. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.

Primera actualización de KDE Gear 25.12

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE Gear 25.12 que nos ofrece un buen número de errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Aquí podéis encontrar la lista completa de cambios de KDE Gear 25.08.1, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:

• Dolphin: Permite la migración para usuarios con el antiguo formato de archivos de sesión (Commit, soluciona el error #513466).
• Kate: Arregla un fallo que hacía colgar la vista en árbol del complemento Project (Commit, soluciona el error #513753).
• Skladnik: Ignora el evento de soltar el ratón al acabar un arrastre (Commit).

Más información: KDE Gear 25.12.1

La entrada Primera actualización de KDE Gear 25.12 se publicó primero en KDE Blog.

Si un amigo o amiga te ofrece… simplemente di NO a la IA. Se empieza por poco y se termina alabando las bondades de los grandes tecnócratas fascistas

Tu aplicación de mensajería, tu red social, tu programa de ofimática, tu asistente personal, tu televisión, tu aspirador, tu microondas, tu frigorífico… todo lleva IA.

Los medios de información te muestran que es la nueva revolución, todo el mundo se sube a la nueva ola tecnológica sin saber muy bien qué hace, cómo utilizarla o cómo implementarla, pero los CEOs ven bondades en ella, reducción de costes (a corto plazo), mejoras (a corto plazo)…

Ayer mismo me encontré por el fediverso un enlace a una web llamada justsayno to AI:

• https://www.justsayno.ai/

Una web en la que se recalca y se pone de manifiesto, que este hype que existe en torno a la (mal) llamada Inteligencia Artificial (IA), quizás es algo excesivo que se nos está escapando de las manos.

Lo cierto es que la IA está ocupando muchos aspectos de nuestro día a día. Se ha incrustrado en muchos aspectos haciéndose casi indispensable para quien la utiliza, pero ese uso y abuso tiene unos costes y puede que unas consecuencias que ahora estamos empezando a vislumbrar.

Grandes empresas de tecnología como Microsoft, Meta (que gestiona WhatsApp, Instagram, Facebook), Google, o X aka Twitter ya incluyen la tan cacareada IA y sus asistentes en sus servicios. Si esas empresas dirigidas por personas que posaban muy orgullosas en la investidura de Donald Trump y cuyos actos en el pasado han sido abusivos y sospechosos abrazan tal tecnología entonces algo mal seguro que hay detrás.

Por sus hechos les conoceréis, y ya en el pasado esas empresas tecnológicas han demostrado que los dividendos positivos son su única finalidad pasando por encima del bienestar de las personas o del medio ambiente.

Ocultan sus intenciones dañinas, y venden una nacesidad que se convierte ya en imprescindible o quieren que así sea.

Las IA que nos promocionan y que nos quieren implantar en cada situación del día a día tienen costes medio ambientales de consumo de recursos, y tiene unas repercusiones sociales que podemos discernir. Ya hay personas que confían en estas herramientas desprovistas de corazón los aspectos más íntimos y las decisiones personales frente al consejo o el tratamiento de personas.

Estamos confiando en empresas oscuras con un oscuro historial nuestra esencia. Estamos pidiendo a Darth Vader que nos aconseje qué hacer y le estamos creyendo y siguiendo como nuevos gurús del siglo XXI.

Estas IA no saben nada, no sienten nada, no saben mentir, se equivocan y se disculpan, pero todo es una mentira. Si había personas que creían que vivíamos en Matrix, ahora al dar voz y voto a estas máquinas, están haciendo realidad esa profecía que tenían en su mente.

Derivada de esa página en inglés, he realizado una traducción/adaptación que puedes encontrar en el siguiente enlace:

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

En la que se explican ciertos motivos para rechazar esa IA omnipresente. Esa gestión de datos está bien para una tarea concreta. Las IA son simplemente programas con miles de millones de datos y utilizarlo para todo es imposible.

Esos Algoritmos Informáticos son buenos encontrando patrones, o recopilando datos de tareas concretas para las que podemos enseñarlas: prevención de cataclismos naturales, prevención de enfermedades, búsqueda de respuestas científicas en base a un montón de datos, etc.

Eso sí, dirigirlas como herramientas para un fin concreto, puede ser buena idea. Intentar que resuelva nuestra vida con lo diversa y diferente que es entre miles de millones de personas es imposible y una locura temeraria que no aporta nada.

Deben ser herramientas, pero deben ser abiertas y éticas. Las empresas como openAI añaden ese «open» a su nombre mientras cierran todo lo demás. Arrasan con datos, con conocimiento que se apropian y blindan sus oscuros algoritmos.

Se debe volver a poner a las personas en el centro de la tecnología. Que esta esté a su servicio como herramienta, no como sustituto de las personas. Rechazo imágenes generadas por estos algoritmos, vídeos, música, etc. No me aportan nada, me rechina su impostada «naturalidad» y su suplantación.

Y además esta caracterísitca hará que no podamos confiar en nada en un futuro al no saber si es algo auténtico o algo sintético salido de oscuros algoritmos creados por oscuras empresas con oscuros intereses.

Echad un vistazo a la web original y mi traducción para ver si os convencen los argumentos expuestos. Y ya sabes, si alguien te ofrece IA…

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

Es increíble el trabajo de promoción que está realizando Nate en su blog, desde hace más del tiempo que puedo recordar, ha sido replicado en ocasiones por Carl Schwan hablando de aplicaciones. Igual que Nate, se trata de un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Dado que en la actualidad tenemos herramientas que nos facilitan la traducción y la edición voy a intentar hacer algo que es simple pero requiere constancia: promocionar dichos artículos facilitando la información a la comunidad hispana que no domina el inglés. Al mismo tiempo hará que yo esté al día y que me entere bien de todo. Bienvenidos pues al artículo de la serie «Nueva aplicación pizarra digital – Esta semana en KDE Apps». Espero que os guste y que os ponga los dientes largos viendo lo que nos espera.

Nueva aplicación pizarra digital, Drawy – Esta semana en KDE Apps

Nota: artículo original en Blogs KDE. Traducción realizada utilizando Perplexity. Esta entrada está llena de novedades en las aplicaciones de la Comunidad KDE.

«¡Bienvenidos a una nueva edición de ‘This Week in KDE Apps’!
Cada semana (más o menos) abarcamos todo lo posible sobre lo que ocurre en el mundo de las aplicaciones de KDE. Arrancamos el año con todas las novedades del panorama de aplicaciones de KDE. ¡Entremos en materia!»

Para este nuevo año he decidido cambiar un poco esta serie de artículos, ya que con los títulos coloridos se hace pesada la escritura, invirtiendo demasido tiempo en aspecto visuales que quizás enmascaran el contenido. Así que me tomaré menos al pie de la letra la estructura del artículo original y realizaré mi entrada más a mi manera.

Nueva aplicación: Drawy

La novedad más destacada de esta semana es la presentación de una nueva aplicación creativa llamada Drawy, desarrollada gracias al trabajo de Prayag Jain,

Drawy es una herramienta de pizarra digital que ofrece un lienzo infinito para el «brainstorming» y el dibujo libre, ideal para los profesores y sus clases en línea.

Entre sus características básicas destacan:

• Soporte para tabletas de dibujo y pantallas táctiles
• Herramientas para agrupar elementos
• Funcionalidades de texto.

Hay que tener en cuenta que aún está en desarrollo, así que lo mejor está por llegar y puede ser una alternativa más que seria a OpenBoard.

KDE Itinerari

Ya es un clásico de esta sección la aplicación de viajes, KDE Itinerary que ha recibido gran una actualización de la mano de Jonah Brüchert, quien ha implementado un nuevo backend basado en MapLibre para las vistas de mapas. Esta mejora permite el renderizado de mosaicos vectoriales, lo que se traduce en mapas que pueden visualizarse a cualquier tamaño sin pixelación y con ampliaciones mucho más fluidas. Además, esta tecnología facilita la visualización de etiquetas tanto en el idioma local como en inglés, aumentando la utilidad de la aplicación en el extranjero.

Otros cambios en Itinerary incluyen la adaptación de múltiples diálogos a un estilo convergente por Carl Schwan, la capacidad de marcar reservas como canceladas en la línea de tiempo (gracias a Volker Krause) para no afectar las estadísticas anuales, y mejoras en la extracción de datos de tarjetas de embarque y correos de KLM, así como soporte para billetes anuales de GOMUS.

Aplicaciones de utilidades, oficina y redes

Llegamos a la sección con actualizaciones más pequeñaa.

Empezamos con Konsole, que ha ganado una nueva opción llamada «Forzar nuevas pestañas», implementada por Leonardo Malaman, que permite abrir nuevas instancias en pestañas dentro de una ventana existente en lugar de crear ventanas nuevas.

Por su parte, el editor de texto Kate ahora incluye soporte nativo para neocmakelsp, un servidor LSP para CMake, facilitando la vida a los desarrolladores.

Okular, el visor de documentos, ha corregido un problema de escalado que causaba que los sellos personalizados se vieran pixelados, algo feo ya que estamos buscando la excelencia.

En la categoria de redes leemos que NeoChat ha unificado su lógica de selección de espacios y ha mejorado su menú de hamburguesa y el diálogo de perfiles para una experiencia más intuitiva.

Por su parte, KAIChat, un chat de IA integrado en el escritorio Plasma y que personalmente desconocía su existencia, ha lanzado su versión 0.6.0, integrando Wikipedia, información meteorológica y un widget de búsqueda rápida.

Para finaliza, Kaidan, la aplicación de chat moderna, ha alcanzado la versión 0.14.0, añadiendo la capacidad de reenviar mensajes fallidos, cancelar subidas y mejorando la compatibilidad con servidores LDAP.

… Y todo lo demás

Este blog solo cubre la punta del iceberg. Descubre más en el blog de Nate sobre Plasma y su serie This Week in Plasma, donde detalla las novedades del entorno de escritorio Plasma de KDE. Para información sin filtrar, visita KDE’s Planet.

Participa

La organización KDE se ha vuelto importante a nivel mundial, y tu tiempo y contribuciones nos han ayudado a llegar hasta aquí. A medida que crecemos, necesitaremos tu apoyo para que KDE sea sostenible.

Puedes ayudar a KDE siendo un miembro activo de la comunidad y participando. Cada colaborador hace una gran diferencia en KDE: no eres un número ni una pieza más en una máquina. ¡Ni siquiera tienes que ser programador! Hay muchas cosas que puedes hacer: ayudar a encontrar y confirmar errores, e incluso quizás solucionarlos; contribuir con diseños para fondos de pantalla, páginas web, iconos e interfaces de aplicaciones; traducir mensajes y elementos de menús a tu idioma; promover KDE en tu comunidad local; y muchas más cosas.

También puedes ayudarnos donando. Cualquier contribución monetaria, por pequeña que sea, nos ayudará a cubrir los costos operativos, salarios, gastos de viaje para los colaboradores y, en general, a que KDE pueda seguir llevando Software Libre al mundo.

Para que tu aplicación sea mencionada aquí, por favor contáctanos en invent o en Matrix.

La entrada Nueva aplicación pizarra digital, Drawy – Esta semana en KDE Apps se publicó primero en KDE Blog.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

Por cierto este mes se cumplen 40 años de la creación de la FSF.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2026/january
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2026/enero

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de enero de 2026.

Se anuncian los ganadores de los premios Free Software Awards: Andy Wingo, Alx Sa, Govdirectory

Del 9 de diciembre

Cada año, la FSF reconoce a algunos grupos e individuos de la comunidad de software libre que han realizado contribuciones significativas a la libertad del software. Este año, los galardonados con el Premio al Avance del Software Libre, el Premio al Contribuyente Destacado de Software Libre y el Premio a Proyectos de Beneficio Social fueron otorgados a Andy Wingo, Alx Sa y Govdirectory. Lee más sobre los ganadores y piensa en cómo podrías involucrarte en un proyecto de software libre en un futuro próximo.

• https://www.fsf.org/news/2024-free-software-awards-winners

La Free Software Foundation recibe donaciones privadas históricas

Del 24 de diciembre

Hacia el final del cuadragésimo año de la FSF, dos donantes excepcionalmente generosos donaron a la organización una contribución total de 900.000 dólares estadounidenses. Estas donaciones extraordinarias, ambas hechas a la FSF en la criptomoneda Monero, están entre algunas de las mayores donaciones privadas jamás hechas a la organización. Los donantes desean permanecer en el anonimato.

Todas las donaciones, sean 5 USD o 500.000 USD, marcan la diferencia en el trabajo de la FSF para avanzar en el movimiento del software libre. Estas donaciones apoyarán al equipo técnico y la capacidad de infraestructura de la organización, así como fortalecerán sus campañas, iniciativas educativas, de licencias y de incidencia, así como oportunidades futuras. Nunca es tarde para apoyar la misión de la FSF de promover la libertad del usuario de ordenadores — dona hoy.

• https://www.fsf.org/news/free-software-foundation-receives-historic-private-donations

Tu vida digital no es tuya: La batalla oculta por la libertad del software

Del 17 de diciembre por Jason Self

Tú eres el dueño de tu teléfono, pero otra persona dicta sus funciones. Puedes usar redes sociales, pero un algoritmo que no puedes inspeccionar moldea la realidad que ves. Eres dueño de tu coche, pero no puedes arreglarlo. Tienes tu smart TV, pero te está observando.

En cada rincón de nuestra vida moderna, estamos rodeados de cosas que hemos comprado pero que se nos prohíbe poseer o comprender realmente. El culpable no es el dispositivo en sí, sino el código invisible que se ejecuta en su interior, y la lucha por el control de ese código es una de las batallas más importantes por los derechos humanos del siglo XXI.

Sigue leyendo para entender mejor cómo los proveedores privativos buscan controlarte y qué puedes hacer para construir un futuro mejor.

• https://www.fsf.org/blogs/community/your-digital-life-is-not-yours

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2026/enero

Y todos los números del «supporter» o boletín de noticias de 2026 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2026

Table of Contents

• 1) Introduction
• 2) Overview of the TLP Daemon
• 3) Security Issues
  • 3.1 Polkit Authorization Check can be Bypassed
  • 3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds
  • 3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception
  • 3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface
• 4) CVE Assignment
• 5) Coordinated Disclosure
• 6) Timeline
• 7) References

1) Introduction

TLP is a utility for saving laptop battery power when running Linux (note: the TLP acronym has no special meaning). In version 1.9.0 of TLP a profiles daemon similar to GNOME’s power profiles daemon has been added to the project, providing a D-Bus API for controlling some of TLP’s settings.

Our SUSE TLP package maintainer asked us for a review of the changes contained in the new TLP release, leading us to discover issues in the Polkit authentication logic used in TLP’s profiles daemon, which allow a complete authentication bypass. While looking into the daemon we also found some additional security problems in the area of local Denial-of-Service (DoS).

We reported the issues to upstream in December and performed coordinated disclosure. TLP release 1.9.1 contains fixes for the issues described below. This report is based on TLP 1.9.0.

The next section provides a quick overview of the TLP power daemon. Section 3 discusses the security issues we discovered in detail. Section 4 looks into the CVEs we assigned. Section 5 provides a summary of the coordinated disclosure process we followed for these findings.

2) Overview of the TLP Daemon

The new TLP power daemon is implemented in a Python script of moderate size. The daemon runs with full root privileges and accepts D-Bus client connections from arbitrary users. For authorization of clients a Polkit policy defines a couple of actions which are checked in the daemon’s _check_polkit_auth() function. Some of these actions are allowed for local users in an active session without providing further credentials, others require admin credentials.

3) Security Issues

3.1 Polkit Authorization Check can be Bypassed

The check_polkit_auth() function relies on Polkit’s “unix-process” subject in an unsafe way. The function obtains the caller’s PID and passes this information to the Polkit daemon for authorization, which is inherently subject to a race condition: at the time the Polkit daemon looks up the provided PID, the process can already have been replaced by a different one with higher privileges than the D-Bus client actually has.

As a result of this, the Polkit authorization check in the TLP power daemon can be bypassed by local users, allowing them to arbitrarily control the power profile in use as well as the daemon’s log settings.

This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.

Upstream Bugfix

We suggested to upstream to switch to Polkit’s D-Bus “system bus name” subject instead, which is a robust way to authenticate D-Bus clients based on the UNIX domain socket the client uses to connect to the bus. This is what upstream did in commit 08aa9cd.

3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds

The D-Bus methods “HoldProfile” and “ReleaseProfile” can be used by locally logged-in users without admin authentication and allow to establish a “profile hold”, preventing the profile from being automatically switched until it is released again.

The “HoldProfile” method returns a cookie value to the caller which needs to be presented to the “ReleaseProfile” method again to release it. This cookie value is a simple integer which starts counting at zero and is incremented for each call to “HoldProfile”. This makes the cookie value predictable and allows other, unrelated users or applications to release an active profile hold by trying to guess the cookie value in use.

Upstream Bugfix

We suggested to upstream to make the cookie value unpredictable by generating a random number. This is what upstream did in commit a88002e.

3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception

As described in the previous section, the “ReleaseProfile” D-Bus method expects an integer cookie parameter as input. The Python D-Bus framework used to implement the method allows clients to pass non-integer types as cookie, however, which causes an exception to be thrown in the daemon. This does not lead to the daemon exiting, however, since the framework catches the exception.

The issue can be reproduced via the following command line:

user$ dbus-send --system --dest=org.freedesktop.UPower.PowerProfiles \
      --type=method_call --print-reply /org/freedesktop/UPower/PowerProfiles \
      org.freedesktop.UPower.PowerProfiles.ReleaseProfile string:test
Error org.freedesktop.DBus.Python.ValueError: Traceback (most recent call
last):
  File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in
_message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/sbin/tlp-pd", line 223, in ReleaseProfile
    cookie = int(cookie)
ValueError: invalid literal for int() with base 10: dbus.String('test')

Upstream Bugfix

While this is not strictly a security issue, we still suggested to make the daemon more robust by actively catching type mismatch issues for the cookie input parameter. Upstream followed this suggestion and implemented it in the same commit as above which introduces unpredictable cookie values.

3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface

The profile hold mechanism described in section 3.2 allows local users in an active session to create an unlimited number of profile holds without admin authentication. This can lead to resource exhaustion in the TLP power daemon, since an integer is entered into a Python dictionary along with arbitrary strings reason and application_id which are also supplied by the client. This API thus offers Denial-of-Service attack surface.

We found a similar issue in GNOME’s power profile daemon some years ago, but GNOME upstream disagreed with our analysis at the time, which is why SUSE distributions are applying a custom patch to limit the number parallel profile holds.

Upstream Bugfix

We asked upstream whether there are any valid use cases for supporting a large number of profile holds in parallel, and it turns out that the typical use case is only to support a single profile hold at any given time. Thus upstream agreed to restrict the number of profile holds to a maximum of 16, which is implemented in commit 6a637c9.

4) CVE Assignment

We assigned CVE-2025-67859 to track issue 3.1 (Polkit authentication bypass). Issues 3.2 (predictable cookie values) and 3.4 (unlimited number of profile holds) would formally also justify CVE assignments; their severity is low, however, and we agreed with upstream to focus on the main aspect of the Polkit authentication bypass.

5) Coordinated Disclosure

We reached out to the upstream author on December 16 with details about the issues and offered coordinated disclosure. Upstream confirmed the issues and accepted coordinated disclosure. We discussed patches and further details over the course of the following two weeks. Due to the approaching Christmas holiday season we decided to set the general publication date to January 7.

We want to express our thanks to the TLP upstream author for the smooth cooperation in handling these issues.

6) Timeline

7) References

• TLP Website
• TLP GitHub project
• TLP Bugfix Release 1.9.1
• openSUSE Bugzilla review bug for TLP 1.9.1

Table of Contents

• 1) Introduction
• 2) Overview of the D-Bus Service
• 3) Security Issues
  • 3.1) Lack of Client Authorization
  • 3.2 Missing Input Parameter Verification
  • 3.3) Unsafe umask used in Daemonize Code
• 4) Upstream Bugfixes
• 5) CVE Assignment
• 6) Coordinated Disclosure
• 7) Timeline
• 8) References

1) Introduction

Foomuuri is an nftables-based firewall manager for Linux. The project includes a D-Bus daemon which offers an API similar to firewalld. In early December an openSUSE community member asked us to review Foomuuri for addition to openSUSE Tumbleweed.

During the review we quickly noticed a lack of client authorization and input validation in the implementation of Foomuuri’s D-Bus service. We reported the issues to upstream and performed coordinated disclosure. Upstream published version 0.31 of Foomuuri on 2026-01-07 which contains bugfixes for the security issues.

The next section provides an overview of the Foomuuri D-Bus service. Section 3) discusses the security issues in detail. Section 4) provides an overview of the upstream bugfixes to address the issues. Section 5) looks into the CVEs which were assigned. Section 6) gives insight into the coordinated disclosure process which was established for these findings.

This report is based on Foomuuri release v0.29.

2) Overview of the D-Bus Service

Foomuuri runs with full root privileges and registers a D-Bus interface under the name”fi.foobar.Foomuuri1”. Optionally a firewalld drop-in replacement interface is also registered under “org.fedoraproject.FirewallD1”. Both interfaces hook into the same logic, however, and there is no need to look at them separately.

There are only a few methods provided by the D-Bus interface: getting the list of available zones and managing the assignment of network interfaces to zones.

3) Security Issues

3.1) Lack of Client Authorization

There is no authentication layer like Polkit present in the Foomuuri D-Bus service, and there are also no restrictions on D-Bus configuration level as to who is allowed to connect to the D-Bus interfaces provided.

As a result any local user, including low privilege service user accounts or even nobody, can invoke the D-Bus interface and change the firewall configuration. The only state which can be modified this way is the assignment of interfaces to zones, but this is enough to weaken the firewall configuration or to perform a limited Denial-of-Service.

3.2 Missing Input Parameter Verification

Apart from the lack of access restrictions pointed out above, the input parameters to the D-Bus methods are not carefully scrutinized. While the zone input parameter is at least checked against currently configured zones, no further checks are performed on the interface parameter. This means that, e.g. via the “addInterface” D-Bus method, arbitrary strings can be passed as interface name. There is also intentionally no check if the specified name corresponds to an existing network device in the system (to allow seamless coverage of network devices even before they are added to the system).

One result from this can be log spoofing, since the interface name is passed to logging functions unmodified. The string could contain control characters or newlines, which can manipulate the log.

In DbusCommon.add_interface() the possibly crafted interface name is added to the to-be-generated JSON configuration via the out() method. While we did not verify whether this works in practice, a local attacker could attempt to largely control the JSON configuration passed to nftables, by skillfully embedding additional JSON configuration in the interface parameter.

We were worried that this could even lead to arbitrary code execution by abusing features of nftables like loading external files or plugin code, but it turned out that there are no such features available in the nftables configuration format.

3.3) Unsafe umask used in Daemonize Code

Foomuuri contains optional support to daemonize itself. Normally this is done by systemd and the code in question is not invoked. It contains logic to set the daemon’s umask to 0, however, which is a bad default, since applications or libraries which intend to foster user control of the file mode of newly created files can pass modes like 0666 to open(), rendering them world-writable.

Foomuuri does not contain any code paths that create new files, but the umask setting is also inherited by child processes, for example. While we did not think this was a tangible security issue in this form, we suggested to choose a more conservative value here to prevent future issues.

4) Upstream Bugfixes

We suggested the following fixes to upstream:

• restrict access to the D-Bus interfaces to root only, maybe also to members of a dedicated opt-in group. Alternatively Polkit could be used for authentication of callers, which is more effort and complex, however.
• the interface input parameter should be verified right from the beginning of each D-Bus method to make sure that it does not contain any whitespace or special characters and is not longer than IFNAMSIZ bytes (which is currently 16 bytes on Linux).
• as an additional hardening measure we also suggested to apply systemd directives like ProtectSystem=full to Foomuuri’s systemd services, to prevent possible privilege escalation should anything go wrong at the first line of defense.

Upstream decided to implement Polkit authentication for Foomuuri’s D-Bus service and otherwise followed closely our suggestions:

• commit 5944a42 adds Polkit authentication to the D-Bus service. Changing firewall settings now requires admin authorization. The use of Polkit can be disabled in Foomuuri, in which case only clients with UID 0 are allowed to perform the operations.
• commit d1961f4 adds verification of the interface parameter to prevent manipulation of the JSON configuration data.
• commit 806e11d sets the umask used in the daemonize code to a more conservative 0o022 setting, preventing world- or group-writable files from coming into existence.
• commit 5fcf125 adds the ProtectSystem=full directive to all Foomuuri systemd service units.

All of the bugfixes are contained in version 0.31 of Foomuuri.

5) CVE Assignment

In agreement with upstream we assigned the following two CVEs corresponding to this report:

• CVE-2025-67603: lack of client authorization allows arbitrary users to influence the firewall configuration (issue 3.1).

• CVE-2025-67858: a crafted interface input parameter to D-Bus methods can lead to integrity loss of the firewall configuration or further unspecified impact by manipulating the JSON configuration passed to nft (issue 3.2).

6) Coordinated Disclosure

We reported these issues to the upstream developer on 2025-12-11, offering coordinated disclosure. We soon got a reply and discussed the details of the non-disclosure process. Upstream quickly shared patches with us for review and we agreed on the final patches already on 2025-12-19. In light of the approaching Christmas season we agreed on a publication date of 2026-01-07 for general disclosure.

We want to thank the upstream author for the prompt reaction and cooperation in fixing the issues.

7) Timeline

8) References

• Foomuuri GitHub project
• Foomuuri v0.31 Bugfix Release

With the start of the new year, I am very happy to announce the release of version Kraft 2.0.0.

Kraft provides effective invoicing and document management for small businesses on Linux. Check the feature list.

This new version is a big step ahead for the project. It does not only deliver the outstanding ports to Qt6 and KDE Frameworks 6 and tons of modernizations and cleanups, but for the first time, it also does some significant changes in the underlying architecture and drops outdated technology.

Kraft now stores documents not longer in a relational database, but as XML documents in the filesystem. While separate files are more natural for documents anyway, this is paving the way to let Kraft integrate with private cloud infrastructures like OpenCloud or Nextcloud via sync. That is not only for backup- and web-app-purposes, but also for synced data that enables to run Kraft as distributed system. An example is if office staff works from different home offices. Expect this and related usecases to be supported in the near future of Kraft.

But there are more features: For example, the document lifecycle was changed to be more compliant: Documents remain in a draft status now until they get finalized, when they get their final document number. From that point on, they can not longer be altered.

There is too much on the long Changes-List to mention here.

However, what is important is that after more than 20 years of developing and maintaining this app, I continue to be motivated to work on this bit. It is not a big project, but I think it is important that we have this kind of “productivity”-applications available for Linux to make it attractive for people to switch to Linux.

Around Kraft, a small but beautiful community has built up. I like to thank everybody who contributed in any way to Kraft over the years. It is big fun to work with you all!

If you are interested, please get in touch.