por
pobrecito hablador
el Martes, 02 Diciembre de 2003, 16:59h
(#240660)
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.
Pero no, aún hace unos pocos días precisamente que por fin tenemos un 2.4 sin este bug, cuando el agujero lleva en el aire más de dos meses.
Lo mismo ocurrió con el bug del ptrace(), el señor Tosatti nos tuvo un montón de tiempo con una versión estable vulnerable a un exploit publicado y que se estaba haciendo demasiado famoso durante meses. Por cierto, el mismo exploit que sigue funcionando en 2.6.0-test11, pese a las repetidas insinuaciones de Alan Cox y otros en la LKML para arreglar esto desde hace tiempo, y que parece que ahora por fin alguien está pensando en incluirlas en la próxima release.
El mismo Tosatti que en pos de garantizar la estabilidad del código rechaza los parches de libata (que darían por fin _soporte_ decente a mi chip SATA) y me recomienda que me vaya al 2.6 para obtener soporte "pues ya parece bastante estable", un 2.6 que no puedo poner en producción y al que no le han aplicado los parches de seguridad de los 2.4 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ó.
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.
En fin, sólo cabe dar gracias por el nombramiento del señor Morton como maintainer del 2.6, pero a algunos aun nos quedan unos meses más de sufrimiento en nuestros servidores.
A ver si lees antes de escupir trolls...
Si Debian (ni nadie) había actualizado los kernels por el fallo del do_brk() es porque el fallo que se corrigió en 2.4.23pre no se sabía que podía llegar a tener tantas implicaciones de seguridad. Vamos, que se arregló como un bugfix normal y corriente.
Supongo que no pretenderás que Debian (o RH, o SuSE, o cualquiera) vaya cambiando de kernels aleatoriamente sólo por el hecho de que ha salido una versión nueva. Si no hay razones para hacerlo y el sistema funciona, no se cambia. Y hasta que se descubrió que ésta fue la causa, el kernel 2.4.22 no tenía problema.
El problema no es de Debian
(Puntos:3, Interesante)Pero no, aún hace unos pocos días precisamente que por fin tenemos un 2.4 sin este bug, cuando el agujero lleva en el aire más de dos meses.
Lo mismo ocurrió con el bug del ptrace(), el señor Tosatti nos tuvo un montón de tiempo con una versión estable vulnerable a un exploit publicado y que se estaba haciendo demasiado famoso durante meses. Por cierto, el mismo exploit que sigue funcionando en 2.6.0-test11, pese a las repetidas insinuaciones de Alan Cox y otros en la LKML para arreglar esto desde hace tiempo, y que parece que ahora por fin alguien está pensando en incluirlas en la próxima release.
El mismo Tosatti que en pos de garantizar la estabilidad del código rechaza los parches de libata (que darían por fin _soporte_ decente a mi chip SATA) y me recomienda que me vaya al 2.6 para obtener soporte "pues ya parece bastante estable", un 2.6 que no puedo poner en producción y al que no le han aplicado los parches de seguridad de los 2.4 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ó.
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.
En fin, sólo cabe dar gracias por el nombramiento del señor Morton como maintainer del 2.6, pero a algunos aun nos quedan unos meses más de sufrimiento en nuestros servidores.
Re:Lo que tiene tela es...
(Puntos:2)( http://www.debian.org/ )
Si Debian (ni nadie) había actualizado los kernels por el fallo del do_brk() es porque el fallo que se corrigió en 2.4.23pre no se sabía que podía llegar a tener tantas implicaciones de seguridad. Vamos, que se arregló como un bugfix normal y corriente.
Supongo que no pretenderás que Debian (o RH, o SuSE, o cualquiera) vaya cambiando de kernels aleatoriamente sólo por el hecho de que ha salido una versión nueva. Si no hay razones para hacerlo y el sistema funciona, no se cambia. Y hasta que se descubrió que ésta fue la causa, el kernel 2.4.22 no tenía problema.