Google con su monopolio casi exclusivo de lo que la gente conoce como internet ha contribuido con sus prácticas a que decaiga el uso de los feeds RSS aunque aún hay quienes los utilizamos

¿Quieres estar al tanto de las publicaciones de una web, blog que te gusta mucho? Una opción es visitarla todos los días para ver si ha publicado algo nuevo… pero hay otras opciones, por ejemplo usar los feeds RSS.

En resumen, cada web o blog (este blog mismo que estás leyendo) tiene disponible ese servicio que hace que gracias a un programa único puedas recopilar todas las novedades de esas webs o blogs recopiladas en un solo lugar en tu equipo.

Así podrás recopilarlas cuando tengas tiempo para leerlas, puedes guardarlas para consultarlas más adelante, ordenarlas, etiquetarlas, etc. Pero no solo sirve para webs o blogs. muchos otros servicios también se difunden usando esta tecnología.

Ahora que resuena en una parte de la comunidad de internet esa tendencia a retornar a los orígenes de la red, alejándonos de la comercialización, del seguimiento, del abuso de la persona que visita, de cobra por cookies, etc.

Los feeds RSS son una herramienta que ha estado ahí desde hace muchos años y fue muy utilizado. En este artículo repasaremos cómo Google con sus prácticas monopolistas ha querido también eliminar del imaginario de internet esta tecnología en favor de algo más centralizado (en su empresa) que permita cuntificar, monetizar y controlar al usuario.

Este artículo es una traducción del inglés de un artículo publicado por OpenRSS en agosto de 2023 en su web que puedes leer en este enlace:

• https://openrss.org/blog/how-google-helped-destroy-adoption-of-rss-feeds

Aunque los feeds RSS están vivos y todavía se utilizan mucho hoy en día, su nivel de adopción se ha visto afectado debido a lo difícil que ha sido para un puñado de empresas de tecnología populares utilizarlos.

Google, especialmente, ha confiado en el protocolo RSS de la web abierta para ganar tanta participación de mercado e influencia, pero continúa adoptando un comportamiento que explota la web abierta a expensas de sus usuarios.

Como resultado, Google ha contribuido por sí solo a la razón por la que muchos usuarios que alguna vez confiaron en los canales RSS hayan dejado de usarlos.

A continuación, profundizamos en el historial de Google de lo que parece ser un modelo de Abrazar, Extender y Extinguir.

La compañía ha construido y ampliado continuamente sus productos en torno al protocolo RSS abierto y gratuito para ganarse la confianza del usuario, solo para luego eliminar el soporte RSS una vez que han bloqueado a los usuarios e ignorar cualquier queja o solicitud para restaurarlo.

No sólo es un flagrante desprecio por el RSS y una gran decepción para quienes lo utilizan, sino que plantea una de las mayores amenazas a la libertad y apertura de Internet.

Google elimina el botón RSS del navegador Chrome

Las primeras versiones del navegador Chromium (en el que se basa el navegador Google Chrome) alguna vez vinieron con integración RSS incorporada.

El navegador tenía un botón RSS incorporado que se mostraba en la barra de direcciones del navegador cuando cualquier sitio web en el que se encontraba tuviera una fuente RSS disponible.

Al hacer clic en el botón, accederá a la fuente RSS de esa página web, lo que permitirá al usuario suscribirse fácilmente.

Luego, el botón RSS desapareció sin previo aviso y no se dio ninguna razón para su eliminación.

Google adquiere FeedBurner y limita el RSS

En 2007, Google adquirió FeedBurner, un servicio de feeds RSS que permite a los propietarios de sitios web monetizar sus feeds RSS.

FeedBurner funciona reemplazando los canales RSS ordinarios por canales privados que sólo pertenecen a Google.

Los feeds se modifican para incluir anuncios, enlaces de afiliados y otros mecanismos de seguimiento, como recuentos de lecturas, tasas de clics y recuentos de suscriptores. Luego, los usuarios de FeedBurner utilizan los feeds para realizar un seguimiento de sus lectores y monetizar su comportamiento.

Después de adquirir FeedBurner, Google cerró las API de FeedBurner en octubre de 2012, lo que impidió a los desarrolladores crear integraciones RSS de terceros para el servicio.

Luego, en julio de 2022, Google cambió drásticamente la infraestructura y el modelo operativo de FeedBurner al eliminar la mayoría de los servicios de FeedBurner de los que dependían sus usuarios de RSS, que incluían suscripciones por correo electrónico.

Esto dejó a muchas personas con URL de fuentes RSS que no funcionaban en sus correos electrónicos de suscripción y sin forma de solucionarlas.

Google cierra Google Reader

En 2005, Google creó Google Reader, una aplicación de lectura de RSS basada en web. Le permitía agregar fuentes RSS en cualquier lugar de Internet y organizarlas en carpetas en una interfaz limpia y minimalista.

Luego, en 2013, después de años de que los usuarios confiaran en él para sus feeds RSS, Google lo eliminó.

La razón que dio Google para eliminar Google Reader fue en un anuncio en el que afirmaban que «si bien el producto tiene seguidores leales, a lo largo de los años su uso ha disminuido».

Pero un ingeniero, que trabajaba para Google en ese momento, declaró: «Me sentí como si durante todo el tiempo que estuve en el proyecto, varias personas intentaran acabar con él».

Sin embargo, la acusación de Google sobre el bajo uso no infundió mucha confianza en la viabilidad de los canales RSS. Los usuarios se quedaron sin una aplicación de lectura de RSS, sin una alternativa comparable y sin educación por parte de Google sobre cómo continuar usando sus canales RSS sin Google Reader.

Esto llevó a los usuarios no sólo a dejar de usar Google Reader, sino también a abandonar por completo los feeds RSS.

Google elimina el RSS de las Alertas de Google

Google Alerts es un servicio ofrecido por Google que le notificará con una alerta cuando haya contenido nuevo en la web que coincida con un término de búsqueda que usted especifique.

En octubre de 2008, Google añadió la posibilidad de recibir alertas de Google en un canal RSS. Pero, en julio de 2013, Google decidió eliminarlo, convirtiendo el correo electrónico en la única opción para recibir alertas de Google. El motivo de la eliminación no estaba claro.

Finalmente, después de recibir una reacción violenta, Google restableció los canales RSS para las Alertas de Google. Pero en ese momento, muchos usuarios ya abandonaron los feeds RSS debido al cierre de Google Reader por parte de Google (mencionado anteriormente), por lo que el daño ya estaba hecho.

Google elimina su extensión de navegador RSS

Google proporcionó una extensión de Google Chrome que coloca un pequeño ícono RSS al lado de la URL de un sitio web en la barra del navegador si estás en una página web que tiene una fuente RSS.

A pesar de que se utilizó esta extensión, Google la eliminó. Pero luego, después de una reacción violenta, lo restableció una semana después, alegando que se eliminó por error. Y si bien restablecerlo era mejor que no hacerlo, eliminarlo seguía siendo un duro golpe para la confianza del usuario en el uso general del feed RSS.

Y si es cierto que se hizo sin querer, todavía muestra cuán poco prioritario se ha convertido el RSS para Google, a pesar de lo mucho que el RSS ha contribuido al crecimiento de la empresa.

Google elimina la integración RSS de Google News

En 2002, Google anunció Google News, el primer sitio de agregación de medios de la compañía, con la capacidad de agregar URL de fuentes RSS de toda la web.

Luego, después de que muchos usuarios de RSS quedaran bloqueados y dependieran de la aplicación Google News para sus feeds RSS, Google dejó de admitir el soporte RSS, lo que provocó que los feeds RSS de los usuarios dejaran de funcionar.

Luego, Google cerró por completo su soporte para feeds RSS en diciembre de 2017. La compañía no dio ninguna razón para eliminar el soporte para feeds RSS en su aplicación Google News.

Como resultado, los usuarios no tuvieron más remedio que buscar enlaces RSS alternativos para cada feed que agregaron a la aplicación Google News, mientras que los enlaces privativos y no abiertos de Google News continuaron funcionando bien.

Google sigue en ello…

El incidente más reciente ocurrió en mayo de 2021, cuando Google anunció que están trabajando en una actualización de Google Chrome que recupera la compatibilidad con RSS.

Pero no ha habido noticias sobre un lanzamiento oficial desde que se anunció hace años. No está claro cuáles serán las implicaciones de esta característica. Pero está claro que Google tiene un historial de crear productos con RSS y eliminar el soporte RSS una vez que ha establecido una base de usuarios.

Por lo tanto, no hay garantía de que, incluso si se lanza la función, seguirá estando disponible y siendo confiable para los usuarios de RSS con el tiempo.

Debido a que Google sin duda tiene una enorme influencia, esperamos que comprenda que incorporar funciones RSS en sus productos y luego eliminarlas afecta negativamente la percepción y la confianza del usuario en torno a RSS en general.

Los canales RSS son una parte vital de la web abierta. Por lo tanto, si Google decide continuar integrando funciones RSS en sus productos, es fundamental que las respalde, las mantenga a lo largo del tiempo y se asegure de que siempre sigan siendo una prioridad.

Si has leido hasta aquí, espero que te haya resultado interesanta esta interesante recopilación de lo que la gran empresa Google ha realizado con los RSS y los estándares abiertos.

Por mi parte sigo utilizando los RSS en mis equipos usando Akregator, aunque en el blog he escrito artículos y tutoriales sobre otros programas para recopilar los feeds RSS.

Además los feeds son la base sobre la que se mantiene PlanetaLibre, el agregador de blogs y webs en español sobre GNU/Linux y software libre. ¡Al que de hecho te puedes suscribir también mediante RSS!

¿Usas RSS? ¿Conoces este método de consultar aquello que te interesa? ¿Tienes algo que compartir al respecto? Usa los comentarios para compartirlo.

There are several changes happening in openSUSE’s rolling release Tumbleweed on a daily basis and integrating systemd-boot into has been evolving.

A shift from the traditional GRUB boot loader is promising better system boot performance and security.

An all-systems-go presentation by Ludwig Nussel sheds some light on the motivations, challenges and future direction of systemd-boot integration in openSUSE.

The primary motivation behind adopting systemd-boot lies in its simplicity and efficiency, especially when handling full-disk encryption. Traditional boot loaders like GRUB require embedding decryption code and key derivation functions that can complicate the boot loader code and the boot process; this could slow down the system at startup. With systemd-boot, these responsibilities are delegated to the Linux Kernel and user space, which helps to streamline the boot process.

MicroOS and Tumbleweed’s use of Btrfs and its snapshotting capabilities adds complexity to the boot process; this is being addressed by integrating systemd-boot with the snapshot management system to ensure each snapshot boots successfully and that kernel updates are handled gracefully within this dynamic environment.

To facilitate this integration, new packaging scripts and tools like sdbootutil were introduced to manage kernel versions, snapshots and boot entries. This tool plays a crucial role in making systemd-boot a practical choice for openSUSE users, as the way that the snapshots are managed are different in MicroOS than in Tumbleweed.

Using sdbootutil, the system will create new Type #1 boot entries in the EFI System Partition (ESP) to represent all the avaliable boot options, which will copy from the snapshot the new installed kernels into this partition. It will also generate good initrd for those snapshots.

When using full disk encryption, sdbootutil will also call the different commands that will update the policies required to automatically unlock the new snapshots using the internal Trusted Platform Module 2.0 (TPM2) device of the system.

Ideally, in the future, some if not all of this functionallity will be exported into systemd itself or other systems components in the distribution. These changes make this tools a good place to experiment, validate or discard the different approaches that openSUSE is leading with systemd-boot.

At this point, systemd-boot support in openSUSE is still considered experimental. Both Tumbleweed and MicroOS yast installers offer systemd-boot as an alternative to grub for the brave. There are also ready-made appliances for qemu that use systemd-boot and full-disk encryption by default.

Ayer mismo comentaba que el equipo de desarrollo de KDE había elaborado una guía para portarlos temas globales a Plasma 6 pretendiendo facilitar la migración de estos elementos tan característicoas de nuestro escritorio a los diseñadores. Pues bien, no sé si el gran Jomada ha seguido esa guía o no pero se ha apuntado el tanto de crear el primer tema Global Para Plasma 6 que ha bautzado con el nombre de Nothing (¿tendrá relación con el gran tema de Depeche Mode?) y que merece ser reconocido en este blog.

Primer tema Global Para Plasma 6: Nothing

Antes lo digo, antes aparece. Ya tenemos disponible para su descarga y aplicación algnos temas globales en la KDE Store. No obstante, y dado que suelo aprovecharme de su trabajo, hoy quiero rendir tributo al primer tema global de Plasma 6 que incluso me pareció ver que estaba incluído en el lanzamiento.

Este tema que destaca por su oscuridad y elegancia, combinando negros y grises, destacando la utiización de un rojo vivo que, evidentmente, contrasta y le mucha vida. Ha sido creado por Jomada, uno de los diseñadores más prolíficos, y en mi humilde opinión, con más gusto del ecosistema de la Comunidad KDE. Para este tema el propio Jorge recomienda el uso del tema de iconos Colloid Grey-black con lo que queda de fábula, como podéis ver en las imagen inferior.

Desde aquí agradezco de antemano el trabajo de estos diseñadores anónimos (porque aunque todo está referenciado poco caso se les hace) que invierten su tiempo en proporcionarnos opciones de tan alta calidad.

Más información: Tema Global Nothing KDE Store

Guía para portar los temas globales a Plasma 6

Debido al lanzamiento de KDE 6 (Plasma, aplicaciones y motor), y como se podía intuir, no solo el API de Plasma utilizada para crear widgets de escritorio (también conocidos como «applets» o «plasmoides«) ha cambiando sino que también se han visto afectados los temas globales, con lo que todos estos paquetes de software que cambian de con un simple click todo el aspecto de tu escritorio deberán ser adaptados ya que se pierde la compatibilidad.

Esto es tanto así que ya se ha creado la sección propia para temas de Plasma 6 en la KDE Store, aunque en el momento de escribir este artículo, ya hay casi una decena lo cual es significativo ya que nos augura un buena cantidad de opciones de personalización para nuestro entorno de escritorio en un periodo de tiempo muy corto.

Con la intención de que esto ocurra en el menor tiempo posible y que en breve tengamos un buen número de estas delicas visuales ideales para personalizar nuestro entorno de trabajo los diseñadores de KDE han creado una breve guía para portar los temas globales a Plasma 6.

En esta guía se especifica las novedades (como que ahora los temas son tratados como un kpackage lo que significa que necesitan de un archivo manifest.json para ser utilizados de forma correcta) o los grandes cambios (como que ya no se pueden utilizar enlaces simbólicos para cargar un tema Plasma).

Por supuesto, hay muchos cambios más como el cambio de nombre de las importaciones QML, en los scripts de diseño de escritorio, en las pantallas de bloqueo personalizadas o en los temas de inicio de sesión SDDM

En resumen, una excelente iniciativa que seguro que los desarrolladores de estas pequeñas (o no tanto) maravillas para nuestro

Más información: KDE Develop

La entrada Primer tema Global Para Plasma 6: Nothing 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.

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/2024/march
• Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2024/marzo

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

Después de muchos años colaborando en la traducción al español del boletín, desde inicios del año 2020 decidí tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿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 marzo de 2024.

Los demócratas vuelven a la carga, tratando de romper los algoritmos de caja negra abiertos

Del 16de febrero porThomas Claburn

Los legisladores demócratas han propuesto una vez más una legislación para garantizar que el código fuente del software utilizado para las investigaciones criminales pueda ser examinado y esté sujeto a pruebas estandarizadas por parte del gobierno.

El 15 de febrero, los representantes de la Cámara de Representantes Mark Takano (D-CA) y Dwight Evans (D-PA) reintrodujeron la Ley de Justicia en Algoritmos Forenses de 2024, un proyecto de ley que prohíbe el uso de afirmaciones de secretos comerciales o que los abogados defensores revisen el código fuente relevante para casos penales y establece un régimen federal de pruebas para software forense.

Dado que se puede utilizar software privativo para encarcelar de por vida a un presunto delincuente, es imperativo que estos programas sean software libre para garantizar un juicio justo.

• https://www.theregister.com/2024/02/16/black_box_government/

El software libre no es la antítesis del éxito comercial

Del 12 de febrero

Un malentendido común con respecto al concepto de software libre, o una pregunta que puede verse planteada por personas en Internet en diferentes salas de chat, foros y demás, proviene de la idea errónea de que «libre» en «software libre» significa libre como tal en «cerveza gratis», es decir, gratis.

En este artículo, Gabriel Cezarin Popovici, pasante del equipo de campañas de la Free Software Foundation (FSF), explica por qué desarrollar software libre y ganar dinero no tienen por qué excluirse mutuamente.

• https://www.fsf.org/blogs/community/free-software-is-not-antithetical-to-commercial-success

Noticias de GNU Emacs de febrero

Del 26 de febrero Sacha Chua

Sacha Chua recopila unos cuantas noticias de este mes de febrero sobre las novedades en GNU Emacs.

• 2024-02-26
• 2024-02-19
• 2024-02-12
• 2024-02-05

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/2024/marzo

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

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

—————————————————————

1) Introduction

The dnf5daemon-server component offers a collection of D-Bus interfaces to interact with the dnf5 package manager on the system. An openSUSE community packager wanted to add the additional D-Bus component to the openSUSE Tumbleweed distribution. New D-Bus system services require a review by the SUSE security team. In the course of this review I found the issues described in this report.

The version of dnf5 I reviewed for this is 5.1.9, and any source code references below are based on the corresponding version tag in the upstream Git repository.

2) D-Bus Interface Design

The dnf5daemon-server offers a main interface “org.rpm.dnf.v0.SessionManager” on which clients can create a new session, which results in a new dynamically allocated D-Bus object being registered on the bus. This session object provides a set of additional D-Bus interfaces for modifying package manager configuration, for installing or removing packages or for inspecting metadata about packages and repositories on the system.

The dnf5daemon-server is running as root and can be autostarted via the D-Bus system bus if it is not already running. Any other users with access to the D-Bus system bus may talk to it.

For certain privileged operations the D-Bus service implements Polkit authentication. Only three operations are protected by Polkit:

• org.rpm.dnf.v0.rpm.RepoConf.write
• org.rpm.dnf.v0.rpm.execute_transaction
• org.rpm.dnf.v0.rpm.Repo.confirm_key

These relate to changing the repository configuration, executing transactions or importing new trusted signing keys. Transactions cover all kinds of changes introduced through the package manager.

All of these operations require auth_admin privileges on Polkit level. The integration of the Polkit authorization logic is correct as far as I can tell.

The per-session D-Bus interface provided by dnf5daemon-server is rather large and many calls take additional key/value maps to tune the behaviour of the package manager logic contained in libdnf5. In summary, the libdnf5 library is attached very closely to the D-Bus system bus via dnf5daemon-server.

3) Local Root Exploit via Configuration Dictionary (CVE-2024-1929)

While the privileged operations mentioned above are correctly protected by Polkit, there are issues with the D-Bus interface long before Polkit is even invoked.

The org.rpm.dnf.v0.SessionManager.open_session method takes a key/value map of configuration entries. A sub-entry in this map, placed under the “config” key, is another key/value map. The configuration values found in it will be forwarded as configuration overrides to the libdnf5::Base configuration. The spot where this happens is found in session.cpp:63.

Practically all libdnf5 configuration aspects can be influenced here, as can be seen in the ConfigMain class in config_main.hpp. Already when opening the session via D-Bus, the libdnf5 will be initialized using these override configuration values. There is no sanity checking of the content of this “config” map, which is untrusted data.

There are surely a lot of different ways to exploit this possibility to influence the libdnf5 configuration. The simplest approach to get full root privileges I found is to trick the library into loading a plug-in shared library under control of the unprivileged user.

To do this, the “pluginpath” and “pluginconfpath” configuration entries need to be supplied and need to point to a user-controlled path. There the unprivileged user can place a configuration file that in turn points towards a user controlled shared library. The library will then dlopen() this user controlled shared library, which will lead to full code execution in the context of the root user.

3.1) Proof of Concept

A proof of concept I wrote shows this vulnerability in action. I successfully tested this exploit also on Fedora 39 using dnf5daemon-server version 5.1.10. The only precondition for this exploit is that the dnf5daemon-server package is installed on the system. Any local user, even nobody, can obtain root privileges this way.

3.2) Bugfix

To fix this, I suggested to enforce a whitelist of configuration parameters that are allowed to be overridden. Only a very small subset of values should be allowed for unprivileged clients.

In upstream commit e51bf2f0d such a whitelist enforcement has been implemented for dnf5daemon-server.

3.3) CVE Assignment

Red Hat Product Security assigned CVE-2024-1929 for this issue.

4) No Limit on Number of Open Sessions / Bad Session Close Behaviour (CVE-2024-1930)

There is no limit on how many sessions D-Bus clients may create using the open_session() D-Bus method. In my tests I was able to quickly create about 4,500 sessions and keep them open. For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service.

In some cases I even managed to cause the D-Bus service to abort() as a result of hitting resource limits. If the service continues running and the client disconnects, then the cleanup code found in SessionManager::on_name_owner_changed() runs for each session that has been created. Each Session holds a ThreadsManager, where the thread associated with each session originates from. It is a thread that is busy-waiting to join other threads, the code for this is found in threads_manager.cpp:33. Since there is a sleep of one second in this thread’s loop it takes about ~4,500 seconds for all the threads from the 4,500 sessions to be joined one by one. The service will be unreachable for more than an hour.

4.1) Bugfix

To fix this, I suggested to limit the number of sessions for each unprivileged user in the system to a sensible value. Also the busy-wait loop in ThreadsManager seems ill-devised. Maybe using a condition variable to inform the cleanup thread of new work would be more efficient. Having a dedicated ThreadsManager and join-thread for each session seems a bit overkill, too.

In upstream commit c090ffeb79 the maximum number of sessions is limited to three sessions. The problematic thread joining behaviour has not been addressed as of now.

4.2) CVE Assignment

Red Hat Product Security assigned CVE-2024-1930 for this issue.

5) Untrusted locale Setting for each Session

Another part of the per-session setup is the use of an untrusted locale setting in session.cpp:54. This string is passed to the C library’s newlocale() function in threads_manager.cpp:92. A danger here is that arbitrary user controlled files or symlinks could be processed by the C library, which could lead to various issues like information leaks, denial of service or even code execution. I looked into the GNU glibc implementation of newlocale(), and luckily it already implements a very careful locale lookup algorithm, that prevents that arbitrary paths are accessed if crafted locale strings are passed to it. This outcome might change if a different C library is used.

Whether anything bad could happen, apart from file system issues, when exotic locales are selected for a thread running in dnf5daemon-server is another question that I did not investigate more closely.

For hardening purposes I suggested that dnf5daemon-server performs a sanity check of the locale string to prevent a string that contains e.g. a slash character / from being used. I don’t know of any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

6) dnfdaemon-client Demands Full Root

Although the D-Bus service implements Polkit for privileged operations, the dnf5daemon-client refuses to perform privileged operations for non-root users. For example:

user$ dnf5daemon-client distro-sync
This command has to be run with superuser privileges (under the root user on most systems).

The code for this is found in various sub-command implementations:

$ grep -r 'throw UnprivilegedUserError' -C 1
dnf5daemon-client/commands/downgrade/downgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/downgrade/downgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/downgrade/downgrade.cpp-    }
--
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/distro-sync/distro-sync.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    }
--
dnf5daemon-client/commands/install/install.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/install/install.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/install/install.cpp-    }
--
dnf5daemon-client/commands/remove/remove.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/remove/remove.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/remove/remove.cpp-    }
--
dnf5daemon-client/commands/upgrade/upgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/upgrade/upgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/upgrade/upgrade.cpp-    }
--
dnf5daemon-client/commands/reinstall/reinstall.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/reinstall/reinstall.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/reinstall/reinstall.cpp-    }

It doesn’t make sense that the client forces users to run as root (and thereby increase the attack surface by running also the client code as root) when the service could authenticate the user via Polkit.

I suggested to drop this root-check code in the client, and rely on the authentication logic in the service side code. If authentication fails, then the client code can still hint at the possibility to run the program as root. I am not aware on any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

7) General Review Summary

In summary my impression is that the libdnf5 library is too closely connected to the D-Bus system bus. The library itself is unaware of the fact that it is running with partially untrusted input. The dnf5daemon-server code needs to carefully filter untrusted input before it is passed to the generic library code.

8) Timeline

9) References

• dnf5 repository on GitHub
• dnf5 5.1.9 Git version tag (the version that has been reviewed)
• code that imports untrusted configuration settings into libdnf5
• bugfix commit for issue 3)
• bugfix commit for issue 4)

El pasado 28 de febrero fue el megalanzamiento 6 de la Comunidad KDE. De una tacada tuvimos disponible Plasma 6, KDE Gears 24.02 y KDE Frameworks 6, la trinidad del desarrollo de KDE. Pero en realidad faltaba una pieza de este gran engranaje. Me complace compartir con vosotros que Plasma Mobile salta también a Plasma 6, con lo que ya tenemos todas las columnas el proyecto preparadas para seguir evolucionando y llevando el Software Libre a nuevas cuotas de grandeza.

Plasma Mobile salta también a Plasma 6

Se me acumulan los lanzamientos. Tengo pendiente desgranar todos los lanzamiento de la Comunidad KDE pero hoy domingo quiero dedicarlo al proyecto dedicado a los dispositivos más portables que podemos tener en nuestras manos: los smartphones y las tabletas.

Y es que el pasado 1 de marzo fue anunciado que a la estela del Megalanzamiento se realizaba también el salto de Plasma Mobile a las tecnologías Qt6/KF6 de la Comunidad KDE, lo cual significaba una mejora importante y, lo más importante, la sincronización de todos los productos de la «marca» KDE.

En palabras de sus desarrolladores:

El equipo de Plasma Mobile se complace en anunciar el lanzamiento de Plasma 6 para dispositivos móviles.
Ha sido un largo año de desarrollo y adaptación desde nuestra última versión importante del shell, así como de las aplicaciones móviles.

Y, a continuación, nos invitan a leer su larga entrada donde describen las novedades más detacadas y nos emplazan visitar una entrada específica Devin de para conocer los detalles técnicos de Plasma 6 en Plasma Mobile.

Más información: Plasma Mobile

¿Qué es Plasma Mobile?

Para los que no lo conozcan Plasma Mobile es la alternativa libre a interfaz gráfica para smartphones de la Comunidad KDE, hablé de él hace un tiempo y, poco a poco, se está convirtiendo en un clásico del blog.

Su idea es muy simple, tras conquistar tu escritorio KDE la Comunidad también quiere conquistar tu teléfono móvil… aunque todavía lo tenga complicado por todas las limitaciones de hardware que todavía tiene este campo de la tecnología.

No obstante, confiemos que de igual forma se han ido conquistando los ordenadores de sobremesa, portátiles y servidores, lleguemos un día que podamos tener libertad total en nuestros smartphones.

Y para cuando eso ocurra la Comunidad KDE estará preparada para ello y por eso está confeccionando un catálogo más que decente de aplicaciones con tecnología adaptativa.

La entrada Plasma Mobile salta también a Plasma 6 se publicó primero en KDE Blog.

Hace unos días lo comentaba, los grandes cambios de versiones tienen una cara extremadamente positiva ( ya que de lo contrario no se realizarían) y algunos aspectos negativos como puede ser un número de bugs más alto de lo habitual o la pérdida de funcionalidades o plasmoides temporal… o la imposibilidad de usar temas globales si no se hacen algunos cambios. Como ocurrió con los plasmoides, el equipo de desarrollo de KDE ha elaborado una guía para portar los temas globales a Plasma 6 y que pretende facilitar la migración de estos elementos tan característicoas de nuestro escritorio. En mi opinión, como dije con los plasmoides, una extraordinaria iniciativa.

Guía para portar los temas globales a Plasma 6

Como ya se podía intuir, no solo el API de Plasma utilizada para crear widgets de escritorio (también conocidos como «applets» o «plasmoides«) ha cambiando para la versión Plasma 6.0 sino que también se van a ver afectados los temas globales, con lo que todos estos paquetes de software que cambian de con un simple click todo el aspecto de tu escritorio deberán ser adaptados ya que se pierde la compatibilidad.

Esto es tanto así que ya se ha creado la sección propia para temas de Plasma 6 en la KDE Store, aunque en el momento de escribir este artículo, no hay ninguno creado, lo cual es significativo y, evidentemente, deber ser solucionado con rapidez.

Con la intención de que esto ocurra en el menor tiempo posible y que en breve tengamos un buen número de estas delicas visuales ideales para personalizar nuestro entorno de trabajo los diseñadores de KDE han creado una breve guía para portar los temas globales a Plasma 6.

En esta guía se especifica las novedades (como que ahora los temas son tratados como un kpackage lo que significa que necesitan de un archivo manifest.json para ser utilizados de forma correcta) o los grandes cambios (como que ya no se pueden utilizar enlaces simbólicos para cargar un tema Plasma).

Por supuesto, hay muchos cambios más como el cambio de nombre de las importaciones QML, en los scripts de diseño de escritorio, en las pantallas de bloqueo personalizadas o en los temas de inicio de sesión SDDM

En resumen, una excelente iniciativa que seguro que los desarrolladores de estas pequeñas (o no tanto) maravillas para nuestro

Más información: KDE Develop

La entrada Guía para portar los temas globales a Plasma 6 se publicó primero en KDE Blog.

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

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

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

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

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

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

• https://dominique.leuenberger.net/blog/2024/03/opensuse-tumbleweed-review-of-the-week-2024-09/

Esta semana se han publicado 6 nuevas snapshots (0223, 0225, 0226, 0227, 0228, y 0229) con cambios tan importantes como estos:

• libjxl 0.10.0 & 0.10.1
• Samba 4.19.5
• Linux kernel 6.7.6
• mdadm 4.3
• Mozilla Firefox 123.0
• chrony 4.5
• openSSH 9.6p1
• fwupd 1.9.14
• exiv2 0.28.2
• Ruby 3.2 ha sido eliminado: esto incluye todas las gemas de ruby y el interpretador de ruby 3.2

Y para próximas actualizaciones, se está trabajando en:

• ImageMagick 7.1.1.29
• openblas 0.3.26
• openjpeg 2.5.1
• KDE Frameworks and Plasma 6
• KDE Gear 24.02.0 – Requiere KDE Frameworks 6
• Systemd 255.3
• dbus-broker
• libxml 2.12.x
• GCC 14

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

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

Enlaces de interés

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

——————————–