Cómo (y por qué) un miembro del equipo TuxCare contribuye al software de código abierto
En algunos de nuestros artículos anteriores hemos tratado la estrecha relación entre el software de código abierto -que es esencialmente libre- y las organizaciones comerciales que dependen de él.
Uno de los puntos que tocamos es que es habitual que empleados pagados por organizaciones comerciales contribuyan a proyectos de código abierto, sin que su empresa reciba un beneficio económico directo de este trabajo.
Detrás de esta generosidad hay una serie de motivaciones. A veces, una organización con fines comerciales simplemente necesita añadir funciones a un proyecto de código abierto por interés propio. Sin embargo, a menudo se trata de la relación simbiótica entre los usuarios de software de código abierto y la comunidad de código abierto.
Para este artículo, hemos hablado con uno de los desarrolladores del equipo TuxCare, Dmitry Antipov, para averiguar cómo contribuye el equipo TuxCare al código abierto. Sigue leyendo para ver cómo Dmitry trabaja con software de código abierto en su trabajo diario en TuxCare, y cuáles son las motivaciones que hay detrás de las contribuciones de TuxCare y Dmitri al software de código abierto.
Señalar un problema clave en RPM
Dmitry empezó a trabajar como ingeniero de software en 1998, sobre todo en proyectos relacionados con Linux, como el núcleo Linux y otras tareas generales de desarrollo de sistemas. Gran parte de esta experiencia la adquirió en el entorno empresarial. En la actualidad, Dmitry trabaja con el equipo de Soporte de Ciclo de Vida Extendido (ELS) en TuxCare, pero también contribuye a una serie de proyectos de código abierto durante su trabajo diario en TuxCare.
A veces este trabajo surge de una necesidad observada. Tomemos el caso de los paquetes RPM. Un miembro de la comunidad observó que, en el caso de los paquetes RPM, las subclaves revocadas no se verifican cuando se comprueba si un paquete tiene una firma válida. Así, aunque una subclave haya sido revocada, seguirá siendo aceptada.
Esto llevó a Dmitry a investigar la cuestión, que era un problema bastante crítico, dado que durante muchos años los usuarios de distribuciones Linux basadas en RPM podían haber estado instalando paquetes en los que las firmas no estaban correctamente validadas.
Suerte - por ahora
Aunque tanto RPM como libdnf comprueban si una clave es válida y no ha caducado, ninguno de los dos comprueba la revocación. Afortunadamente, ninguna de las distribuciones de RPM ha sufrido un ataque basado en este fallo.
Según Dmitri, ha sido una suerte esencialmente que no haya sido necesario revocar las claves, como ocurrió con el hackeo de la autoridad de certificación de Norton. Y, en consecuencia, que las claves utilizadas para firmar paquetes RPM se hayan almacenado correctamente, y nunca se hayan revocado.
Dmitri dice que parte del problema es que los proyectos de gestión de paquetes se centran más en la gestión de paquetes que en la criptografía. Esto es de esperar, y no hay mucha necesidad de que RPM establezca sus propias bibliotecas criptográficas. No obstante, Dmitri señaló el problema y, a su debido tiempo, el equipo responsable de la gestión de paquetes RPM lo abordará, aunque es una incógnita cuándo ocurrirá.
Contribución a GlusterFS
Uno de los aspectos más poderosos de la comunidad de código abierto es cómo sigue respondiendo a las necesidades tecnológicas más actuales con proyectos de vanguardia impulsados por la comunidad.
GlusterFS es uno de estos proyectos. Para satisfacer las necesidades de los entornos de servidores distribuidos de escala constante, un equipo de usuarios comenzó a construir un sistema de archivos distribuido que puede escalarse de forma arbitraria.
El sistema de archivos puede manejar varios petabytes de almacenamiento a través de cientos de notas y es una solución popular para el almacenamiento backend en entornos virtuales distribuidos. Sin embargo, como todos los demás proyectos de código abierto, GlusterFS necesita la aportación continua de la comunidad. Después de todo, tiene más de una década.
Hablando con Dmitri, rápidamente se vio que está contribuyendo a GlusterFS de una manera importante. Durante algún tiempo, Dmitri ha trabajado en las capas inferiores del sistema GlusterFS, donde la lógica del sistema de alto nivel se encuentra con el sistema operativo. Esto incluye trabajar en archivos, sockets, hilos, sincronización, etc. Más recientemente, ha solucionado algunos problemas relacionados con el uso de mutexes no inicializados que, aunque es algo que una herramienta como valgrind puede detectar fácilmente, todavía se encuentran en el código base. También ha corregido código relacionado con la finalización de hilos, en el que algunos hilos que salían no liberaban correctamente el espacio de la pila, lo que provocaba fugas de memoria.
Solucionar el creciente problema de los mutexes
Nuestros lectores habituales habrán notado que recientemente hemos cubierto fallos de seguridad en una serie de vulnerabilidades, y que han surgido preocupaciones en torno al uso de mutexes y futexes, con varios CVEs señalando fallos en su uso.
De hecho, algunas de las contribuciones de Dmitry a GlusterFS giraron en torno a los mutexes - tratando de resolver problemas con fugas de recursos. Según Dmitry, cuando los mutexes ya no son necesarios, deben ser liberados - de lo contrario, se producirá una pequeña pero visible fuga de recursos. Si bien no es tan grave como una fuga de memoria, todavía existe la necesidad de prácticas de programación desinfectadas - y los recursos siempre deben ser limpiados después de su uso.
Trabajar en código abierto dentro de TuxCare
RPM y GlusterFS son sólo dos ejemplos de las contribuciones de Dmitri dentro de la comunidad de código abierto. El elemento interesante del trabajo de nuestro desarrollador es el hecho de que consume casi todo su tiempo en TuxCare.
En otras palabras, Dmitri se dedica sobre todo a contribuir a proyectos de código abierto, aunque trabaje en el equipo de apoyo al ciclo de vida ampliado (ELS). Preguntamos a Dmitri cómo encaja eso dentro de las prerrogativas de una organización comercial.
Según Dmitri, TuxCare pretende que se le considere un miembro valioso del movimiento de código abierto, y que el impulso para realizar contribuciones en proyectos de código abierto provenga de un nivel directivo. Al compartir el código creado para solucionar los problemas detectados en las distribuciones de Linux cubiertas por ELS con los proyectos upstream, esas correcciones estarán disponibles para todos, contribuyendo así a un entorno informático más seguro en general.
Dmitri dice que es probable que siga contribuyendo a proyectos de código abierto, añadiendo a una larga lista de contribuciones existentes que más allá de lo que ya hemos mencionado también incluye una sincronización del sistema de archivos basado en POSIX AIO y un mejor soporte para la ejecución de diferentes comprobadores Valgrind.
La historia de Dmitri a TuxCare pone de relieve cómo los proveedores comerciales colaboran estrechamente con los miembros de la comunidad de código abierto para contribuir a los proyectos de código abierto. Juntos, impulsamos el proyecto de código abierto y garantizamos que todas las organizaciones, ya sean gubernamentales, no gubernamentales o con ánimo de lucro, puedan seguir confiando en una base de código abierto capaz y segura.