Noticias

May 30, 2023

AlmaLinux descubre que trabajar con Red Hat no es fácil

Cuando Red Hat anunció que el código fuente de Red Hat Enterprise Linux (RHEL) ya no estaría fácilmente disponible, transformó la forma en que los clones de RHEL como AlmaLinux, Oracle Linux y Rocky Linux crean

Cuando Red Hat anunció que el código fuente de Red Hat Enterprise Linux (RHEL) ya no estaría fácilmente disponible, transformó la forma en que los clones de RHEL como AlmaLinux, Oracle Linux y Rocky Linux crean sus distribuciones. Mientras Oracle y Rocky planean pelear, AlmaLinux optó por un rumbo más pacífico. Eso no ha funcionado tan bien como esperaba.

AlmaLinux ha dejado de intentar que el código fuente sea 100% compatible con RHEL. En cambio, los desarrolladores del sistema operativo AlmaLinux decidieron que fuera compatible con la interfaz binaria de aplicaciones (ABI). Para casi todos los fines de uso práctico, eso es más que suficiente.

También:Elive 3.8.34: Una belleza que a cualquier usuario de Linux de la vieja escuela le encantaría

Por lo tanto, la Junta de AlmaLinux votó unánimemente para "seguir apuntando a producir una distribución de Linux a largo plazo y de nivel empresarial que esté alineada y sea compatible con ABI con RHEL en respuesta a las necesidades de nuestra comunidad, en la medida de lo posible, como ese software que se ejecuta en RHEL se ejecutará igual en AlmaLinux".

Como explicó el presidente de AlmaLinux, Benny Vásquez, el objetivo preciso es "la compatibilidad ABI [que] en nuestro caso significa trabajar para garantizar que las aplicaciones creadas para ejecutarse en RHEL (o clones de RHEL) puedan ejecutarse sin problemas en AlmaLinux. Ajustarnos a esta expectativa elimina nuestra necesidad para garantizar que todo lo que publiquemos sea una copia exacta del código fuente que obtendría con RHEL".

Para ello, AlmaLinux utilizará el código fuente de CentOS Stream. A cambio, Vásquez agregó: "Continuaremos contribuyendo en Fedora y CentOS Stream y al ecosistema Enterprise Linux en general, tal como lo hemos estado haciendo desde nuestros inicios, ¡e invitamos a nuestra comunidad a hacer lo mismo!"

También:Linux Mint 21.2: Su nuevo y mejorado escritorio Linux para los próximos tres años

Oficialmente, Red Hat no tenía nada que decir. Pero los Red Hatters me dijeron que este es exactamente "el enfoque que sugerimos que adopten las distribuciones similares a RHEL: trabajar con la comunidad más amplia en CentOS Stream".

¿Entonces, cuál es el problema? Bueno, Jonathan Wright, director de tecnología de KnownHost y líder del equipo de infraestructura de AlmaLinux, publicó recientemente una solución de CentOS Stream para CVE-2023-38403, un problema de desbordamiento de memoria en iperf3. Iperf3 es una popular prueba de rendimiento de red de código abierto. Este agujero de seguridad es importante, pero no un gran problema. Aún así, es mucho mejor solucionarlo que dejarlo persistir y ver que eventualmente se utiliza para bloquear un servidor.

Eso es lo que yo y otros sentimos de todos modos. Pero luego, un ingeniero de software senior de Red Hat respondió: "Gracias por la contribución. En este momento, no planeamos abordar esto en RHEL, pero lo mantendremos abierto para evaluación según los comentarios de los clientes".

Eso cayó como un globo de plomo.

También:Las mejores computadoras portátiles con Linux

La conversación de GitLab prosiguió:

AlmaLinux: "¿Es realmente necesaria la demanda de los clientes para arreglar los CVE?"

Red Hat: "Nos comprometemos a abordar los problemas de seguridad críticos e importantes definidos por Red Hat. Las vulnerabilidades de seguridad con gravedad baja o moderada se abordarán a pedido cuando existan requisitos de cliente u otros negocios para hacerlo".

AlmaLinux: "Puedo incluso entender eso, pero ¿por qué rechazar la solución cuando el trabajo ya está hecho y sólo hay que fusionarlo?"

En este punto, intervino Mike McGrath, vicepresidente de plataformas principales de Red Hat, también conocido como RHEL. Explicó: "Probablemente deberíamos crear un documento sobre 'qué esperar cuando envíes'. Escribir el código es sólo el primer paso. en lo que Red Hat hace con él. Tendríamos que asegurarnos de que no haya regresiones, control de calidad, etc.... Así que gracias por la contribución, parece que el lado de Fedora va bien, así que terminará en RHEL en algún momento".

A partir de ahí, las cosas fueron cuesta abajo rápidamente.

También: ¿Linux tiene más del 3% del mercado de escritorio? Es más complicado que eso

Un usuario escribió: "¿Quiere la demanda de los clientes? Aquí está la demanda de los clientes. ARREGLARLO, o NUNCA tocaré RHEL NUNCA". Mientras que otro, gruñó: "Red Hat: ¡Nos volveremos totalmente comerciales porque Alma nunca impulsa las correcciones hacia arriba! Además, Red Hat: ¡No queremos tus correcciones, Alma!"

En Reddit, McGrath dijo: "Admito que aquí tuvimos una gran oportunidad para hacer un gesto de buena fe hacia Alma y fallamos".

Finalmente, aunque el equipo de Red Hat Product Security calificó el CVE como "'Importante', el parche se fusionó.

Entonces, el problema inmediato ha sido solucionado. Aún así, los malos sentimientos han quedado atrás. Como escribió Wright: "La peor parte de esto para mí es sentir que perdí el tiempo incluso al enviar una PR [solicitud de extracción] aquí". Esa es la última reacción que desea de los desarrolladores en una comunidad de código abierto.

Sin embargo, de cara al futuro, Vásquez es optimista. En una entrevista, dijo: "Este es un territorio inexplorado para todos nosotros y parecen estar dispuestos a mejorar las cosas. Si volvemos a nuestro verdadero objetivo (mejorar el ecosistema para todos), esta interacción es una oportunidad de aprendizaje. para todos. Ya tienen procesos y prácticas para aceptar cosas de los SIG [Grupos de interés especial de CentOS Stream], pero espero que mejoren en la aceptación de RP fuera de los SIG".

Ya veremos.