Table of Contents

• 1) Introduction
• 2) Local DoS Issue via UNIX Domain Socket (CVE-2025-62875)
  • Memory Leak on Regular Connection Close
  • Workaround by Adjusting Socket Permissions
  • Reproducer
  • Affected Versions
  • Affected Systems
  • CVE Assignment
  • Upstream Bugfix
• 3) Notes on setuid and setgid Binaries
  • lockspool
  • smtpctl
• 4) Notes on the Network-Facing OpenSMTPD Code
• 5) Timeline
• 6) Links

1) Introduction

OpenSMTPD is an implementation of the server-side SMTP protocol offered by the OpenBSD project. A few months ago a SUSE colleague started packaging it for openSUSE Tumbleweed, which led to a code review of the package.

While looking into a local API offered by OpenSMTPD we discovered a trivial local Denial-of-Service (DoS) attack vector which allows unprivileged users to cause the shutdown of all smtpd services. The full details about the issue follow in section 2. Some additional remarks about setuid-root and setgid utilities contained in OpenSMTPD are found in section 3. A quick survey of the network-facing code of OpenSMTPD is provided in section 4.

Note that two source code repositories for OpenSMTPD exist. The most up-to-date code is found in the OpenBSD CVS repository, while the portable version is found on GitHub. The portable version offers cross platform support for various kinds of UNIX systems, including Linux and the other BSDs. This report is based on the portable OpenSMTPD version 7.7.0p0.

We reported the local DoS issue to upstream but did not get a response until two days before publication, due to communication issues. By now an upstream bugfix is available which will be part of a pending 7.8.0 release, but it seems an independent memory leak issue remains unaddressed.

2) Local DoS Issue via UNIX Domain Socket (CVE-2025-62875)

OpenSMTPD contains the smtpctl program, which communicates with the smtpd: control daemon instance via a UNIX domain socket in /var/run/smtpd.sock. While looking into the protocol used for this purpose, we noticed a trivial local Denial-of-Service attack vector affecting all of OpenSMTPD.

The UNIX domain socket smtpd.sock has file mode 0666 and is thus writable for all users in the system, allowing anybody to create local connections towards smtpd.

In the daemon’s code in mproc_dispatch() the process exits via fatal() in case anything goes wrong while handling such a UNIX domain socket connection. Two common error situations leading to this are bad returns from readv() in ibuf_read() or a bad message length value in the message header, which is detected in imsg_parse_hdr(). Similar error conditions exist in the msgbuf_read() call path which is used when file descriptor passing is enabled on the connection (see imsgbuf_read()).

As a result, sending a malformed message with a bad header length is enough for a client to provoke the invocation of fatal() on the daemon side. Once fatal() is called, the smtpd: control instance ends execution and causes the whole smtpd instance to be shut down along with it.

We learned from upstream that the reason for the call to fatal() is that smtpd.sock is used for two different purposes at the same time:

• connections from other, trusted smtpd daemon instances.
• connections from arbitrary other clients using the smtpctl program.

The call to fatal() is made with the first kind of connections in mind. These connections are established during startup, and if anything goes wrong while processing data from other smtpd daemon instances, then a bug in OpenSMTPD itself is assumed, and a shutdown of all daemon processes is a viable course of action.

The second kind of connections was left unconsidered in this logic, thus allowing unprivileged clients to trigger this code path which leads to the local DoS. The upstream bugfix consequently consists of an added if clause which excludes the second type of connections from the call to fatal().

Memory Leak on Regular Connection Close

While looking into a possible bugfix for the DoS issue, we noticed a comment in the code, which points to unsolved cleanup issues, when processing a connection fails:

ibuf_read_process(struct msgbuf *msgbuf, int fd)
{
    /* <<< SNIP >>> */
fail:
    /* XXX how to properly clean up is unclear */
    if (fd != -1)
        close(fd);
    return (-1);
}

This made us wonder, if the cleanup is unclear in error conditions, is it maybe also unclear during regular operation? After all, proper cleanup will be needed regardless of whether a connection ends gracefully or not. As it happens, the cleanup logic for a regular connection close and for an erroneous connection close indeed is equivalent in OpenSMTPD.

To this end, we tested what happens when a lot of UNIX domain socket connections towards smtpd are created and closed in succession. The outcome indeed is that the memory used by the smtpd: control instance continuously grows. Thus it seems there is a memory leak present here as well independently of the main issue described above. We did not analyze this in more detail, but upstream is aware of the issue and is analyzing it on their end.

This independent issue means that unprivileged clients can trigger the memory leak in the smtpd: control daemon, even after applying the upstream bugfix to fix the main issue in this report. The impact will also be a local DoS, it will take a much longer time to execute it, however, because the memory leak is small and in our tests only consumes about 100 megabytes within half an hour. The next section describes a possible temporary workaround to avoid this issue, as well.

Workaround by Adjusting Socket Permissions

We initially suggested a different patch to address the local DoS issue, tightening the permissions of the smtpd.sock UNIX domain socket. We wrongly assumed that there were no valid use cases for non-root users connecting to this socket. Shortly before publication we learned from upstream that there actually is a valid use case for this scenario: non-root users can enqueue mail using the sendmail interface, which makes use of this socket.

Even though our suggested patch causes a regression in this case, it reduces attack surface and provides protection against the memory leak described in the previous section. For some users of OpenSMTPD it can thus be a sensible option to use this patch if the described use case is not needed, at least until upstream provides a fix for the memory leak issue, as well.

Reproducer

We offer a simple Python script to reproduce the issue. The script creates a connection towards smtpd.sock and sends an excessive header length. If the reproducer works, the smtpd daemon processes will all exit immediately.

Affected Versions

In commit 3270e23a6eb, which first made its way into version 7.7.0, major changes to the message parsing code have been introduced, including the call to fatal(). Triggering the issue was easily possible in our tests for all packages based on this version.

It is unclear if older versions might be affected by some variant of this issue as well. We only verified that the trivial reproducer does not work against version 7.6.0 of OpenSMTPD.

Affected Systems

We verified that the issue affects the following systems, which all offer OpenSMTPD version 7.7.0:

• Arch Linux (fully updated on 2025-09-29)
• Debian 13
• Fedora 42
• Gentoo Linux using the 7.7.0p0 ebuild
• OpenBSD 7.7
• NetBSD 10.1 (using the package available from pkgsrc)

On FreeBSD 14.2, where only the older version 7.6.0 of OpenSMTPD is available, we could not reproduce the issue.

CVE Assignment

Without a formal confirmation from upstream we were reluctant to assign a CVE for the issue. The case seemed clear-cut, however, and when we were asked to provide a CVE on the distros mailing list, we assigned CVE-2025-62875 and also communicated this to upstream.

When contact to upstream was established shortly before the publication of this report, upstream picked up this CVE and used it to document their bugfix.

Upstream Bugfix

Upstream already published the bugfix commit for the main issue in this report. The release of OpenSMTPD version 7.8.0 containing this bugfix is expected soon, and was already announced on the upstream mailing list.

3) Notes on setuid and setgid Binaries

The original reason for reviewing OpenSMTPD in the first place was the presence of setuid and setgid binaries in the package. The following sub-sections give a short summary of the outcome of the review.

lockspool

/usr/libexec/opensmtpd/lockspool is a world-accessible setuid-root binary which is used to synchronize parallel access to a user’s spool.

The lockspool code found in the OpenSMTPD portable release is quite complex and is based on some assumptions that might not hold true. This code can allow for a minor local DoS in multi-user scenarios. The OpenBSD CVS repository already contains a simplified locking algorithm which is not affected by this.

We reached out to upstream about this separately from the UNIX domain socket DoS issue. In this instance we quickly got a reply and upstream merged the change from the CVS repository into the OpenBSD portable repository. This change will be part of the OpenSMTPD 7.8.0 release. We backported the change into the openSUSE packaging of OpenSMTPD as well.

smtpctl

/usr/sbin/smtpctl is a world-accessible setgid binary operating in _smtpq group context. The program uses these special group privileges to store mail in the directory
/var/spool/smtpd/offline, when the smtpd services are not running.

The _smtpq group privileges are only used for this well defined purpose and the extra privileges are also dropped as soon as they are no longer needed. We found no issues in this aspect of the program.

4) Notes on the Network-Facing OpenSMTPD Code

After we found the local security issues described in this report, we thought it a good idea to also have at least a cursory look at the actual network-facing SMTP protocol parsing code found in OpenSMTPD. We could not find any tangible security issues in these parts, still here is a short summary of our impression of the code:

• the protocol parsing is implemented in plain C and thus error prone. The implementation does have this under control, however, even though there is some redundancy in handling the various message types.
• a lot of parsing is done manually without the help of third party libraries, including things like domain name end email address verification.
• transmission of plaintext passwords is rejected on unencrypted connections, which is a good security stance.
• the daemon processing network data is running with limited service user credentials and is also placed into a chroot jail, which reduces attack surface.
• the daemon logs every bad SMTP protocol message by default, including attacker controlled data, which is a bit peculiar. The logging systems on the BSDs and Linux systems we looked into are able to deal with this in safe ways, however (e.g. terminal escape sequences are escaped or stripped).

5) Timeline

6) Links

• OpenSMTPD website
• OpenSMTPD portable Git repository
• Suggested patch to work around the issue (includes a possible regression!)
• Upstream bugfix of the issue (leaves a memory leak issue unaddressed)
• Python script to reproduce the issue
• openSUSE Bugzilla review bug for OpenSMTPD

hoy me complace compartir con vosotros un nuevo episodio de Compilando Podcast, que ha vuelto con fuerza en forma de DOS episodios tipo píldora muy instructivos. En esta ocasión se trata del episodio 61 que lleva por título «IA Open Source ¿transparencia real o etiqueta de marketing?» donde Paco nos explica que no por llevar la etiqueta Open Source realmente nos encontramos con algo libre.

IA Open Source ¿transparencia real o etiqueta de marketing? en Compilando Podcast

En palabras del gran Paco Estrada, extraídas de la nueva web de Compilando Podcast y que sirven de introducción del episodio 61:

En este episodio de Compilando Podcast exploramos el debate sobre la inteligencia artificial open source. ¿Qué significa realmente, en qué se diferencia del software libre clásico y por qué está generando tanta controversia?. Analizamos las licencias bajo las que se liberan los principales modelos —desde GPT o Claude, cerrados; hasta LLaMA o Mistral, con distintos grados de apertura. También revisamos la definición propuesta por la Open Source Initiative (OSI) para “Open Source AI”.

Un viaje por el presente y futuro de la «IA abierta», donde se cruzan intereses científicos, empresariales y regulatorios. ¿Qué partes de un modelo deben estar realmente abiertas: el código, los pesos, los datos? Y lo más importante: ¿qué impacto tendrá esa respuesta en el acceso, la transparencia y la confianza en la Inteligencia Artificial?

Música: https://incompetech.filmmusic.io/ by Kevin McLeod y musopen.org

Licencia : Creative Commons (CC BY-NC-SA)

Más información: Compilando Podcast

¿Qué es Compilando Podcast?

Dentro del mundo de los audios de Software Libre, que los hay muchos y de calidad, destaca uno por la profesionalidad de la voz que lo lleva, el gran Paco Estrada, y por el mimo con el que está hecho. No es por nada que ganó el Open Awards’18 al mejor medio, un reconocimiento al trabajo realizado por la promoción .

A modo de resumen, Compilando Podcast es un proyecto personal de su locutor Paco Estrada que aúna sus pasiones y que además, nos ofrece una voz prodigiosa y una dicción perfecta.

La entrada IA Open Source ¿transparencia real o etiqueta de marketing? en Compilando Podcast se publicó primero en KDE Blog.

Las historias más escalofriantes del software privativo acechan en cada época del año. Ese acoso constante es el que las hace todavía más aterradoras

Aunque las monstruosidades escalofriantes de la larga y oscura noche de Walpurgis sean en su mayoría imaginarias, las siniestras amenazas de los proveedores de software privativo depredador siguen siendo demasiado reales.

¡Pero no temáis! La comunidad KDE, se encargarán de ahuyentar a esos seres malignos y proteger a nuestros amigos, familiares, empresa y comunidad de todas las aplicaciones y servicios privativos inquietantes e insidiosos que acechan nuestras computadoras, teléfonos y electrodomésticos.

¡Pero no pueden hacerlo solos! Necesitamos tu ayuda para librar esta batalla contra los fantasmas tecnológicos. Realiza un donativo de cualquier cantidad a su campaña de recaudación de fondos y ayudemosles a mantener a raya a las fuerzas oscuras.

Mientras tanto, disfrutemos (o suframos) con un par de nuevas historias que nos provocarán ansiedad y reflexionen sobre las lecciones que nos enseñan. Aprendamos de ellas, porque para los protagonistas, ya era demasiado tarde…

La noche de las camas vivientes

Una epidemia de tortícolis, lumbalgia y dolor de hombros fue la primera señal de que algo andaba muy mal.

Luego, Charles, nuestro querido vecino de 80 años, postrado en cama, murió doblado por la mitad «¡Como un taco!», lamentó desconsolada su viuda. Nadie podía comprender cómo su cuerpo artrítico había logrado adoptar semejante forma.

Cuando la pareja de tres casas más abajo murió asfixiada mientras dormía, la historia dio un giro aún más extraño. Las empleadas de la limpieza los encontraron con tela acolchada y espuma viscoelástica introducidas en sus gargantas.

Haz clic para revelar la dramática historia detrás de estos espeluznantes sucesos

Es la segunda semana y ya no nos atrevemos a subir. Oímos cómo «ellos» hacen ruido arriba, intentando salir. Por ahora estamos a salvo en la planta baja, ya que todavía no dominan los pomos de las puertas ni las escaleras.

Salir de casa para escapar no es una opción. Observamos horrorizados desde la ventana de la cocina cómo un pobre incauto lo intentaba. Corrió hacia su coche, pero una enorme cama California King, sorprendentemente ágil para su tamaño, lo alcanzó. La gigantesca losa grisácea le cayó encima, aplastándolo como a un insecto.

Otros aparatos se están sumando. La última vez que probamos el filtro de agua inteligente, nos dio una mezcla tan asquerosa que nos hemos visto obligados a beber directamente del grifo.

¡Qué horror!

No podemos confiar en nada electrónico. La televisión nos mantiene confundidos con noticias falsas: ¿algo sobre la demolición de la Casa Blanca? Obviamente, se trata de IA; así que no tenemos ni idea de si es un fenómeno global o si solo afecta al microverso de nuestra tranquila calle sin salida en las afueras.

Estoy escribiendo estas memorias en la encimera de la cocina con un cuchillo, ya que el iPad ya estaba conspirando contra la humanidad incluso antes de que lo sacáramos de la caja. En resumen, si alguien lee esto, espero que sirva de advertencia a las futuras generaciones, menos ingenuas.

Sea quien sea, escuche atentamente mi advertencia: ¡Por nada del mundo se le ocurra comprar una cama conectada a la nube de AWS!

El software de KDE funciona de manera local en tu equipo, directamente en tu ordenador, sin conectarse a ningún servicio en línea a menos que tú lo decidas. No tendrás que crear una cuenta para usar Krita; KDE Connect conecta todos tus dispositivos ÚNICAMENTE en tu red local doméstica o de trabajo, sin conectarse nunca a Internet; Kdenlive solo descargará recursos cuando se lo pidas explícitamente. Con KDE, todo tu software está bajo tu control absoluto y no recibirá órdenes de servidores en línea.

Al donar a KDE, garantizas que esa comunidad de software libre pueda seguir ofreciéndote aplicaciones y entornos que te permiten mantener el control, proteger tu privacidad y evitar que te causen problemas mientras duermes.

El color de los residuos

Caminando por el denso bosque, uno llega al Páramo Estéril de forma gradual. Rodeado de helechos, bajo la sombra de árboles de veinte metros de altura, apenas se percata de que, a partir de cierto punto, la maleza comienza a volverse más escasa.

Pero si uno se adentra lo suficiente en el páramo, lo nota. Pronto, no hay vegetación alguna bajo los pies. Los pocos árboles, con hojas amarillas y escasas, yacen a ras del suelo, con los troncos retorcidos y debilitados por la putrefacción.

Haz clic para revelar la dramática historia detrás de estos espeluznantes sucesos

Llegué a una aldea. El sendero que seguía se convirtió en un camino fangoso entre chozas destartaladas. Vi a poca gente, pero también estaban demacrados y arrugados, la mayoría solo podía caminar con dos bastones.

Me miraron con recelo y no respondieron a mi saludo. Seguí adelante apresuradamente, llegando pronto al límite norte del páramo.

La vegetación volvía a espesarse cuando divisé una cabaña y a un anciano fumando en pipa en el umbral.

—¿Vienes de la ciudad? —preguntó.

—Sí —respondí—. Es un lugar precioso.

—El sol te debe haber afectado los ojos si piensas eso —rió—. Ven, tómate algo y deja que se te pase el enfado.

Cansado de caminar, la idea de probar un poco de aguardiente casero se volvió más tentadora.

Le pregunté qué había llevado a la zona a un estado tan desolador.

—¿Ves? Cayó un meteorito en la propiedad del viejo Whateley, allá —dijo señalando vagamente hacia donde yo había venido.

Me contó cómo algo se había filtrado en la tierra, envenenando el agua del pozo y luego los cuerpos y las mentes de los habitantes de la granja.

La esposa había sido internada en un psiquiátrico; el hijo andaba suelto, desnudo, por el bosque. Al viejo Whateley lo encontraron vagando por la casa vacía, balbuceando en una lengua extranjera. Como el veneno también le oscureció la piel, la policía lo confundió con un mexicano y lo envió a El Salvador.

—Está creciendo, esa cosa que dejó el meteorito, ¿ves? Se come los árboles, los insectos y las bestias.

Se estremeció.

—¡¿En serio?! —exclamé sin aliento.

—¡Qué va, hombre! Ustedes, los de la ciudad, se creen cualquier chorrada. Hay un vertedero de basura electrónica río arriba. Hace unos años, cuando Windows 11 dejó de funcionar en los ordenadores, tiraron allí cincuenta mil ordenadores viejos. Los arrasaron con excavadoras y todo para que nadie pudiera llevárselos a casa. Cadmio, ¿ves? Esa porquería está en el río, en el aire, por todas partes, y bueno… —Señaló el páramo y se encogió de hombros.

—Aun así —dijo, mientras me rellenaba el vaso—, podría haber sido peor.

—¿Por qué?

—En el pueblo de al lado van a montar un centro de datos de Meta AI —se rió entre dientes—. Estamos jodidos durante una generación, pero esos cabrones están jodidos para siempre.

Me abstuve de decirle que Windows 13 saldría ese mismo año.

KDE combate la contaminación tecnológica con su proyecto KDE Eco. No solo reducen la huella de carbono del software, sino que también se aseguran de que todo su software funcione en ordenadores de baja potencia y supuestamente obsoletos.

Si te han hecho creer que necesitas un dispositivo nuevo porque una actualización de algún software privativo indeseable impedirá que funcione en el tuyo, piénsalo dos veces. Consulta la campaña End of 10 y descubre cómo tú también puedes combatir la obsolescencia programada.

Dona a KDE y ayuda a una comunidad global a seguir luchando por el medio ambiente… ¡y por tu bolsillo!

Estas historias «teatralizadas» sirven como ejemplos reales de cómo el software privativo (aquel que te restringe tu libertad como usuario de utilizarlo como prefieras) es no solo una cortapisa tecnológica, si no también una manera de hacerte dependiente de sus decisiones comerciales.

Con el software libre, tienes libertad. Y la comunidad de KDE crea un montón de software libre para darte la libertad que mereces. Empezar a utilizar KDE es descubrir un mundo nuevo de aplicaciones útiles y variadas que hacen que puedas utilizar tus equipos con libertad.

Pero para realizar toda esa labor, la comunidad de KDE necesita dinero para sufragar todos los gastos. El software que realizan es libre y gratuito, pero requiere un montón de infraestructura y manos de obra que no lo son.

La meta de donaciones era de 50K, y en dos semans ya ha sido sobrepasada y se acerca al ambiciosa meta de 75K.

¿Ya has donado a la comunidad que crea tu entorno de escritorio favorito? No lo pienses más y colabora con la cantidad que desees, y haz que estas historias de miedo se conviertan solo en ficción… aunque hay muchas otras amenazas ahí fuera…

• https://kde.org/es/fundraisers/yearend2025/

Un proyecto comunitario pretende exportar funcionalidades de YaST que faltan en la nueva herramienta Cockpit, ya que SUSE y openSUSE 16.0 han «jubilado» a la gran herramienta de configuración de sistema YaST

El pasado 1 de octubre de 2025 se publicó openSUSE Leap 16.0. Una nueva versión de esta distribución de GNU/Linux que trajo varios cambios significativos e importantes. Entre ellos, el nuevo instalador Agama y la nueva herramienta web de configuración del sistema que utiliza Cockpit como sustituto del veterano YaST.

Cockpit se introdujo en Leap 16.0 como parte de un cambio más amplio hacia una infraestructura moderna y amigable con la automatización.

Todos los cambios son disruptivos y a veces traumáticos. Y eso de no tener a YaST a la hora de realizar gestiones en nuestro openSUSE Leap puede ser una razón que tire hacia atrás a los usuarios.

Y más cuando la nueva herramienta todavía adolece de algunas funcionalidades básicas que en YaST era algo común y sencillo, pero que todavía no se han exportado a la nueva herramienta Cockpit. Se evaluó cuales eran los módulos de YaST más populares y usados o más necesarios y se fue trabajando en ellos, para priorizar esfuerzos y recursos.

Pero hay muchas lagunas que todavía no se han llenado. Y eso es lo que pretende solucionar un proyecto presentado en la Hack Week 25. Ese proyecto tiene como objetivo abordar los comentarios de la comunidad al incorporar funciones de configuración populares de YaST a Cockpit y System Roles, lo que es un paso para cerrar la brecha dejada por la obsolescencia de YaST en openSUSE Leap 16.0.

Esperemos que ponto vayan llenándose los huecos dejados por la retirada de YaST y se vaya también puliendo los ya existentes. Si te interesa participar con un grupo de desarrolladores y aprender y aportar te podrás unir a este proyecto de Hack Week.

Hack Week es una iniciativa llevada a cabo por SUSE, en la que en una fase inicial los desarrolladores y trabajadores de SUSE aportan sus ideas de diferentes proyectos. Quien quiera se puede unir a los proyectos que le parezcan más interesantes, y durante una semana los desarrolladores aparcan su trabajo habitual para dedicarse al proyecto que han presentado o al que se han unido. Pasada esa semana se puede seguir trabajando en el proyecto personal hasta finalizarlo.

Esta iniciativa de SUSE se viene llevando a cabo desde 2007 y de ella han salido proyectos muy importantes hasta después tener entidad propia y convertirse en proyectos comunitarios muy importantes.

Por poner un ejemplo, de pasadas ediciones de esta Hack Week han salido proyectos como: openQA, Weblate, Aeon, o NextCloud.

A ver si con esta iniciativa se puede dar un empujón a Cockpit para que cada vez sea más completo e incluya más funcionalidades de YaST.

Enlaces de interés

• https://news.opensuse.org/2025/10/29/hw-project-aims-to-bridge-yast-cockpit-gaps/
• https://hackweek.opensuse.org/25/projects/bring-to-cockpit-plus-system-roles-capabilities-from-yast

La entrada Hoy no tengo ganas de escribir se publicó primero en KDE Blog.

A project during Hack Week 25 aims to address community feedback by bringing popular configuration features from YaST into Cockpit and System Roles, which is a step toward bridging the gap left by YaST’s deprecation in openSUSE Leap 16.0.

The initiative, titled Bring to Cockpit + System Roles capabilities from YAST, responds directly to some users anxiety about the loss of the familiar desktop and system management tools. Cockpit was introduced in Leap 16.0 as part of a broader shift toward modern, automation-friendly infrastructure.

Many long-time users have rightly pointed out that critical YaST functionality remains missing, but the next chapter of Leap requires a modern successor to YaST without reinventing the wheel alone; these advancements can grow stronger when shared and improved across communities.

The efforts for the Hack Week project, are set to begin Dec. 1. People can continue to work on the list of implementations should they choose to advance the features.

Several configuration and installation capabilities that were available in the deprecated YaST, which has long been one of the project’s hallmark tools, have yet to make it into the new Cockpit release. Significant research and careful consideration went into the transition away from YaST. Despite its deep ties to the project’s brand identity, teams thoroughly evaluated which features and modules were essential. These gaps for Cockpit are still being filled through community contributions and ongoing integration with System Roles.

The project’s goal is to implement service configuration in System Roles and then layer a Cockpit interface on top to give administrators direct control. In cases where an existing resource is already configured, specific Cockpit modules to handle the interaction are expected.

Should people choose to assist in the efforts, a spreadsheet detailing the missing features and suggested implementations has been published for contributors. Contributors can track progress and collaborate via the project’s Hack Week page.

Hack Week, which began in 2007, has become a cornerstone of the project’s open-source culture. Hack Week has produced tools that are now integral to the openSUSE ecosystem, such as openQA, Weblate and Aeon Desktop. Hack Week has also seeded projects that later grew into widely used products; the origins of ownCloud and its fork Nextcloud derive from a Hack Week project started more than a decade ago.

For more information, visit hackweek.opensuse.org.

Me alegra compartir con todos vosotros la primera actualización de Plasma 6.5, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Primera actualización de Plasma 6.5

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 28 de octubre de 2025, una semana después de liberar el código de Plasma 6.5 la Comunidad KDE presenta la primera actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.5

Aprovecho para realizar un listado de las novedades generales de Plasma 6.5:

• Cambio automático entre tema claro y oscuro
• Paneles desplazables para widgets y accesos
• Nuevo asistente de configuración inicial (KISS)
• Almacenamiento global de contraseñas Wi-Fi
• Mejoras de rendimiento en KWin al reproducir vídeo
• Configuración de diales en tabletas de dibujo
• Mejoras en la gestión de colores para monitores HDR
• Uso de la tecla Enter en las acciones de apagado del menú Kickoff
• Filtro de accesibilidad para escala de grises
• Ajustes visuales con bordes redondeados en menús

Más información: KDE

La entrada Primera actualización de Plasma 6.5 se publicó primero en KDE Blog.

The M8 has extensive USB audio and MIDI capabilities, but it cannot be a USB MIDI host. So you can control other devices through USB MIDI, but cannot sent to it over USB.

Control Surface & Pots for M8

Controlling things via USB devices has to be done through the old TRS (A) jacks. There’s two devices that can aid in that. I’ve used the RK06 which is very featureful, but in a very clumsy plastic case and USB micro cable that has a splitter for the HOST part and USB Power in. It also sometimes doesn’t reset properly when having multiple USB devices attached through a hub. The last bit is why I even bother with this setup.

The Dirtywave M8 has amazing support for the Novation Launchpad Pro MK3. Majority of peolpe hook it up directly to the M8 using the TRS MIDI cables. The Launchpad lacks any sort of pots or encoders though. Thus the need to fuss with USB dongles. What you need is to use the Launchpad Pro as a USB controller and shun at the reliable MIDI connection. The RK06 allows to combine multiple USB devices attached through an unpowered USB hub. Because I am flabbergasted how I did things here’s a schema that works.

If it doesn’t work, unplug the RK06 and turn LPPro off and on in the M8. I hate this setup but it is the only compact one that works (after some fiddling that you absolutely hate when doing a gig).

Intech Knot

The Hungarians behind the Grid USB controlles (with first class Linux support) have a USB>MIDI device called Knot. It has one great feature of a switch between TRS A/B for the non-standard devices.

It is way less fiddly than the RK06, uses nice aluminium housing and is sturdier. Hoewer it doesn’t seem to work with the Launchpad Pro via USB and it seems to be completely confused by a USB hub, so it’s not useful for my use case of multiple USB controllers.

Non-compact but Reliable

Novation came out with the Launch Control XL, which sadly replaced pots in the old one with encoders (absolute vs relative movement), but added midi in/ou/through with a MIDI mixer even. That way you can avoid USB altogether and get a reliable setup with control surfaces and encoders and sliders.

One day someone comes up with a compact midi capable pots to play along with Launchpad Pro ;) This post has been brought to you by an old man who forgets things.

Lynis es una herramienta de software libre con la que podrás auditar la seguridad de tu sistema GNU/Linux y otras derivadas de Unix como FreeBSD, Solaris o MacOS.

Hoy hechando un vistazo a mis feeds, me he encontrado con un artículo en inglés de SUSE, donde nos dan una serie de recomendaciones y guías para securizar nuestro sistema GNU/Linux.

El fortalecimiento de Linux es el proceso de reducir las vulnerabilidades, fortalecer las configuraciones y asegurarse de cumplir con los estándares de seguridad en los sistemas Linux. Con miles de organizaciones que confían en las soluciones empresariales de Linux para cargas de trabajo críticas, el uso de prácticas sólidas de fortalecimiento se ha vuelto esencial para protegerse contra las amenazas cibernéticas y mantener el cumplimiento normativo.

Está escrito por SUSE, pero se pueden extrapolar sus recomendaciones a cualquier sistema GNU/Linux:

• https://www.suse.com/c/linux-hardeningthe-complete-guide-to-securing-your-systems/

En dicho artículo además del conjunto de recomendaciones para fortalecer nuestro sistema GNU/Linux hablan sobre una herramienta que me ha llamado la atención llamada Lynis: Lynis – Herramienta de auditoría y endurecimiento de seguridad, para sistemas basados en UNIX.

Lynis es una herramienta publicada bajo licencia GPL v3.0, por lo que es software libre y además gratuito, ya que puedes descargarla y utilizarla. Primero veamos cómo se definen en su repositorio de GitHub:

Lynis es una herramienta de auditoría de seguridad para sistemas basados en UNIX como Linux, macOS, BSD y otros. Realiza un análisis de seguridad en profundidad y se ejecuta en el propio sistema. El objetivo principal es probar las defensas de seguridad y proporcionar consejos para un mayor fortalecimiento del sistema. También buscará información general del sistema, paquetes de software vulnerables y posibles problemas de configuración.

Lynis fue utilizado comúnmente por administradores de sistemas y auditores para evaluar las defensas de seguridad de sus sistemas. Además del «equipo azul», hoy en día los probadores de penetración también tienen a Lynis en su caja de herramientas.

La herramienta está orientada a personal técnico como: Administradores de sistemas, Auditores Oficiales de seguridad, Probadores de penetración de sistemas, Profesionales de la seguridad, etc.

Digamos que es una herramienta profesional pero que podemos utilizarla en nuestro sistema GNU/Linux como guía, pero teniendo en cuenta que hay que tener conocimientos profundos del sistema y valorar si realmente nuestro sistema GNU/Linux merece llevar a cabo las sugerencias en cuanto a seguridad que nos ofrece la herramienta Lynis.

En GNU/Linux somos de naturaleza curiosa y nos gusta ver cosas nuevas, así que «¿¿a quien no le va a gustar ejecutar esta herramienta de seguridad???» (punto para ti si reconoces el vídeo parafraseado).

En mi caso la quise probar pero sin instalar nada. Lynis está en los repositorios de openSUSE y de muchas otras distribuciones, así que desde tu gestor de software favorito la puedes buscar e instalar.

En mi caso, como era algo meramente informativo y puntual no quise instalarlo, así que me descargué el archivo comprimido y después lo descomprimí. A día de hoy la versión actual es 3.6.1:

wget https://cisofy.com/files/lynis-3.1.6.tar.gz     
tar -zxvf lynis-3.1.6.tar.gz

Nos descomprime todo en un archivo lynis, entramos en él y ejecutamos la auditoría que queramos.

En mi caso quería algo rápido para ver qué aspecto tiene la herramienta y qué resultados me ofrecía. Así que ejecuté un:

 sudo ./lynis audit system --quick 

Después de introducir la contraseña y de aceptar con ENTER la advertencia que nos hace la herramiente Lynis, comienza el escaneado rápido de nuestro sistema GNU/Linux. Y en él nos va mostrando diferentes mensajes.

Aquí es donde digo que hay que tener un conocimiento profundo del sistema. Nos saldrán varias advertencias, lo que nos puede llevar a tratar de corregirlas sin saber cómo y podremos romper el sistema si actuamos a lo loco.

Más adelante, la propia herramienta Lynis nos ofrece una serie de sugerencias para aumentar la seguridad de distintas partes del sistema. Aquí dejo a tu consideración si realmente merece la pena llevar a cabo las recomendaciones.

También al final del escaneo realizado nos mostrará un par de rutas donde guarda los registros o logs obtenidos, para una revisión más detallada o para enviarlo a un profesional, etc…

Lynis puede ser una buena herramienta si estás estudiando sobre estos temas o si ya trabajas con temas relacionados con la administración se sistemas o seguridad y quieres repasar si tus sistemas tienen puntos débiles que haya que solucionar o mejorar.

Tiene muy buena documentación y al ser software libre, tiene disponibles complementos que pueden expandir sus posibilidades. ¿Te animas a probarlo?

Enlaces de interés

• https://www.suse.com/c/linux-hardeningthe-complete-guide-to-securing-your-systems/
• https://cisofy.com/
• https://cisofy.com/documentation/lynis/get-started/
• https://github.com/CISOfy/Lynis