Portada
mis comunidades
otras secciones
![Linux: bug crítico compromete cientos de aplicaciones [ENG]](https://cdn.mnmstatic.net/cache/20/7f/media_thumb_2x-link-2129869.jpeg?1417833704)
#8:
#2
Si teniendo el código a la vista un error puede pasar desapercibido durante 10 años imagínate si nadie puede ver el código, la de errores y puertas traseras que puede haber...
Por otro lado, linux es de mi propiedad así que es normal que lo defienda por malo que sea...
Como es normal que microsoft o apple defiendan su software cuando se descubren bugs y backdoors...
Lo que no es tan normal es lo de los fanboys
Si teniendo el código a la vista un error puede pasar desapercibido durante 10 años imagínate si nadie puede ver el código, la de errores y puertas traseras que puede haber...
Por otro lado, linux es de mi propiedad así que es normal que lo defienda por malo que sea...
Como es normal que microsoft o apple defiendan su software cuando se descubren bugs y backdoors...
Lo que no es tan normal es lo de los fanboys
#13:
¿Por qué en el titular pone Linux en mayúsculas? Según lo que dice la noticia, el bug no es de Linux, sino de una librería llamada GnuTLS, que está disponible para varios sistemas operativos, entre ellos ese.
#12:
Debian ya lo tiene corregido:
https://www.debian.org/security/2014/dsa-2869
https://www.debian.org/security/2014/dsa-2869
#29:
#24 El primer mensaje reportando el error en la lista de gnu-tls es del 11 feb. El 15-feb ya estaba el paquete debian en los repositorios con la corrección. Tres o cuatro días, dependiendo de horas y timezones. Es el tiempo de respuesta normal.
El servicio de atención al cliente de debian es inmejorable, nada que ver con otros. Cuando digo que la razón para usar linux es la calidad me refiero a cosas de estas.
Esta noticia el 4 de marzo ya es obsoleta. La gran mayoría de los ordenadores del mundo ya están actualizados.
El servicio de atención al cliente de debian es inmejorable, nada que ver con otros. Cuando digo que la razón para usar linux es la calidad me refiero a cosas de estas.
Esta noticia el 4 de marzo ya es obsoleta. La gran mayoría de los ordenadores del mundo ya están actualizados.
#10:
#2 No hombre. Lo irónico es que por los fallos del guindous te cobren. Los fallos del Linux los va descubriendo (y solucionando) la propia comunidad, pero no te quejes que es material abierto a disposición de cualquiera. Si lo usas es porque quieres y no has tenido que pagar por ello.
(Mira que mi madre me lo dice siempre: no des de comer al troll, no des de comer al troll...)
(Mira que mi madre me lo dice siempre: no des de comer al troll, no des de comer al troll...)
#20:
#2 El software de la GNU tiene una fama de calidad y seguridad de la que carece windows. Si estuvieras acostumbrado a ver los informes de bugs y el tiempo que se tarda en solucionarlos (si es que se solucionan), tendrías una perspectiva muy diferente.
#13 Cierto. El bug afecta a muchas aplicaciones de muchos sistemas operativos, también en windows.
cc/ #19
#13 Cierto. El bug afecta a muchas aplicaciones de muchos sistemas operativos, también en windows.
cc/ #19
#30:
En Slackware ya esta corregido:
patches/packages/gnutls-3.1.22-i486-1_slack14.1.txz: Upgraded.
Fixed a security issue where a specially crafted certificate could
bypass certificate validation checks.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0092
(* Security fix *)
patches/packages/gnutls-3.1.22-i486-1_slack14.1.txz: Upgraded.
Fixed a security issue where a specially crafted certificate could
bypass certificate validation checks.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0092
(* Security fix *)
#50:
#11 Tantos los virus Sasser como Blaster, fueron creados por ingeniería inversa de los parches de Microsoft que corregían las vulnerabilidades que explotaban.
Para Sasser, el parche salió 17 días antes de que observaran las primeras muestras (http://csc560.wikispaces.com/The+Sasser+Worm), para Blaster el virus salió el 11 de agosto para una vulnerabilidad que fue parcheada un 16 de julio (http://nsrg.eecs.umich.edu/publications/IEEE_Security_Privacy_Blaster_Final.pdf).
¿Por qué las máquinas infectadas no habían sido actualizadas?
Estoy con #42: la idea de que el software libre es más seguro por el mero hecho de que cualquiera puede leer el código roza el mito. Me recuerda al security by obscurity.
Y coincido con #8 en su última frase (aunque sólo en eso, me temo jeje). Si se ha de criticar algo al menos que sea aportando datos, no como un fanboy más. Eso no hace más que añadir ruido y estupidez a una conversación. Y empobrece a todas las partes.
Para Sasser, el parche salió 17 días antes de que observaran las primeras muestras (http://csc560.wikispaces.com/The+Sasser+Worm), para Blaster el virus salió el 11 de agosto para una vulnerabilidad que fue parcheada un 16 de julio (http://nsrg.eecs.umich.edu/publications/IEEE_Security_Privacy_Blaster_Final.pdf).
¿Por qué las máquinas infectadas no habían sido actualizadas?
Estoy con #42: la idea de que el software libre es más seguro por el mero hecho de que cualquiera puede leer el código roza el mito. Me recuerda al security by obscurity.
Y coincido con #8 en su última frase (aunque sólo en eso, me temo jeje). Si se ha de criticar algo al menos que sea aportando datos, no como un fanboy más. Eso no hace más que añadir ruido y estupidez a una conversación. Y empobrece a todas las partes.
#78:
#42
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
Lo que siempre se dice no es que nos da automáticamente seguridad. Lo que se dice es que nos da mucha más seguridad que un código cerrado.
De hecho, nunca escucharás a un programador experto asegurar que algo no tiene bugs. Y si lo hace, es que no es tan experto.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
Por eso hay partes que son muy delicadas y se está buscando continuamente gente que las entienda para que colabore.
Por eso hay empresas que invierten en software libre y son ellas mismas las que desarrollan y auditan el código, para estar seguras de que se hace bien.
Por eso hay modificaciones (que no parches urgentes) del kernel de Linux que tardan meses en salir adelante, porque quieren estar seguros.
Señalas un problema, pero no señalas que el software libre lo soluciona mejor que el software privativo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
Por eso está por ejemplo Debian, que te obliga a añadir "a mano" el software que no tiene licencia libre. Nadie está obligado a instalar este software, igual que nadie está obligado a abrir el ejecutable que te envía por email el rey de Nigeria para que le ayudes a mover el dinero a un paraíso fiscal.
¿Que el usuario medio no lo sabe y lo instala a ciegas? El usuario medio tampoco sabía la primera vez que el cartel del visitante un millón era mentira, ni tampoco sabía que la aplicación para ver quién ha visto tu perfil de facebook era una trampa para robarte los datos. Lo que falta es alfabetización digital, no puedes proteger a los usuarios de su propia estupidez.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
Claro que se puede auditar, igual que el software libre (que algunas librerías o partes del kernel han sido auditadas por empresas expertas). Pero sigue siendo menos seguro que un código libre que además cualquiera puede auditar.
¿Desensamblar sirve realmente de algo?
Te pongo el caso más diferenciador: si yo soy una empresa medianamente grande y quiero asegurar mi software, ¿realmente crees que Microsoft me dejará auditar el código de Windows? ¿O Apple el de iOS? Con GNU/Linux no tengo ni que pedir permiso.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
Pero esto es lo bueno del software libre: es muy meritocrático. Conforme vas adentrándote en el código más delicado de GNU/Linux, más difícil es que un desconocido pueda comitear sin que su código lo revisen cien ojos. Se sabe perfectamente qué partes ha hecho cada uno y se le pueden pedir cuentas por conductas sospechosas.
Alguien que haga código de mala calidad (como este), sea o no queriendo, tiene poco futuro de comiteador, si es que puede llegar a serlo alguna vez.
Alguien desconocido que haga código de mala calidad, sea o no queriendo, va a tener que pasar muchas revisiones antes de poder comitear.
¿Conclusión? Claro que puede haber problemas y fallos de seguridad. Pero la clave no es que no los haya, la clave es que son muchos menos y que cuando salen a la luz, se solucionan mucho más ŕapido.
Si el OS privativo tiene X medidas de aseguramiento de la calidad, el OS libre tiene esas X medidas y además tiene las medidas de aseguramiento de la calidad que sólo pueden darse en el software libre. Por pura lógica, el OS libre será más seguro que el OS privativo.
¿Quién en su sano juicio escogería un sistema operativo más inseguro y que tarde más en parchear los agujeros de seguridad para un proyecto empresarial serio?
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
Lo que siempre se dice no es que nos da automáticamente seguridad. Lo que se dice es que nos da mucha más seguridad que un código cerrado.
De hecho, nunca escucharás a un programador experto asegurar que algo no tiene bugs. Y si lo hace, es que no es tan experto.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
Por eso hay partes que son muy delicadas y se está buscando continuamente gente que las entienda para que colabore.
Por eso hay empresas que invierten en software libre y son ellas mismas las que desarrollan y auditan el código, para estar seguras de que se hace bien.
Por eso hay modificaciones (que no parches urgentes) del kernel de Linux que tardan meses en salir adelante, porque quieren estar seguros.
Señalas un problema, pero no señalas que el software libre lo soluciona mejor que el software privativo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
Por eso está por ejemplo Debian, que te obliga a añadir "a mano" el software que no tiene licencia libre. Nadie está obligado a instalar este software, igual que nadie está obligado a abrir el ejecutable que te envía por email el rey de Nigeria para que le ayudes a mover el dinero a un paraíso fiscal.
¿Que el usuario medio no lo sabe y lo instala a ciegas? El usuario medio tampoco sabía la primera vez que el cartel del visitante un millón era mentira, ni tampoco sabía que la aplicación para ver quién ha visto tu perfil de facebook era una trampa para robarte los datos. Lo que falta es alfabetización digital, no puedes proteger a los usuarios de su propia estupidez.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
Claro que se puede auditar, igual que el software libre (que algunas librerías o partes del kernel han sido auditadas por empresas expertas). Pero sigue siendo menos seguro que un código libre que además cualquiera puede auditar.
¿Desensamblar sirve realmente de algo?
Te pongo el caso más diferenciador: si yo soy una empresa medianamente grande y quiero asegurar mi software, ¿realmente crees que Microsoft me dejará auditar el código de Windows? ¿O Apple el de iOS? Con GNU/Linux no tengo ni que pedir permiso.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
Pero esto es lo bueno del software libre: es muy meritocrático. Conforme vas adentrándote en el código más delicado de GNU/Linux, más difícil es que un desconocido pueda comitear sin que su código lo revisen cien ojos. Se sabe perfectamente qué partes ha hecho cada uno y se le pueden pedir cuentas por conductas sospechosas.
Alguien que haga código de mala calidad (como este), sea o no queriendo, tiene poco futuro de comiteador, si es que puede llegar a serlo alguna vez.
Alguien desconocido que haga código de mala calidad, sea o no queriendo, va a tener que pasar muchas revisiones antes de poder comitear.
¿Conclusión? Claro que puede haber problemas y fallos de seguridad. Pero la clave no es que no los haya, la clave es que son muchos menos y que cuando salen a la luz, se solucionan mucho más ŕapido.
Si el OS privativo tiene X medidas de aseguramiento de la calidad, el OS libre tiene esas X medidas y además tiene las medidas de aseguramiento de la calidad que sólo pueden darse en el software libre. Por pura lógica, el OS libre será más seguro que el OS privativo.
¿Quién en su sano juicio escogería un sistema operativo más inseguro y que tarde más en parchear los agujeros de seguridad para un proyecto empresarial serio?
#42:
Varias cosas, que ya dije en otras noticias similares anteriormente:
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
#45:
#42 El disponer del codigo fuente es una gran ventaja. Primero porque puedes ver el funcionamiento e incluso modificarlo segun convenga (siempre que se tenga conocimientos). Al ser privativo es muchisimo mas complicado poder entender/modificar ese software (y no creo que se pueda modificar por ejemplo un kernel de un sistema cerrado porque seria algo tan complejo y podrian fallar tantas cosas ...).
Quien sabe si en un futuro no existiran herramientas automaticas basadas en redes neuronales o sistemas expertos que puedan buscar bugs en codigo fuente de programas de forma eficiente y rapida. Si no se dispone del codigo fuente no se podra realizar este tipo de cosas o sera mucho mas complicado.
De todas maneras yo voto por medidas de seguridad que sean capaces de proteger al sistema y los datos de posibles bugs o puertas traseras. Herramientas avanzadas a nivel kernel como SELinux, Pax/Grsecurity y cosas parecidas; junto con medidas de seguridad de red o entornos sandbox-virtuales, y otro tipo de medidas para evitar problemas de seguridad producidos por bugs (intencionados o no).
Quien sabe si en un futuro no existiran herramientas automaticas basadas en redes neuronales o sistemas expertos que puedan buscar bugs en codigo fuente de programas de forma eficiente y rapida. Si no se dispone del codigo fuente no se podra realizar este tipo de cosas o sera mucho mas complicado.
De todas maneras yo voto por medidas de seguridad que sean capaces de proteger al sistema y los datos de posibles bugs o puertas traseras. Herramientas avanzadas a nivel kernel como SELinux, Pax/Grsecurity y cosas parecidas; junto con medidas de seguridad de red o entornos sandbox-virtuales, y otro tipo de medidas para evitar problemas de seguridad producidos por bugs (intencionados o no).
Comentarios
Debian ya lo tiene corregido:
https://www.debian.org/security/2014/dsa-2869
#12 Por curiosidad ¿tiempo entre que han avisado y que se ha arreglado?
#24 El primer mensaje reportando el error en la lista de gnu-tls es del 11 feb. El 15-feb ya estaba el paquete debian en los repositorios con la corrección. Tres o cuatro días, dependiendo de horas y timezones. Es el tiempo de respuesta normal.
El servicio de atención al cliente de debian es inmejorable, nada que ver con otros. Cuando digo que la razón para usar linux es la calidad me refiero a cosas de estas.
Esta noticia el 4 de marzo ya es obsoleta. La gran mayoría de los ordenadores del mundo ya están actualizados.
#29 Ya estaba yo cagado haciendo apt-gets en los servidores y ahora te veo...
#29 Te estás confundiendo de bug, este es posterior y oficialmente se corrigió el día 3 de marzo.
#33
¡ Qué fallo ! Inintencionado total.
¡ Qué vergüenza ! Al menos votarme negativo, que se note que es un error.
#12, también Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-libs/gnutls/ChangeLog?view=markup
#12 Ubuntu también corregido http://lwn.net/Articles/589232/
¿Por qué en el titular pone Linux en mayúsculas? Según lo que dice la noticia, el bug no es de Linux, sino de una librería llamada GnuTLS, que está disponible para varios sistemas operativos, entre ellos ese.
#13 Porque esa librería es parte esencial del sistema operativo GNU/Linux.
#14 No es esencial.
#16 Pero sí es parte del sistema operativo. No te quejes de que digan que es de Linux, si utilizas Linux como palabra polisemica para referirte tanto al kernel como a toda distro libre con software libre con kernel Linux. Es confuso que la gente llame "Linux" a la distro entera, lo lleva siendo años.
#8 Linux no es exactamente "de tu propiedad." El código tiene derechos de autor (que no es lo mismo que propiedad), y pertenecen al autor. Las licencias libres te dan libertad, no autoría.
#92
Linux pertenece a todo el mundo, no es propiedad de los autores de cada pieza de código (aunque estos sean los propietarios de dicha pieza) porque cada pieza podría ser sustituida por otra sin que sucediese nada.
#100 #131 Linux no es una propiedad. Linux es un software y como todo software tiene derecho de autor, no es una propiedad.
El derecho de autor pertenece a los autores. No a la gente en general.
La licencia GPL concede libertad de uso y modificación, no de autoría.
Si no entendéis esos conceptos, no entenderéis si se puede o no cambiar la licencia de un software GPL y quien puede hacerlo. No entenderéis las CLA, ni tampoco porqué están rotas según Torvalds. No entenderéis porqué tenéis que respetar las licencias, y cuándo las tenéis legalmente que respetar.
#92 se refiere a que no es propiedad de una empresa. en ese sentido puede decir que es propiedad suya aunque no sea él su autor. Es totalmente diferente a por ejemplo los MacOSX que el ordenador ni siquiera es tuyo.
#14 La usan muchos programas que funcionan en Linux, pero también en otros sistemas operativos. No es algo exclusivo de éste.
#15 Bueno, yo no lo decía por las mayúsculas en sí, sino por "Linux"
#18 ¿Y? La denominación GNU/Linux es la denominación defendida por el Proyecto GNU y la FSF junto con otros desarrolladores y usuarios para el conjunto que utiliza el sistema operativo Linux en conjunto con las aplicaciones de sistema creadas por el proyecto GNU y por muchos otros proyectos de software.
http://es.wikipedia.org/wiki/GNU/Linux#Denominaci.C3.B3n_GNU.2FLinux
Vaya, que lo dice Richard Stallman en persona.
#2 El software de la GNU tiene una fama de calidad y seguridad de la que carece windows. Si estuvieras acostumbrado a ver los informes de bugs y el tiempo que se tarda en solucionarlos (si es que se solucionan), tendrías una perspectiva muy diferente.
#13 Cierto. El bug afecta a muchas aplicaciones de muchos sistemas operativos, también en windows.
cc/ #19
#20 El software de la GNU tiene una fama de calidad y seguridad de la que carece windows. Si estuvieras acostumbrado a ver los informes de bugs y el tiempo que se tarda en solucionarlos (si es que se solucionan), tendrías una perspectiva muy diferente.
Enlaces, please?
#54 No, no hay enlaces. Pasa por un foro de seguridad, estate un tiempo y verás como se palpa en el ambiente. de entrada nadie concibe que los bugs se mantengan en secreto. Ni tiempos de resolución de bugs críticos de más de varios meses. Y verás que el nivel que se sobreentiende que se exige al software libre "de referencia" (gnu, apache, eclipse, linux, red hat...) es muy superior al que se recibe por comprar una licencia de windows por ejemplo.
Pedir enlaces para esto sería como pedir un enlace en el que se explicase que en la universidad se ven cosas mas avanzadas que en el colegio de primaria.
#162 #54 En la cueva de menéame, hay un ejémplo, no hace falta ser un snowden.
Ubuntu corrige el bug crítico ("contraseña de root")
Ubuntu corrige el bug crítico ("contraseña de...
ubuntu.com#19 Repito, no es esencial. Puedes rular Debian GNU/Linux con OpenSSL en vez de GNUTLS.
O sin SSL siquiera. Y sigue siendo GNU Coreutils/userland + Linux.
#21 La denominación GNU/Linux es lo suficientemente abierta como para que un sistema o distribución considere esencial el uso de GNUTLS para el manejo de SSL.
Luego sí, es esencial. Lo que no quiere decir que sea una librería única, ni sin reemplazo, como tú muy bien apuntas.
#23 No. GNUTLS es prescindible, al igual que GNU Guile, GNU Freetalk o GNU EMACS, para ejecutar GNU/Linux.
O GNU wget. No forma parte del sistema básico. https://www.gnu.org/software/wget/
#25 Ya te digo: depende de si tu distribución va con esas librerías o no.
El otro día, sin ir más lejos, creé mi propia distribución: Montequintux. Y la construí eligiendo cuidadosamente una serie de librerías y aplicaciones, para que todo en ella fuese perfectamente integrado y funcionase a la perfección.
Y le metí el GNUTLS. Luego sí: esa librería es esencial para mi distribución GNU/Linux.
#26 Te equivocas. GNU/Linux no requiere de GNUTLS para funcionar. Puedes tener un arranque de kernel, glibc y Bash... sin requerir TLS.
Otra cosa son las aplicaciones que metas encima.
Si TLS es necesario para usar GNU/Linux borra Vim, ya que no es GPL ni GNU.
#26 No es esencial en Linux. Tengo un ordenador con ArchLinux con instalación basica y acabo de comprobar que no tengo instalado Gnutls, por lo que no es imprescindible o siempre instalado por defecto.
#36, también lo he comprobado. Lo tengo en Gentoo (ya actualizado a la versión corregida), pero no en Arch.
Y de todas las aplicaciones que tengo instaladas en Gentoo (que no son pocas), solo fcron utiliza gnutls.
#38 Por eso digo que no es un programa "basico" para linux (aunque si es necesario para muchos otros programas). Seguramente habra otras distros que tampoco lo tengan instalado por defecto. De todas formas pienso que los bugs en codigo son algo que siempre existira (aunque se vayan solucionando) y creo que para tener un sistema a prueba de bugs es necesario otras medidas mas sofisticadas (en Linux puede ayudar bastante Grsecurity, RSBAC, SELinux, etc...).
#19 No he dicho que no fuese esencial (que lo será en muchas distribuciones), sino que no era exclusivo.
#13 Modificado
#13 Porque el profano en informática identifica el mundo del software libre y del "Open Source" con Linux porque es el de mayor implantación y el que más fama tiene.
En Slackware ya esta corregido:
patches/packages/gnutls-3.1.22-i486-1_slack14.1.txz: Upgraded.
Fixed a security issue where a specially crafted certificate could
bypass certificate validation checks.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0092
(* Security fix *)
#30 Es que Slackware es mucho
Seguro que son los mismos que usan la memoria protegida... paranoicos!!
#35 Y en las Mint que tiran del los repositorios de Ubuntu, y en las Mint que tiran de los repositorios de Debian
#48 Bibliotecas compartidas?? Hablas en serio?? Hay sistemas operativos en los que las aplicaciones comparten las bibliotecas?? Y no se hacen un lío??
Por cierto, unas líneas de código que están "ahí" desde hace más de 9 años; no son necesariamente un bug de 9 años... porque es muy posible que hace 9 años ninguna aplicación podía explotar esas líneas que hoy si representan una vulnerabilidad.
The coding error, which may have been present in the code since 2005,
#2 No hombre, lo bueno de linux es que, como cualquiera puede ver el código, está continuamente auditado por cientos de ojos. Este bug seguramente se habrá introducido en la última versión y lo habrán corregido a los dos días de salir.
Espera... c/c #1
#6, como puedes ver en http://www.debian.org/security/2014/dsa-2869.
Date Reported: 03 Mar 2014
Corregido (Ultima edición de la página): Tue, Mar 4 23:34:40 UTC 2014
Va a ser que tienes razón. No tardan 2 días en corregirlo.
#7 goto #1
Tan solo le ha durado 9 años 
#39 Emmm... el error tiene 9 añazos, por si no lo has leído...
(véase #1)
#41 PWNED! (¡Auch..!)
Pero, ojo, que por norma general es así. En cuanto se detecta algo, se arregla con relativa rapidez
#115 El comentario decía "Lo bueno del software abierto y libre es que estas cosas se detectan rápidamente y del mismo modo, se tarda poco en solucionar."
Lo de que se solucionan rápido nadie lo cuestiona. Mi comentario iba por lo de que se detecta rápidamente (por lo que se sabe, el error llevaría unos 9 años. Y aunque llevase 1 año, no sería tan rápidamente...).
Al menos@Vermelnardo ha admitido el error en su comentario con gracia (ver #43).
Otros parecen empecinados en no ver lo que a todas luces es obvio...
#41. El tiempo de respuesta a los errores se mide desde que se descubren. Antes de descubrir un error, nadie, en ningún sistema operativo, tiene la posibilidad de corregirlo. En este caso el tiempo de respuesta es de unos 2 días.
Y como #1 indica, como no se había descubierto antes, tampoco se sabe exactamente desde cuando podría estar presente, que es lo que dice la noticia: "podría estar desde..."
Ubuntu también lo tiene corregido: http://www.ubuntu.com/usn/usn-2127-1/
Varias cosas, que ya dije en otras noticias similares anteriormente:
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
#42 El disponer del codigo fuente es una gran ventaja. Primero porque puedes ver el funcionamiento e incluso modificarlo segun convenga (siempre que se tenga conocimientos). Al ser privativo es muchisimo mas complicado poder entender/modificar ese software (y no creo que se pueda modificar por ejemplo un kernel de un sistema cerrado porque seria algo tan complejo y podrian fallar tantas cosas ...).
Quien sabe si en un futuro no existiran herramientas automaticas basadas en redes neuronales o sistemas expertos que puedan buscar bugs en codigo fuente de programas de forma eficiente y rapida. Si no se dispone del codigo fuente no se podra realizar este tipo de cosas o sera mucho mas complicado.
De todas maneras yo voto por medidas de seguridad que sean capaces de proteger al sistema y los datos de posibles bugs o puertas traseras. Herramientas avanzadas a nivel kernel como SELinux, Pax/Grsecurity y cosas parecidas; junto con medidas de seguridad de red o entornos sandbox-virtuales, y otro tipo de medidas para evitar problemas de seguridad producidos por bugs (intencionados o no).
#11 Tantos los virus Sasser como Blaster, fueron creados por ingeniería inversa de los parches de Microsoft que corregían las vulnerabilidades que explotaban.
Para Sasser, el parche salió 17 días antes de que observaran las primeras muestras (http://csc560.wikispaces.com/The+Sasser+Worm), para Blaster el virus salió el 11 de agosto para una vulnerabilidad que fue parcheada un 16 de julio (http://nsrg.eecs.umich.edu/publications/IEEE_Security_Privacy_Blaster_Final.pdf).
¿Por qué las máquinas infectadas no habían sido actualizadas?
Estoy con #42: la idea de que el software libre es más seguro por el mero hecho de que cualquiera puede leer el código roza el mito. Me recuerda al security by obscurity.
Y coincido con #8 en su última frase (aunque sólo en eso, me temo jeje). Si se ha de criticar algo al menos que sea aportando datos, no como un fanboy más. Eso no hace más que añadir ruido y estupidez a una conversación. Y empobrece a todas las partes.
#50 > la idea de que el software libre es más seguro por el mero hecho de que cualquiera puede leer el código roza el mito. Me recuerda al security by obscurity.
Normal que te lo recuerde, es justo lo contrario.
#42 Ciertamente el software libre no tiene por qué ser seguro por el mero hecho de ser libre, pero desde luego es mucho más transparente y, hasta donde yo sé, cuando se detecta un error se hace público y se procede inmediatamente a su corrección, explicando al detalle en qué consistía el fallo y cómo se ha corregido.
#42
- El mito de que poder ver el código nos da automáticamente seguridad hay que desterrarlo ya, crea en la gente una falsa sensación de seguridad totalmente irreal. ¿Quién supervisa los 17 millones de lineas del kernel? y ya no digamos los billones del resto de programas, es imposible.
Lo que siempre se dice no es que nos da automáticamente seguridad. Lo que se dice es que nos da mucha más seguridad que un código cerrado.
De hecho, nunca escucharás a un programador experto asegurar que algo no tiene bugs. Y si lo hace, es que no es tan experto.
- Determinadas implementaciones no necesitan un millón de ojos mirando código, porque igual solo hay dos o tres personas que entiendan realmente qué hace cada cosa y por qué, y esas personas no pueden supervisarlo todo.
Por eso hay partes que son muy delicadas y se está buscando continuamente gente que las entienda para que colabore.
Por eso hay empresas que invierten en software libre y son ellas mismas las que desarrollan y auditan el código, para estar seguras de que se hace bien.
Por eso hay modificaciones (que no parches urgentes) del kernel de Linux que tardan meses en salir adelante, porque quieren estar seguros.
Señalas un problema, pero no señalas que el software libre lo soluciona mejor que el software privativo.
- Linux y otros sistemas libres salvo dos o tres incluyen firmware cuya fuente no está disponible.
Por eso está por ejemplo Debian, que te obliga a añadir "a mano" el software que no tiene licencia libre. Nadie está obligado a instalar este software, igual que nadie está obligado a abrir el ejecutable que te envía por email el rey de Nigeria para que le ayudes a mover el dinero a un paraíso fiscal.
¿Que el usuario medio no lo sabe y lo instala a ciegas? El usuario medio tampoco sabía la primera vez que el cartel del visitante un millón era mentira, ni tampoco sabía que la aplicación para ver quién ha visto tu perfil de facebook era una trampa para robarte los datos. Lo que falta es alfabetización digital, no puedes proteger a los usuarios de su propia estupidez.
- El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
Claro que se puede auditar, igual que el software libre (que algunas librerías o partes del kernel han sido auditadas por empresas expertas). Pero sigue siendo menos seguro que un código libre que además cualquiera puede auditar.
¿Desensamblar sirve realmente de algo?
Te pongo el caso más diferenciador: si yo soy una empresa medianamente grande y quiero asegurar mi software, ¿realmente crees que Microsoft me dejará auditar el código de Windows? ¿O Apple el de iOS? Con GNU/Linux no tengo ni que pedir permiso.
- Esto podría haber sido un backdoor a la vista de todo el mundo que el programador ha dejado ahí intencionadamente, lo único que nos ofrece el código abierto en este caso es la capacidad de ver quien ha sido el que ha introducido el cambio y ver si ha hecho cosas similares en otros sitios. Además esta hipótesis cobra fuerza porque hay muchos "fallos" similares últimamente.
Pero esto es lo bueno del software libre: es muy meritocrático. Conforme vas adentrándote en el código más delicado de GNU/Linux, más difícil es que un desconocido pueda comitear sin que su código lo revisen cien ojos. Se sabe perfectamente qué partes ha hecho cada uno y se le pueden pedir cuentas por conductas sospechosas.
Alguien que haga código de mala calidad (como este), sea o no queriendo, tiene poco futuro de comiteador, si es que puede llegar a serlo alguna vez.
Alguien desconocido que haga código de mala calidad, sea o no queriendo, va a tener que pasar muchas revisiones antes de poder comitear.
¿Conclusión? Claro que puede haber problemas y fallos de seguridad. Pero la clave no es que no los haya, la clave es que son muchos menos y que cuando salen a la luz, se solucionan mucho más ŕapido.
Si el OS privativo tiene X medidas de aseguramiento de la calidad, el OS libre tiene esas X medidas y además tiene las medidas de aseguramiento de la calidad que sólo pueden darse en el software libre. Por pura lógica, el OS libre será más seguro que el OS privativo.
¿Quién en su sano juicio escogería un sistema operativo más inseguro y que tarde más en parchear los agujeros de seguridad para un proyecto empresarial serio?
#79 Perdona pero eres tu el que está haciendo un debate de blanco o negro.
Yo no soy anti-software libre, eso sería una locura, porque evidentemente es mejor tener el código disponible que no tenerlo (esto en respuesta a #78 también), no gastéis tinta convenciéndome de lo que es mejor, que ya lo tengo claro.
Pero mi comentario no iba por ahí, lo que quería resaltar es que aunque sea mejor tener el código no es una garantía inmediata de seguridad o de calidad, claro que hace más fáciles las auditorías, pero hay que hacerlas y las tiene que hacer un programador que sepa lo que hace, esta noticia demuestra que un fallo puede pasar años a la vista de todos y no ser corregido simplemente porque no hay recursos para auditar todo el código disponible.
Sigo con lo de #78
- El kernel de Debian tiene partes no libres, o para ser más general -> Linux ahora mismo no es 100% libre. No lo digo yo, hace poco tuve la suerte de poder entrevistar en persona a Richard Stallman y estuvimos hablando largo y tendido sobre este tema. Si quieres un kernel 100% libre hay un fork que usan distros como GNUsense y alguna más (en realidad es un script que elimina las partes no libres)
- ¿Desensamblar sirve realmente de algo? -> SI, puse el ejemplo del malware precisamente para ver como se puede analizar un programa sin tener el código fuente y además un programa ofuscado a mala leche para no ser detectado, cifrado, empaquetado, etc..
- Lo de la meritocracia en un mundo ideal sería así, pero en realidad si miras las estadísticas de los proyectos en github por ejemplo (digo ahí porque a través de la API es muy fácil), después de una vulnerabilidad los comitters son exactamente los mismos. No hay gente apenas que sepa implementar cierta cosas, que vas a hacer, ¿prohibirle desarrollar por un error?
Y ya lo de que son muchos menos fallos es el eterno debate en el que no quería entrar.
Échale un ojo al malware en Android (Linux) en 2013, o a las vulnerabilidades detectadas en el kernel de Linux en el mismo año, o a los CVE por sistema operativo, etc.. damos por sentado cosas que no siempre son así.
¿Debería de ser más seguro, tener menos fallos? ok, puede ser, pero la realidad no es esa.
En lo de corregirlos antes después del aviso si que no hay vuelta de hoja, es infinitamente más rápido el software libre por el simple hecho de que no se limita por cuestiones comerciales
Dicho todo esto, aunque me da una pereza terrible tener que justificar nada, yo soy pro-software libre, y creo que es mejor tener acceso al código ya desde un punto de vista técnico, obvio, pero creo que de vez en cuando no viene mal un chorro de realidad para que los "uso linux y no tengo antivirus porque mola mucho y es seguro" despierte y se ponga las pilas.
#93 No se muy bien que tiene que ver android y su malware con todo esto porque sinceramente no encuentro la relación. Si vas a instalar una linterna y le das permiso para leer sms no creo que sea por culpa del kernel.
"pero creo que de vez en cuando no viene mal un chorro de realidad para que los "uso linux y no tengo antivirus porque mola mucho y es seguro" despierte y se ponga las pilas."
¿y que tiene que ver un agujero de seguridad con un virus? ¿hace falta instalarse un antivirus en linux en un cliente de escritorio? ¿has tenido muchos virus en linux?
#97 Tiene que ver en que en android es trivial analizar el código de una app y sin embargo hay malware a dolor, cientos de miles en lo que va de año, así que va de que la relación entre facilidad de análisis seguridad no siempre es directa, hay otros factores mucho más determinantes como la cuota de mercado, el tipo de datos objetivo, y por supuesto lo que dices tu, la colaboración del usuario.
Y no, que yo sepa no he tenido virus como tal, ¿y tu? no se si has tenido un rootkit, un troyano, un backdoor en una aplicación, no todo el malware son virus, nisiquiera el más preocupante, en vez de tener un antivirus en un Linux de escritorio paso mi tiempo buscando otro tipo de cosas, pero los riesgos son similares.
Por cierto, ¿has oído hablar del gusano "The Moon"? (pongo este ejemplo porque es muy reciente) , búscalo y enjoy, que hacemos con eso, decimos que como no hace falta un antivirus para routers linksys, ¿ya es muy seguro?, los hechos desmontan estos argumentos fácilmente.
Y otra reflexión, el panorama de ausencia de ese tipo de amenazas era igual en Mac OS X hace unos años, y hoy en día si es recomendable tener un antivirus en Mac, así que no es descartable un antivirus en Linux en el futuro.
#93 es que es un debate o "mito" inventado el tuyo. Nadie dice lo que tú pones en boca de no se sabe quién. Nunca lo he leído de nadie decir que el software libre dé "automáticamente seguridad"; ni Stallman dice eso. Entonces no sé por qué lo pones.
#42 eso es una manipulación. Nadie cree que el software, por ser libre, ya es "automáticamente" seguro. Me das un enlace de alguien que diga eso? Lo que se dice es que el software libre, en general, es un modelo más eficiente, pero no perfecto, claro, y no por ser libre algo ya es bueno necesariamente. Los que no tenéis argumentos de peso recurrías al "blanco o negro" para convertir esto en un debate tipo Madrid contra Barcelona, igual que pasa en política.
#42 Ole, ole y ole tus pelotas, comparar la depuracion de código en c con la ingeniería inversa.
Y ya de lo de asumir que solo hay 3 personas en el mundo que comprendan el funcionamiento del kernel...
#42 El software privativo TAMBIEN SE PUEDE AUDITAR, se le puede hacer análisis dinámico y se puede desensamblar, se puede ver lo que hace, como se hace con el malware, y como harán los que le interese con Windows u otros programas. ¿Que es difícil? Toma, claro, pero auditar millones de lineas de C también.
Solo que en el caso de software privativo, tienes que desensamblar y auditar cientos de millones de líneas en ensamblador o en un lenguaje 'C' autogenerado mucho más difícil de seguir. No comparemos.
Si este error estuviera en un sistema propietario, no se habría descubierto. (Por lo menos públicamente, hay mucha gente ganando pasta con 0-days)
#42 Ole tus cojones. Comprar el desensamblar software propietario el cual tiene muchas veces protecciones frente a ello contra código en C automáticamente disponible.
¿Es un chiste?
¿Vas a compararme ESTO http://www.openbsd.org/cgi-bin/cvsweb/ contra la caja negra de Windows? A vacilar a otro.
nuh!, esta visto que hay que volver a http://www.openbsd.org/
#17 Yo ya estoy en BSD, pero yo lo llamo MacOSX
Una cosa que se le escapa a muchos: si hay un bug en una lib como esta, en otros sistemas operativos se verían obligados a actualizar "cientos de aplicaciones" como dice el titular, debido a la política de la compilación estática o de incluir cada programa sus propias libs en su directorio de instalación. En GNU/Linux no, se actualiza sólo esa lib y fin de la historia. Los demás programas que la usan tiran de la compartida por el sistema, facilitando el mantenimiento.
sudo apt-get upgrade -V
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
libgnutls-openssl27 (2.12.23-1ubuntu4.1 => 2.12.23-1ubuntu4.2)
libgnutls26 (2.12.23-1ubuntu4.1 => 2.12.23-1ubuntu4.2)
libgnutls26:i386 (2.12.23-1ubuntu4.1 => 2.12.23-1ubuntu4.2)
libpython2.7 (2.7.5-8ubuntu3 => 2.7.5-8ubuntu3.1)
libpython2.7-minimal (2.7.5-8ubuntu3 => 2.7.5-8ubuntu3.1)
libpython2.7-stdlib (2.7.5-8ubuntu3 => 2.7.5-8ubuntu3.1)
libpython3.3 (3.3.2-7ubuntu3 => 3.3.2-7ubuntu3.1)
libpython3.3-minimal (3.3.2-7ubuntu3 => 3.3.2-7ubuntu3.1)
libpython3.3-stdlib (3.3.2-7ubuntu3 => 3.3.2-7ubuntu3.1)
python2.7 (2.7.5-8ubuntu3 => 2.7.5-8ubuntu3.1)
python2.7-minimal (2.7.5-8ubuntu3 => 2.7.5-8ubuntu3.1)
python3.3 (3.3.2-7ubuntu3 => 3.3.2-7ubuntu3.1)
python3.3-minimal (3.3.2-7ubuntu3 => 3.3.2-7ubuntu3.1)
13 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados.
Necesito descargar 13,8 MB de archivos.
Se utilizarán 36,9 kB de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]?
#52 tardas en actualizar el bug Critico de la década lo mismo que en leer a los Trolls en menéame. He actualizado varias maquinas por consola, y sin quitarme el pijama
#72 eres un crack. Con Windows tienes que ponerte el mono de obra y echas por lo menos una semana.
#76. Tienes razón. Los updates de Windows destacan por su rapidez en salir y por su velocidad al ser aplicados. Sin hablar de lo poco molesto que es reiniciar varias veces para que los pille todos...
Una gloria.
#52 #72 Corred insensatos a actualizar como locos, ni un minuto que perder que un segundo sobre nueve años son una eternidad.
#0 Te falta poner el vía: @1789014
Ah si ahora empezamos con lo de que el fallo no es del kernel si no de una libreria, y con lo de GNU y Linux y los nombres y Stallman... cojo palomitas.
¿Y por qué en la de Apple (apple-goto-fail-fallo-seguridad-ssl-tls-posible-relacion-nsa/2)
Apple y "goto fail", un fallo de segurid...
genbeta.com#34 Por la coincidencia de fechas de introducción del bug con un anuncio del programa PRISM de la NSA.
¿Coincidencia? Los conspiranoicos no lo creen así.
¿Alguien sabe si afecta a Android? Creo que es lo que más nos debería preocupar ahora mismo, porque actualizar millones de teléfonos Android va a ser la risa.
#66 Me contesto a mí mismo. Al parecer Android utiliza OpenSSL, por lo que no está afectado por el bug. Aunque puede haber aplicaciones específicas que sí utilicen GNuTLS. http://www.tomsguide.com/us/critical-linux-flaw-gnutls,news-18406.html
Aviso a todos los IGNORANTES que se alegran de los supuestos males ajenos: el fallo no es de Linux, sino de GnuTLS. Linux no tiene que corregir nada, y el fallo existe en otros sistemas que no usan Linux. Sensacionalista, errónea y malintencionada.
Bueno, al menos los BSD que linkan todo contra OpenSSL estarán medianamente seguros.
Lo bueno del software abierto y libre es que estas cosas se detectan rápidamente y del mismo modo, se tarda poco en solucionar. Lo malo es que mientras esto sucede, los que quieran aprovecharse lo tienen más fácil que si no se dijese nada. Depende de la comunidad.
Con el software cerrado: lo mismo lo arreglan; lo mismo dicen nada y algunos que lo saben hacen de las suyas; o lo mismo lo arreglan con tardanza. Depende de los intereses de la empresa y los recursos que ponga.
#5 #39 : Esta vulnerabilidad lleva ahí casi una década y no ha sido detectada hasta ahora. Que algo sea SW Libre no garantiza su calidad, ni que sea seguro. Hace falta que personas con el conocimiento suficiente se tomen el tiempo necesario para analizarlo.
#46 No ha sido detectada en una decada pero el código está ahí para que se pueda detectar y corregir. De hecho el bug se ha encontrado por una auditoría de código de Red Hat. Si el código es cerrado nadie puede auditarlo ni en una década ni en diez.
#77 : Pues claro que se puede auditar sin tener el código fuente, como ya han comentado anteriormente. Si realmente hiciese falta tener el código para detectar una vulnerabilidad, los sistemas privativos serían precisamente los más seguros También se puede ceder ese código fuente para la auditoría sin necesidad de hacerlo público.
En los comentarios a la noticia en Ars Technica enlazaban este correo de 2008 en que ya parecía claro que GnuTLS tenía problemas serios:
http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
El SW Libre sigue necesitando esfuerzo real. Si nadie lo realiza, la calidad no aparece mágicamente.
#46. Hace falta que personas con el conocimiento suficiente se tomen el tiempo necesario para analizarlo.
En algunos sistemas no llega con eso, ya que carecen de la posibilidad de analizar nada.
Que manía tenemos de defender o de justificar el software libre diciendo que X o Y sistema tardaron más en parchear errores similares. Linux, como cualquier otro sistema operativo, está hecho por humanos imperfectos, es normal que las cosas que hagan sean imperfectas. Ya. Punto. Sin comparar.
#64 El único comentario con sentido común de por aquí. No se cuándo nos daremos cuenta de que las tecnologías están ahí para que escojamos lo mejor de cada una, a nuestro criterio. Nunca entenderé la manía de "predicar".
#0: Es GNU/Linux, no Linux. El tema es importante, porque existen otros sistemas operativos como GNU/Hurd.
Bueno, quiero decir, algún día existirán.
#47 Y GNU/kFreeBSD (kernel de FreeBSD, herramientas GNU y apt de Debian) desarrollada por Debian.
Y GNU/NetBSD (kernel de NetBSD y Debian).
"Actualmente, hay al menos cinco distribuciones de GNU/Hurd en preparación (Debian GNU/Hurd, Gentoo, Arch Hurd, Bee y A.T.L.D. GNU/Hurd), aunque ninguna ha publicado versiones oficiales".
A ver quien acaba antes
Saludos.
Me encanta lo FÁCIL y RÁPIDO que se solucionan las cosas en GNU/Linux:
root@debianNAS:~# apt-get update
Des:1 http://security.debian.org wheezy/updates Release.gpg [836 B]
Des:2 http://ftp.es.debian.org wheezy Release.gpg [1.672 B]
Des:3 http://security.debian.org wheezy/updates Release [102 kB]
Des:4 http://ftp.es.debian.org wheezy-updates Release.gpg [836 B]
Des:5 http://ftp.es.debian.org wheezy Release [168 kB]
Des:6 http://ftp.es.debian.org wheezy-updates Release [124 kB]
Des:7 http://security.debian.org wheezy/updates/main Sources [89,2 kB]
Des:8 http://ftp.es.debian.org wheezy/main Sources [5.956 kB]
Des:9 http://security.debian.org wheezy/updates/main amd64 Packages [162 kB]
Des:10 http://security.debian.org wheezy/updates/main Translation-en [90,2 kB]
Des:11 http://ftp.es.debian.org wheezy/main amd64 Packages [5.845 kB]
Des:12 http://ftp.es.debian.org wheezy/main Translation-es [349 kB]
Des:13 http://ftp.es.debian.org wheezy/main Translation-en [3.849 kB]
Des:14 http://ftp.es.debian.org wheezy-updates/main Sources [3.399 B]
Des:15 http://ftp.es.debian.org wheezy-updates/main amd64 Packages/DiffIndex [643 B]
Des:16 http://ftp.es.debian.org wheezy-updates/main Translation-en/DiffIndex [643 B]
Descargados 16,7 MB en 12seg. (1.327 kB/s)
Leyendo lista de paquetes... Hecho
root@debianNAS:~# apt-get upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
libgnutls26
1 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados.
Necesito descargar 618 kB de archivos.
Se utilizarán 0 B de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]?
Des:1 http://security.debian.org/ wheezy/updates/main libgnutls26 amd64 2.12.20-8+deb7u1 [618 kB]
Descargados 618 kB en 1seg. (604 kB/s)
Leyendo lista de cambios... Hecho.
(Leyendo la base de datos ... 28050 ficheros o directorios instalados actualmente.)
Preparando para reemplazar libgnutls26:amd64 2.12.20-8 (usando .../libgnutls26_2.12.20-8+deb7u1_amd64.deb) ...
Desempaquetando el reemplazo de libgnutls26:amd64 ...
Configurando libgnutls26:amd64 (2.12.20-8+deb7u1) ...
root@debianNAS:~#
#94 ¡Sencillísimo! Y los pardillos de Mac haciendo esto...
También actualizado en Arch, aunque no es un paquete tan importante como en Debian o Fedora: https://www.archlinux.org/packages/extra/x86_64/gnutls/
#83 En Arch por ejemplo no viene instalado Gnutls.
Para los que se empeñan en decir que es un fallo de Linux...
En mi distro fué corregido anteayer
Lo que siempre sale patente en estas noticias es que si algo falla en Linux (como en este caso) ese fallo no es Linux (aunque sea una librería que usa todo cristo y que venga de serie en el 99% de instalaciones) y cuando algo funciona de puta madre, no es merito del software es merito de Linux.
Esto cada vez se parece más a lo de los médicos con las estampitas de la virgen.
#89. ¿Ya has actualizado tus aplicaciones Windows que usan GnuTLS?
1. Esa librería no solo se utiliza en Linux.
2. Ese bug no está en Linux, está en la librería. Es como si un error en Firefox se achaca a Windows, absurdo.
3. Nada más que desir.
Sensacionalista.
Windows hace años que va hacia abajo y Linux hacia arriba, por mucho que la gente se empeñe en no verlo...
Fan boys everywhere! No me toques mi linux, no me toque mi ñu o vas a pagar las consecuencias!
Como linuxero pensar que Linux no tiene fallos lo considero un error, esta hecho por personas y como tal no esta exento de errores. Personalmente la politica de asumir errores e intentar corregirlos lo mas rapido posible desde que se detectan es algo que el software libre hace y no el software propietario.
¿por qué sale una foto de Jordi Évole con un vaso escuchando la pared?
Me acabáis de alegrar la semana... Como sí tuviese pocas cosas que hacer de por sí
Bueno, lo primero de todo, que GnuTLS no está ni mucho menos tan extendido como OpenSSL, de hecho hay aplicaciones como el wget que pueden compilarse con una o con otra. GNUTls existe por una discrepancia sobre si la licencia de OpenSSL es o no compatible con la GPL.
Por si a alguien le interesa el diff del cambio:
https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b
En serio alguien usa gnutls?...
ahora mismo estará Tovard encantadisimo por la noticia
Este error ya lo arregle yo mismo editando la fuente y recompilando, lo que no entiendo es que no se hayan dado cuenta hasta ahora....
A ver, dentro de mi ignorancia y por eso pregunto, si el código es abierto y ha habido un bug des de 2005, al ser abierto no lo pueden haber visto "malas personas" antes, lo hayan utilizado y mientras no se enteren lo sigo utilizando?
Es decir, con código abierto todo el mundo puede ver los fallos y corregirlos bastante antes que el software cerrado (que solo lo vigilan unos pocos), pero eso no expone también los fallos a todo el mundo de forma mas fácil?
Pongo por ejemplo, imaginemos que hacemos un misil de defensa tierra-aire y publicamos todo para que la gente se pueda defender. Hay un malo malote que nos quiere atacar y como también tiene toda la información de nuestro misil, sabe como evitarlo por que sabe de que pie cojea. No se si me explico... Si no tengo el codigo, me tengo que currar la busqueda de los bugs "a ciegas"
#87 Por todo eso hay otras medidas de seguridad que pueden ayudar: SELinux, Pax/Grsecurity, seguridad de red, etc... Lo que pasa que son cosas complejas de entender/configurar y que a veces pueden venir desactivadas por el kernel Linux.
No entiendo cómo el GNU/Linux no ha triunfado entre la gente sin ningún conocimiento informático, es todo tan sencillo.
Algo que es gratis no puede ser mejor que Winddows.
#70 siempre he pensado que linux no es gratis, nunca lo fue, que alguien te regale algo no quiere decir que sea gratis
la gente que descarga linux da su apreciada ingenuidad a cambio de recibir libertad, por eso no es gratis.
perder tu ingenuidad es un precio muy grande, y debes que valorar muy bien lo que vas a obtener y la responsabilidad que ello aporta antes de dar ese paso. por eso muy poco lo hacen
LINUX = CACA
No es posible. Linux no tiene fallos de seguridad. Debe ser algún cacho de código que les copiaron a los del Windows.
#2 por suerte con linux has podido mirar el codigo de tu Operating System y has podido corregirlo tu a mano antes de compilarlo. En Windows no habrias podido.
Ademas Bill Gates dona dinero para desgravar impuestos.
#5 que tiene que ver lo de "Ademas Bill Gates dona dinero para desgravar impuestos. " ¿?
¿Eso te lo has inventado, o tienes alguna fuente fiable, con números, que lo demuestre?
#59 las fuentes están ahí, en la red. Usando TOR para que nadie espíe tus conexiones, SSL y una búsqueda rápida en google bajo OpenBSD o similar las encontrarás. No te olvides de hacer todo eso en una máquina con hardware de "código abierto", impresa en 3D. Y desde la terminal, para no depender de "navegadores intrusivos". Ponle letras verdes y fondo negro.
Yo ahora mismo no puedo buscártelas ya que tendría que recompilar mi kernel, pero vamos que Windows es una mierda.
#62 para algunas cosas será mejor linux, para otras windows, para otras mac.... no creo sea muy bueno tachar un sistema operativo como "mierda" cuando al final, por el motivo que sea, se tiene que terminar usando...
#65 es una mierda porque oprime mi libertad. Mi libertad de decidir qué línea de código quiero en cada momento. Por ejemplo en Windows no puedo ocultar el Clip de Word, sin embargo en Linux con LibreOffice ya es otra historia!!
Además sin hablarte de que en Windows trabajan los peores profesionales, y que Linux es una COMUNIDAD de gente que sabe mucho de programar.
NOTA: Antes de seguir, estaba troleando en mi comentario de #5 y lo he seguido haciendo. Me estaba haciendo un poco el "fanátio de Linux". Yo uso Windows cuando me conviene, también Linux para lo que me conviene
#67 viéndolo desde ese punto de vista, cualquier cosa va a oprimir tu libertad.
Una modificación que no puedes hacer en tu casa/piso, un cambio en el coche que no puedes, una decisión de tus jefes (si los tienes) contraria a tu forma de pensar.....
Sobre de que trabajan los peores profesionales... ¿datos?. Sobre que en una comunidad de miles de personas, están los que mejor saben programar.... y también los que peor saben, ¿no?
Ahora he leído tu nota ¬_¬
46 #59 #67 #73 #90 Creo que no habéis entendido la ironía de #5
#5 "y (tú mismo) has podido corregirlo tu a mano antes de compilarlo" JAJAJA, CRACK
#5 Operating System?¿??. Lleva el fallo desde 2005 y nadie lo ha encontrado. Para mi que los que dicen "corregir y compilar el código" para solucionarlo no es nadie, eso sí, queda muy molón decirlo y dárselas de buen programador y tal...
#5 Pues es raro, cuando tiene pensado donar la práctica totalidad de su fortuna a su fundación en lugar de dejarla como herencia. Seguro que eso desgrava impuestos en el cielo o algo, ¿no?
Si no estoy muy equivocado, el dinero que donas es el dinero por el cuál no tienes que pagar luego en impuestos, no como el dinero que, por ejemplo, te ha costado comprarte un Ferrari.
De modo que la única forma de que tenga sentido donar para evitar pagar de verdad es que tu ONG sólo sea una tapadera. Si vas a hacer acusaciones así, por lo menos podrías poner datos. Mejor, deberías denunciarlo en un juzgado.
Ese hombre no será un santo, ni mucho menos. Pero tampoco me gusta que se vaya acusando a la gente sólo por los clichés y los tópicos.
#5 hay que ser ignorante para decir eso de Bill Gates. Vaya negocio donar 100 para luego ahorrarte 20 de impuestos y perder un neto de 80. A ver si te piensas que desgrava más de lo que dona. Joder qué burros sois los linuxeros en general.
#2 Si los tiene, pero no le duran años sin solucionar cono a otros.
#2
Si teniendo el código a la vista un error puede pasar desapercibido durante 10 años imagínate si nadie puede ver el código, la de errores y puertas traseras que puede haber...
Por otro lado, linux es de mi propiedad así que es normal que lo defienda por malo que sea...
Como es normal que microsoft o apple defiendan su software cuando se descubren bugs y backdoors...
Lo que no es tan normal es lo de los fanboys
#8 A mi juicio no tiene sentido ponerse a defender nada a ultranza, ya lo consideres "tuyo", o no, que me parece tan debatible como defender tu "equipo", algo con lo que realmente no tienes nada que ver. Como mucho, tendría sentido defender el trabajo que hayas hecho, si es que has colaborado en algo.
No lo digo tanto por ti, sino en el contexto de lo que comentáis. Es mejor que sea libre, pero no por eso van a desaparecer mágicamente los fallos.
PS: Ah, una última cosa, a mi me parece sensacionalista lo que comentas al principio, porque no tiene que ser necesariamente así. No es de extrañar que si es "visible a todos" sea aún menos probable que nadie haga nada. Y que si tienes a una persona encargada de algo, al menos esa persona lo vea una vez.
Y no es por defender nada, simplemente no caigamos en falacias absurdas.
#2 No hombre. Lo irónico es que por los fallos del guindous te cobren. Los fallos del Linux los va descubriendo (y solucionando) la propia comunidad, pero no te quejes que es material abierto a disposición de cualquiera. Si lo usas es porque quieres y no has tenido que pagar por ello.
(Mira que mi madre me lo dice siempre: no des de comer al troll, no des de comer al troll...)
#2 vale, seguro que en unos días con un apt-get update tienes el problema solventado.
Dime, ¿cuánto tardó windows en solventar el virus del windows que te entraba nada más conectarte a internet?
Recuerdo que entrar en internet con tu modem y sin firewall era como ir de putas sin condom
#11 los devs de gnutls ya han sacado parche y recomendaciones. Ahora sólo falta ver la velocidad de las distintas distribuciones de ponerlo en los repositorios de paquetes y de los usuarios (particulares y empresas) en actualizar sus sistemas.
#11 Yo ya he actualizado en Debian mientras leía el articulo. Tanto la version la version estable (7.4 Wheezy) como la anterior (6.0.9) Squeeze. Esta disponible desde el dia 3 de marzo. http://www.debian.org/security/2014/dsa-2869
#2 Qué poca autocrítica tienen por aquí
. Inversamente proporcional a su postureo.
#2 Qué gran troleo. Te votaría positivo, pero para lo que te va a valer
De verdad, qué escaso sentido del humor que tienen estos linuxeros... ¿Sindrome Sheldom Cooper?