Barrapunto

El problema no es del todo de Tossati. Lo de sacar versiones 2.4.22.1, etc.. se ha discutido muchas veces en linux-kernel, pero nadie llega a un acuerdo.

Por tanto, la responsabilidad sí es en cierta parte de Debian al no parchear sus kernels, y en cierta parte de los desarrolladores del núcleo al no marcar este fallo de seguridad.

Por cierto, estoy de acuerdo en que Marcelo no lo ha hecho del todo bien, pero también hay que agradecerle su dedicación.

Los parches SIEMPRE han estado disponibles y las distribuciones SIEMPRE actualizan cuando hay un fallo de seguridad. Cuando estaba el ptrace, había parche. Los bugs de seguridad del 2.6 están ahi por que no son criticos. Ya han sido portados al 2.6, simplemente estan esperando para entrar.

1º El señor tossati no quiere meter libata porque es inteligente, y sabe que 1) libata tiene muy pocos meses desde que salio 2) probablemente ha leido los "asuntillos" sobre corrupciones de fichero con libata en la lista. ¿Quieres soporte de SATA 100% estable para linux? Pues bien, NO LO HAY.

2º: Tossati no fue quien metio JFS en el 2.4, fue Linus Torvalds. Las razones por las que no se incluyeron en su dia fueron bastante claras: un sistema de archivos que modificaba todo el kernel para adaptarlo a las necesidades de xfs. En sus dias, el parche de xfs dependia de rmap (vm que fue reemplazada y que ya no estaba en el 2.4).
Las razones que da ahora son bastante comprensibles: el parche de XFS toca código de *otros* sistemas de ficheros, y el que durante mucho tiempo nadie haya tenido problemas no significa que no los vaya haber (para empezar, la mayoria de la gente solamente usa un sistema de ficheros, asi que a ver cuanta gente ha probado el efecto de los parches de XFS en otros sistemas de archivos). Aun asi, en la lista lo acaba de dejar en manos de Christopher Hellwigh, (ex-hacker de SGI y conocedor del codigo que toca xfs), y será el quien decida finalmente si lo incluye o no. A saber si con esos parches podriamos tener problemas algunos usuarios de otros sistemas de archivos y tener corrupciones.... si SGI hubiera hecho las cosas bien en su dia no tendriamos esta situacion.

En resumen, Marcelo Tossati es un *buen* mantenedor. Quien diga lo contrario es que obviamente no recuerda lo pésimo que era Linus manteniendo ramas estables (palabras textuales del mismo Linus refiriendose a si mismo), y de las 3 veces que ha habido corrupcion de sistemas de ficheros en la serie *estable*, y del cambio de VM que hizo al 2.4 inusable durante meses (*años* en el caso de maquinas con varios gigas de ram), y del que incluso en el 2.4.23 ha habido cambios referentes a aquel error.

Si a ti te gusta juguetear con tu Pee Cee, alla tú, pero el "señor marcelo" (que tendra tu edad, o poco mas) tiene razones de sobra para no ir metiendo cositas "guais" porque a cuatro geeks quieran. La estabilidad no se consigue con esos métodos.

El problema es de un tal Marcelo Tossati al que la responsabilidad de mantener el 2.4 le está viniendo demasiado grande y para intentar dar una imagen de estabilidad en las sucesivas versiones del 2.4 se está tirando siglos en sacar cada revisión pudiendo y debiendo hacerlo INMEDIATAMENTE en casos como éste.

Una opinión como otra cualquiera, que no comparto del todo. La idea es que el usuario que debería complicarse compilando el núcleo y sabiendo a lo que se expone por jugar con la pieza más básica de software en su máquina NO espera a una versión final para corregir los problemas potenciales de seguridad de los que pueda tener constancia.

Es decir, si yo estoy TAN concienciado de los problemas de seguridad y se anuncia que en 2.4.23-pre7 se corrige un fallo potencial, no me espero ni dos meses ni dos días para bajarme el "patch", aplicarlo y recompilar, o mirar el "changeset" (en el propio diff o en el repositorio con interfaz web de 2.4.x [bkbits.net] correspondiente.

Si no estoy tan concienciado pero llevo a cabo prácticas sanas entonces comprobaré a diario (si es que no me notifican por correo) las listas de actualizaciones del fabricante para aplicarlas raudo y veloz. Así que en este caso la responsabilidad tampoco es del amigo Tosatti.

El mismo Tosatti que en pos de garantizar la estabilidad del código rechaza los parches de libata

Es decir, que como el "niño" quiere soporte "alpha" para SerialATA en el núcleo estándar está dispuesto a dejar que la gente corrompa alegremente sus sistemas de ficheros por trasladar la responsabilidad desde las personas encargadas de hacer que funcionen las cosas a la persona encargada de exigir que funcionen.

y que si es invulnerable a éste es porque Andrew Morton es quien mantendrá el código y se ha preocupado de parchear el bug que él mismo descubrió

Sinceramente, esta parte no la termino de entender.

El mismo Tosatti que incluye JFS en el kernel y se niega a incluir XFS, proyecto tan maduro como el propio 2.4 y muy estabilizado.

Es que muchas veces no todo depende de que haya algo por ahí que se diga que es la crema de bueno, los desarrolladores del mismo tienen que demostrar que saben "comportarse" en el grupo de desarrollo en que consiste todo esto. El caso concreto de XFS no lo he seguido, y no sé si la causa de su no inclusión será la inexistencia de parches independientes que revisar e incluir uno por uno, y no un par de parches de a MiB cada uno imposibles de analizar salvo para un par de ingenieros de SGI.

pero a algunos aun nos quedan unos meses más de sufrimiento en nuestros servidores

¿ En qué consiste exactamente tu penitencia con los servidores y núcleo 2.4.x ?. Lo digo porque es condición imprescindible para arreglar un problema que alguien motivado y cualificado sea consciente de él.