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
#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
Debian ya lo tiene corregido:
https://www.debian.org/security/2014/dsa-2869
¿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.
#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
#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.
#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.
#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...)
#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.
#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
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 *)
The coding error, which may have been present in the code since 2005,
#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.
#14 No es esencial.
Ubuntu también lo tiene corregido: http://www.ubuntu.com/usn/usn-2127-1/
#12, también Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-libs/gnutls/ChangeLog?view=markup
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).
#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
#29 Te estás confundiendo de bug, este es posterior y oficialmente se corrigió el día 3 de marzo.
#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?
#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.
#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?
#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"
nuh!, esta visto que hay que volver a http://www.openbsd.org/
#39 Emmm... el error tiene 9 añazos, por si no lo has leído...
(véase #1)
#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.
#7 goto #1
Tan solo le ha durado 9 años 
#94 ¡Sencillísimo! Y los pardillos de Mac haciendo esto...
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.
#2 Si los tiene, pero no le duran años sin solucionar cono a otros.
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]?
#29 Ya estaba yo cagado haciendo apt-gets en los servidores y ahora te veo...
#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.
#19 No he dicho que no fuese esencial (que lo será en muchas distribuciones), sino que no era exclusivo.
#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.
#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.
#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/
#12 Por curiosidad ¿tiempo entre que han avisado y que se ha arreglado?
¿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#33
¡ Qué fallo ! Inintencionado total.
¡ Qué vergüenza ! Al menos votarme negativo, que se note que es un error.
¿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.
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.
#13 Modificado
Bueno, al menos los BSD que linkan todo contra OpenSSL estarán medianamente seguros.
#163 No es para tanto. En algo tenías razón, la mayoría de los ordenadores ya estaban actualizados porque tienen habilitadas las actualizaciones automáticas (o porque sus usuarios son actualizadores compulsivos )
#13 Porque esa librería es parte esencial del sistema operativo GNU/Linux.
Resulta interesante ver las diferentes reacciones de los mismos usuarios ante el mismo tipo de fallo, dependiendo de si es error de Apple o de Linux.
Pero no os cortéis, que siga el festival de autojustificaciones, voy a por más palomitas.
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.
#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.
#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í.
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.
#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
#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.
#41 PWNED! (¡Auch..!)
Pero, ojo, que por norma general es así. En cuanto se detecta algo, se arregla con relativa rapidez
#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.
#12 Ubuntu también corregido http://lwn.net/Articles/589232/
#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#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.
#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
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:~#
#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.
#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...).
#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?
#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...
#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.
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/
#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...
#168 Kubuntu ya tiene docks incorporados.
#170 Crea un lanzador y arrástralo.
En mi distro fué corregido anteayer
#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
#109 Vamos que escribir sudo apt-get update && sudo apt-get upgrade es ultra complicado...
Pero si tienes un entorno gráfico como Gnome puedes instalar las actualizaciones dándole a un botón con su notificación automática y todo.
#2 Qué poca autocrítica tienen por aquí
. Inversamente proporcional a su postureo.
#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.
#157
, a qué me dedico es otro asunto) son de periodista/comunicólogo y no tengo ni idea de programación (algo de Basic y C, y HTML+CSS), sencillamente soy usuario de GNU/Linux desde Debian Potato GNU/Linux, antes usuario de Mandrake.
Mis conocimientos (oficiales
Te aseguro que yo no soy capaz de mirar ese código y ver la vulnerabilidad, se puede ser usuario de sistemas operativos open source y libres GNU/Linux y BSD sin ser ingeniero y sin tener la más remota idea de programación. Te doy mi palabra.
Soy incapaz de usar Windows, me siento inseguro, siento que no controlo lo que tengo delante, es más, me siento controlado.
Por eso uso software de código abierto y libre. Porque quiero tener el control de la máquina que uso, (la línea de comandos sigue siendo una maravilla) y porque no quiero pagar por una licencia de uso, quiero pagar por el trabajo de elaboración, distribución, resolución de dudas, y participar en una comunidad global como lo es la del software libre, aportando mi minúsculo grano de arena.
GORA GNU/LINUX!!!
#134 Claro, claro, si le pasa a Apple es muy posible que haya sido financiado por la NSA, a pesar de que la librería con el bug de Apple es Open Source y cualquiera podía ver el código "financiado por la NSA". Tiene toda la pinta de ser un fallo al hacer un merge en los repositorios, pero cuando uno tiene ganas de echar mierda la echa como sea.
Eso sí, le pasa lo mismo a una librería de la comunidad GNU y los razonamientos ya son totalmente distintos.
Hacéoslo mirar, anda.
#171 Puede ser una buena opción aunque pienso que sería inocua puesto que al final vendrían activados por defecto para no añadirle complejidad al usuario normal y este va a darle a aceptar sin quitarlos uno a uno. Al final creo que es lo mismo, sea como sea eso no es un error del kernel que es de lo que hablábamos.
#173 Más ... lo que hace apple con su tienda de aplicaciones ...me parece mejor gestionado.
#176
Muy bien, es una forma de hablar.
La palabra propiedad es el dedo El hecho de que sea un procomún y pueda considerarlo, por tanto también mío, es la luna.
#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.
#102 Ya. Pero seamos sinceros: si quisieras tener acceso a lo que circula por la red ¿qué sistema operativo atacarías, Mac OS X o Linux? (obviamente hay que tener en cuenta que sistema es el más utilizado en servidores).
Me sorprende un poco que con un SO minoritario como Mac OS X salten los conspiranoicos con lo de la NSA, pero en uno que es usado en la gran mayoría de los servidores del mundo nadie diga nada...
(Bueno, no me sorprende tanto en realidad, ya se que en Menéame no se puede hablar bien de Apple ni de nada que la empresa haga, porque inmediatamente te atacarán y te acusarán de fanboy).
#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.
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.
#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.
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...
#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".
#121 ¡Venga ya!
#122 Es lo que me dice mi vecina todos los días: "¡No te olvides del sudo apt-get, que va a hacer frío!"
(Cualquier CLI, para un usuario sin conocimientos, es infranqueable).
#127 Eso o que has ido de listo más bien.
#110 No pretendo meterme en vuestra discusión, pero cada que alguien termina culpando a los usuarios por no leerse los permisos me da un patatuz. El sistema de permisos actual es pésimo, y no creo que sea muy difícil de cambiar por algo que te permita elegir directamente que permisos admites y cuales no, que realmente puedas denegar un permiso. Si una aplicación pide permiso de acceso a internet, y no se lo das, pues le simulas que no hay señal, que está apagado, etc, nisiquiera rompes la aplicación porque ya debería considerar esos fallos.
Sin contar que hay permisos que no se cuentan como críticos, como el de leer sms.
Lo único que se consigue es precisamente enseñarle al usuario medio que los permisos no sirven para nada, así que para qué se los va a mirar, y bueno, siguiendo tu crítica, la tienda de google permite todo, excepto lo que vaya directamente contra sus intereses.
#172 Eso es inevitable, pero al menos no tienes un sistema inútil que da una falsa seguridad y puede resultar muy contraproducente, más que eso no puedes hacer. Me recuerda en cierta medida a las mejoras de seguridad de win7 y vista, que solamente servían para echarle la culpa al usuario.
#72 eres un crack. Con Windows tienes que ponerte el mono de obra y echas por lo menos una semana.
#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.
Fan boys everywhere! No me toques mi linux, no me toque mi ñu o vas a pagar las consecuencias!
#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.
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
#136 fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
Yo hago ironía y vosotros me insultais. Mal negocio. ESO SÍ QUE ES MAL NEGOCIO!
#138 te remito a #108, el pobre ha tenido que explicarlo por mí jaja
Lo que me asusta un poco ahora es que, habrá gente que lo ha pillado y me ha votado positivo porque les ha hecho gracia. Pero otra mucha gente parece que no lo ha pillado y me ha votado positivo simplemente porque piensa así... Miedo tengo.