Portada
mis comunidades
otras secciones
#2:
"I don't' want to have anything to do with virtualization stuff," Torvalds said. "I want to run on hardware; I'm a real man."
Comentarios
#12 Teniendo en cuenta el bajísimo número de personas que compilan kernels hoy en día, si hubiera una puerta trasera en el kernel, su difusión sería prácticamente del 100%
#13 Cierto yo compilaba el kernel, pero hace años que no lo he vuelto a compilar, ahora mismo ni me acuerdo como se hacía.
#5 en este foro es más importante obedecer normas estúpidas que proporcionar contenido interesante.
#9 Son los talibanes del microblogging, los que votan negativo por tonterías y en lugar de hablarlo con la persona que envía prefieren tumbarla y que no se sepa.
Wellcome to meneame.
#10 son estas cosas que me molesta más… conseguí mi primera portada en junio de 2006
#0 El titular ralla el microblogging: Torvalds responded "no" while shaking his head "yes," as the audience broke into spontaneous laughter.
#3 ¿ralla? En la noticia todo lo que sale al respecto es lo de la entradilla.
"I don't' want to have anything to do with virtualization stuff," Torvalds said. "I want to run on hardware; I'm a real man."
#22 No es que yo me fíe o me deje de fiar, sino que esa confianza no debería estar siquiera en la ecuación.
Yo estoy proponiendo soluciones (#15). ¿Y tú?
Nadie te va a asegurar nada 100%, pero si todo es compilado desde un codigo fuente y con unos parches que publican y controlan en detalle cada distribucion con una persona responsable para cada paquete y todo eso: tu crees que van a meter una puerta trasera asi por asi y si se descubre ya saben quien es el responsable???
Supongo que no entiendes cómo funciona el compilado binario del software. Partiendo de un código fuente, que puede ser público y auditado y todo lo que quieras, un grupo insultántemente reducido de personas cogen ese código fuente y lo convierten en binario. Durante ese proceso de compilado es trivial introducir parches no públicos que alteren el contenido final del binario.
No existe ninguna forma sencilla para el usuario final de determinar si ese binario que utiliza proviene realmente del código fuente publicado o si contiene parches no públicos.
Así que toda la publicación y revisión de código fuente público se queda en nada si las cuatro manos (a veces dos) que crean el binario tienen intereses en introducir código malicioso.
Y dadas las últimas noticias publicadas ya no se trata de malas personas, sino de personas que no quieren ir a prisión tras ser acusados de Traición por un organismo gubernamental.
Así que no, tu respuesta no es una respuesta sino que es cerrar los ojos a un problema.
La solución de "pues compílatelo tú" ni es solución ni es nada. Es un mientras ande yo caliente que se joda el resto de la gente™
A nivel de kernel no es tan facil meter una puerta trasera y que no se de cuenta nadie (ya no digo mirando codigo solamente, sino por conexiones no permitidas o sockets, entre otras cosas). Para ello y para hacerlo bien hay que poner a mucha gente de acuerdo en poner la "puerta trasera" y que no se pueda detectar por ningun lado ni con ninguna herramienta o mecanismo del kernel.
Osea que tu gran argumento es que el código malicioso estará tan mal hecho que será fácilmente detectable.
Claro que sí.
Chapó.
No voy a entrar en lo absurdo de ese argumento porque me da la risa y se me saltan las teclas.
Y no, el código malicioso no tiene por qué estar publicado para estar en el binario.
#23 Tu crees que no se pueden luego depurar esos binarios a bajo nivel y desensamblar por los mismos desarrolladores??? Ej. objdump, strace, ltrace, gdb, libdisasm, ....
Además para que crees que existen las firmas hash en las distribuciones linux y el control que se tiene desde los repositorios oficiales.
Eso que planteas no digo que no se pueda hacer, pero tampoco te creas que es muy dificil descubrirlo.
Y te vuelvo a decir que si quieres te coges una distribucion basada en codigo solamente que las hay y muchas o ya puestos te la fabricas tu desde 0 con LFS entre otros metodos.
Yo pienso que si eso llegara a pasar, se descubriria al final y habria responsabilidades y desprestigio para los culpables (además de un control mucho mas exahustivo).
pd.: si ya te pones paranoico total con los binarios y eso, pues tienes utilidades para firmarlos criptograficamente (los ejecutables) como por ejemplo "bsign" con lo que ademas de las firmas hash de cada fichero tendrias firma interna en los ejecutables (no se que distribuciones pueden hacer uso de eso, pero hasta podrias proponerlo para alguna de las miles que existen si es que no lo han tenido en cuenta antes.
#24 Tu crees que no se pueden luego depurar esos binarios a bajo nivel y desensamblar por los mismos desarrolladores???
Exacto. Encontrar algo ahí sin saber lo que buscas exactamente es como buscar una aguja en un pajar.
Además para que crees que existen las firmas hash en las distribuciones linux
Las firmas hash únicamente sirven para que puedas identificar el binario oficial de uno falso. No te protege si el creador del binario ha introducido parches no oficiales.
y el control que se tiene desde los repositorios oficiales.
A este grupo es al que me refería como a un grupo insultántemente reducido de personas.
¿Puedes asegurarme a ciencia cierta que todos los binarios contenidos en una distribución linux han sido compilados y verificados por distintas personas de distintos marcos legislativos? (si todos los participantes son de EEUU no cuenta, obviamente)
Eso que planteas no digo que no se pueda hacer, pero tampoco te creas que es muy dificil descubrirlo.
De nuevo la "solución" es que "no ocurra" y que si ocurre "tengamos suerte" de descubrirlo. Y eso requiere que quienes han introducido ese parche no sean "suficientemente buenos" como para no ser descubiertos.
Ya me siento más seguro. Deben ser las alas.
Y te vuelvo a decir que si quieres te coges una distribucion basada en codigo solamente que las hay y muchas o ya puestos te la fabricas tu desde 0 con LFS entre otros metodos.
Y te vuelvo a decir que el problema no es mío sino de todos. ¿Tan difícil es comprender ese concepto?
Yo quiero que a mi padre no le espíe la NSA. ¿Tengo que enseñarle a compilar su propio linux?
Gracias pero no gracias.
Yo pienso que si eso llegara a pasar, se descubriria al final y habria responsabilidades y desprestigio para los culpables (además de un control mucho mas exahustivo).
Intel.
pd.: si ya te pones paranoico total con los binarios y eso, pues tienes utilidades para firmarlos criptograficamente (los ejecutables) como por ejemplo "bsign" con lo que ademas de las firmas hash de cada fichero tendrias firma interna en los ejecutables (no se que distribuciones pueden hacer uso de eso, pero hasta podrias proponerlo para alguna de las miles que existen si es que no lo han tenido en cuenta antes.
Y dale.
Yo no soy el compilador de binarios de Linux, de Apache, de OpenBSD, de Android ... ¿tan difícil es entender que la solución no pasa porque "yo" sea quien compile el binario?
¿Tan mal me explico?
#26 El proceso de compilado de kernel de Debian es abierto. Vete al Git de alioth, te lo bajas y te creas tu propio Deb . Con OpenBSD, lo mismo. He vuelto a mi SO favorito y los snapshots de sistema (kernel y userland) me los actualizo cada mes via CVS.
Es decir, todo está disponible para el público, la publicación de cada distro no se hace a puerta cerrada:
https://alioth.debian.org/projects/pkg-debile/
http://alioth.debian.org/
#38 ¿Ese proceso de compilado es deterministico? ¿El resultado final que se consigue es idéntico, bit a bit, a la versión distribuida en forma de binario?
Si no es así los problemas que he citado anteriormente siguen vigentes.
#42 "¿Ese proceso de compilado es deterministico? ¿El resultado final es idéntico, bit a bit, a la versión distribuida en forma de binario?"
Suma MD5 o SHA1. Si las opciones de compilación se mantienen, el binario será idéntico. Los paquetes deb-src se compilan de la misma forma que los oficiales de la distro, pues se aplican los parches automaticamente con debuild.
#43 Si ese procedimiento existe y está debidamente documentado entonces es a lo que me refería inicialmente.
Ojalá se extiendan este tipo de prácticas a todo el software libre del que se distribuyen binarios y éstos dispongan de métodos similares para corroborar públicamente que éste no contiene parches no publicados.
Si eso ya fuera así pues perfecto.
#44 Creo que todas las distros lo hacen. Al menos las basadas en Deb. Sobre las RPM,
pkreuzt nos podría informar.
#42 Creo que "sorrillo" se refiere a la introducción de una puerta trasera justo antes de preparar el paquete para la distribucion (antes de sacar la firma hash).
#38 En cuestion de seguridad no cambiaría un buen Linux por OpenBSD para uso general. Te dejo un enlace para que reflexiones: http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
Dentro del mundo BSD preferiria un FreeBSD por muchos motivos ademas de implementar mas medidas de seguridad.
#46 La "gracia " GRSEC y demás, es que si encuentras un modo de saltarte esas restricciones, el sistema cae enterito. OpenBSD parchea y restringe cada binario que forma parte de su sistema principal y paquetes esenciales recompilados, como apache, mysql, XFCE, varios juegos...
De hecho siguen usando un Apache, pero ultraparcheado y fortificado en plan paranoico, sin dependender de ajustes externos. (que los hay, kern.securelevel y demás...)
Si quieres usar un Opera propietario desde los ports usando la capa de compatiblidad con Linux , allá tu.
Parchean hasta las funciones en C de los programas por sus contrapartes seguras, no te digo más.
#48 Yo creo que es mas bien al contrario, si se encuentra un bug explotable en OpenBSD si cae el sistema entero porque no dispone de contramedidas eficaces. Linux dispone de muchas y no solo por medio de MAC.
Es una utopia intentar que no exista ni un fallo o bug explotable (remotamente o localmente) en un sistema operativo por muy abierto que sea y muy buenos que sean sus programadores.
Ademas OpenBSD es muy limitado en otros aspectos comparado a Linux.
Hombre, siempre hay que intentar usar todas las medidas de seguridad ofrecidas y por supuesto intentar usar software abierto en la medida de lo posible (no Opera claro esta).
#50
http://www.openbsd.org/security.html
http://en.wikipedia.org/wiki/OpenBSD_security_features
"Privilege separation,] privilege revocation, chrooting and randomized loading of libraries also play a role in increasing the security of the system. Many of these have been applied to the OpenBSD versions of common programs such as tcpdump and Apache, and to the BSD Authentication system. OpenBSD also supports sandboxing of untrusted applications using the Systrace facility, a framework allowing interposition of system calls for fine-grained restriction of processes. Systrace supports interactive generation of policies, and other features designed to allow privilege elevation.
"
Linux intenta paliar el problema poniendo barreras que muchas veces son reventadas, como pasa con SeLinux. OpenBSD intenta crear un sistema invulnerable desde la base y luego ya pone capas con kern.securelevel y demás estrategias.
#51 Aquí te dejo un resumen de algunas medidas de seguridad en Linux: https://www.linux.com/learn/docs/727873-overview-of-linux-kernel-security-features/
#53 Por esto te digo, lo mejor es usar ambos.
#54 Tienes razón, pero yo ya pierdo mucho tiempo aprendiendo un solo sistema y es muy dificil llegar a un nivel de conocimiento muy profundo en cada sistema como para conocer en mucha profundidad 2 sistemas (aunque sean parecidos). Linux me llena bastante y lo uso para todo (aunque a veces haya usado software privado, jeje), y me ofrece todo tipo de posibilidades y mucho soporte en la comunidad y libros o documentación también. Por eso tengo que usar principalmente un sistema y conocerlo en profundidad.
#55 Tranquilo, la configuración avanzada de OpenBSD es hasta más sencilla que la de Linux. Editando tres archivos exactamente, tienes un sistema configurado:
En el .profile de /root, añades esto :
export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/`uname -r`/packages/`uname -m`/
Guardas, ejecutas "pkg_add -v pkg_mgr slim slim-themes", abres pkg_mgr e instalas el escritorio que te plazca. Con marcar "xfce y xfce-extras" en "meta" y pulsar "a" te sobra.
Finalmente, pones lo siguiente en /etc/rc.local :
[ -x /etc/rc.d/slim ] && /etc/rc.d/slim start
y reinicias. Ya tienes un XFCE. Faltan algunos ajustes de disco que lo optimizan
enormemente(sin exagerar), pero así te tira en un pentium II perfectamente.
. La instalacion en disco es mas simple.
#56 De BSD me gusta la sencillez de sus scripts de init (en rc.d) y en Linux tienes Slackware que usa ese esquema y otras cosas muy parecidas a los BSD.
#58 Si, pero no necesitamos systemd o udev, junto con otras cosas. Slackware es parecido pero OpenBSD tiene una mejor documentación en todo(nada está sin documentar), como suele pasar con algunas distros de Linux.
Y el rc.conf de OpenBSD es más simple que una patata. Y todo es así. Puedes crearte una interfaz virtual que haga bonding entre dos interfaces en 3 líneas...
echo "up" > /etc/hostname.re0
echo "up" > /etc/hostname.re1
echo "trunkproto roundrobin trunkport re1 trunkport re0" > /etc/hostname.trunk0
#59 Documentación man de OpenBSD es muy buena y si es cierto que algunas distribuciones Linux tienen una documentación regular o escasa a veces (Debian no esta mal porque tienes también las manpages de practicamente todo paquete e incluso en español muchas de ellas).
A mi me gusta la simpleza de OpenBSD. Sobre la union de interfaces ethernet, en Linux si tienes que configurar alguna cosilla más (aunque no mucho mas).
#60 Debian lo mejor casi es pasar de las man, instalar elinks o lynx y meter sysadmin guide junto con los doc-debian-es o similares para administrar Debian y entonces sí, leer las man de lo que te quieras aplicar de la guía.
http://www.debian.org/doc/manuals/debian-reference/
Vamos, con sysadmin-guide y doc-debian estás servido. Obligado de instalar en todo Debian.
Sobre OpenBSD, entre la FAQ, la guía de instalación y empezando con "man afterboot" configuras todo el sistema. Todo-todo.
#61 OpenBSD tiene sus cosas buenas, pero no todo es bueno y creo que hay mas de lo que se dice lo que pasa que al no ser un sistema tan usado no aparecen tanto sus defectos:
http://aboutthebsds.wordpress.com/2013/01/25/20/
http://aboutthebsds.wordpress.com/2013/03/31/bsd-vs-linux/
Aunque van mejorando poco a poco.
#66 Ese post como comentan, no está más que basado en FUD
"Theo de Raadt willing allowed government agencies and possible terrorist organizations to put back doors into OpenBSD. An example of this is shown in December 2010 when de Raadt allowed FBI agents to plant backdoors in OpenBSD’s Cryptographic Framework which they had taken from Linux and illegally removed the GPL license."
Se demostró que no y que no era cierto. Puro FUD.
"The majority of programs that runs on GNU/Linux without configuration requires recompilation of the kernel to run on BSD."
Este hombre quiere que lo baneen de por vida en las listas de cualqueir *BSD, ¿verdad? El kernel GENERIC cubre de todo y más si usas una Snapshot.
#66 "ext4 inductions, journaling reinforced with soft updates which has saved countless numbers amounts of data that would have been lost due to crashes, "
openbsd:/home/ander$ cat /etc/fstab
927597be419ac72f.b none swap sw
927597be419ac72f.a / ffs rw,softdep,noatime 1 1
/proc /proc procfs rw,linux 00
swap /tmp mfs rw,nodev,nosuid,-s=1048576
El blogger sigue en el año 1999 o no se entera.
"Numerous amounts of test by phoronix have shown that BSD is not just slower than GNU/Linux"
Segun que BSD. NetBSD en máquinas antiguas con no mucha CPU (Pentium I-III) tira bastante mejor que GNU/Linux.
"An example is in 2011 where by Theo de Raadt (Head of the OpenBSD project) made an agreement with the FBI to plant a backdoor in OpenBSD, OpenSSH and PF"
Seguimos con lo mismo, no hubo tal backdoor.
"Not only that but Linux is actually usable on all the platforms that it has been ported to while for NetBSD, the only thing it can do on most platforms is just bootup with no ability for the user to interact with it or use it."
Avisadme cuando GNU/Linux vuelva a arrancar con la misma soltura en un Amiga/Mac/Atari M68K y sea capaz de arrancar las X, o que funcione igualmente en una VAX.
"In BSD, there is only the slow, unreliable, prone to errors and difficult to use ports tree and pkgsrc."
http://www.openbsd.org/faq/faq15.html#PkgInstall
http://rhaalovely.net/pkg_mgr/
#68 Podrías comprobar si es cierto lo que comenta del kernel panic en caso de sacar un pendrive sin desmontar?
#69 Lo he hecho varias veces...
#70 Pues seguro que se basa en versiones mas antiguas de los sistemas BSD.
#70 He buscado un poco por internet y he visto algunos problemas con lo del USB pero en FreeBSD y de hace un tiempo (2008/2009).
#72 Yo en OpenBSD sin problema. Vale, he tenido que instalar una cosilla para automontar las unidades en /vol (hotplugd-disks o algo así) y un programita en la bandeja del sistema para desmontar, pero por lo demás funciona todo, hasta las Webcam USB.
#73 Por cierto, como cojones instalas OpenBSD en un pendrive desde la iso para poder instalarlo en un netbook??? He seguido una guía que tienes hasta que crear una imagen para qemu y luego instalarlo en esta imagen para despues volcarla con dd en un pendrive. Un jaleo que flipas para que luego me diera un problema de particiones internas del pendrive y no pueda empezar a instalarlo.
Alguna manera sencilla usando solo fdisk y dd o con algo como unetbootin???
#74 http://liveusb-openbsd.sourceforge.net/#Usbinst Coges esta imagen y le haces un dd.
#75 cual de ellas?
#75 la minimal?
#75 en la pagina pone que la imagen de instalacion es sobre 130 MB pero yo solo encuentro un enlace de imagen que ocupa trescientos y algo MB. No se si es esa imagen?
#75 Te envié un privado para no alargar aquí la conversación. Gracias.
#50 Si quieres un sistema más seguro... instala ambos y úsalos indistintamente. Un escritorio XFCE en Debian testing no se diferencia del OpenBSD 5.3.
#23 Legalmente no te pueden obligar a nada y mucho menos a saltarte las licencias ya establecidas para ese software (que eso si seria delito judicial).
#25 Legalmente no te pueden obligar a nada y mucho menos a saltarte las licencias ya establecidas para ese software (que eso si seria delito judicial).
Alma de cántaro ...
El FBI amenaza con arrestar al fundador de Lavabit por cerrar el servicio [ENG]
El FBI amenaza con arrestar al fundador de Lavabit...
investigations.nbcnews.comNo todo el software que usas está compilado en el marco legislativo de España. Salvo el que compiles tú mismo (que sé que me vendrías con eso de nuevo).
#27 Pues te coges una distribución totalmente libre (aconsejada por la FSF) o te coges una que la monten en un país ajeno a EEUU que hay muchisimas y buenas (ejemplo. OpenSUSE), o incluso una Japonesa o China si quieres (no creo que esos metan nada para la NSA).
Si una distribución se acoge a una licencia tipo LGPL no pueden obligar a nadie a meter una puerta trasera. No pueden obligar legalmente. Es como si tu sacas un programa o un juego y te obligan a que metas una puerta trasera: ¿no podrias denunciar ese abuso? Es algo ilegal claramente.
#28 De nuevo pones tu fe en el sitio equivocado.
Estás pidiendo que tu país, u otro, no haga una ley que no conozcas y relativa a elementos como la "seguridad nacional" o "terrorismo" (palabras clave para hacer lo que les de la gana) y decidan aplicarla a un ciudadano que no conoces obligándole con amenaza de cárcel a hacer un acto "por el bien del país".
Tu fe la pones en eso.
Yo prefiero ponerla en la ciencia. En las matemáticas. En la criptografía.
Y no me vuelvas a proponer que mi padre aprenda a compilar binarios, por favor.
#27 Te recuerdo de nuevo que aunque te metan una puerta trasera y no puedas/sepas desensamblar o depurar binarios para encontrar algo sospechoso, se puede comprobar con utilidades del sistema o incluso externas al mismo (sniffers, cortafuegos, etc) algunas actividades sospechosas, puertos usados, sockets usados, capturar trafico entrante/saliente, etc... Depende lo que se quiera auditar.
#30 Tu fe es admirable.
De veras.
¿Has leído las noticias últimamente?
Dime cómo detectas que el kernel tiene un parche que hace que en vez de generar números pseudoaleatorios genera una secuencia conocida por el atacante pero aparentemente aleatoria para el resto.
Dime que herramienta de auditoria de las que citas te permite detectar eso.
Y ya sin irnos al caso concreto de los números aleatorios indícame cómo detectas ese agujero de seguridad si ha sido programado para atacar víctimas específicas con nombres y apellidos. Es decir el parche en tu equipo no hace nada, ni en el mío, pero en el de tu tío, que no tiene ni idea de informática pero es el director de una multinacional, ese mismo software se activa una vez al año para iniciar una conexión saliente a servidores de Gmail controlados por la NSA.
Dime como detectas eso.
No seas tan inocente ni tengas tanta fe en que quienes programan malware son idiotas o no tienen ni idea de lo que vas a hacer para detectarlos.
Seamos más listos, busquemos soluciones que no dependan de tener suerte.
#31 Pues aparte de que puedo usar el generador de numeros para pruebas en mis propios programas, puedo coger y desactivar ese generador por hardware para usar uno por software (si te refieres a la noticia sobre supuesto problema en un generador usado por Intel).
Las puertas traseras tienen un fin (ya sea para robar informacion, para poder entrar en un sistema o algo parecido). Ese fin necesita por cojones el uso de Internet para sacar o meter datos. Tan dificil es ser un poco paranoico e instalar medidas de seguridad activas y pasivas de red en tu sistema o en tu propia red interna para comprobar comportamientos sospechosos???
Hombre ya si me pones casos extremos pues yo te pongo medidas extremas que se me ocurran (posiblemente alguien con mas conocimientos que yo te daría mas medidas).
Yo creo una gran ayuda esta en controlar la información que entra y sale de tu ordenador: limitar puertos, sockets, ip's de destino y de origen, auditar todo trafico (aunque eso ocupe muchos ficheros), poner sniffers, proxys y firewalls, etc... Todo esto usable tanto fuera como dentro del ordenador en cuestión.
Ya si me dices que la supuesta puerta trasera no va dirigida a mi sino solo a un objetivo especifico y no se activa ni manda nada, pues supongo que sera mucho mas complicado encontrarla.
#32 puedo coger y desactivar ese generador por hardware para
¿De veras no he sido capaz tras tantos comentarios de trasladarte lo que entiendo es el problema?
Tan dificil es ser un poco paranoico e instalar medidas de seguridad activas y pasivas de red en tu sistema o en tu propia red interna para comprobar comportamientos sospechosos???
Osea que lo de poder comprobar que los binarios oficiales distribuidos provienen efectivamente del código fuente publicado te parece una mala idea.
Es eso lo que intentas decirme, ¿no?
Que prefieres que no se pueda comprobar e instalar tú un cortafuegos que te proteja del generador de números aleatorios modificado y que usas para cifrar tus datos que salen a Internet.
Me rindo.
#33 Yo no he dicho eso. Toda medida para asegurar las distribuciones es bienvenida. Pero como aseguras tu eso??? Permites parches de las propias distribuciones???
Yo antes te he puesto algunas soluciones para gente a la que interese la seguridad absoluta (como usar distribuciones basadas en codigo fuente y no en paquetes binarios precompilados).
Di tu una solución que te parezca eficaz para ese problema.
#34 Yo no he dicho eso. Toda medida para asegurar las distribuciones es bienvenida. Pero como aseguras tu eso??? Permites parches de las propias distribuciones???
Ya lo he explicado ... hace mucho rato. Aquí: #15
#35 pero eso depende de muchas cosas. Tu dices que el binario que distribuyan debe ser identico (en tamaño y contenido) al que tu compilarias en tu propia casa, no???
Para empezar creo que influiria la maquina en que lo compiles, el compilador y version, el sistema operativo usado y kernel, directivas de compilacion, etc.
#36 Sí ese es el problema y a ese problema es al que hay que encontrar solución.
El proyecto que cito en #15 va en esa dirección y ya se está usando en algún proyecto. Aunque también es cierto que desconozco los detalles con profundidad como para saber si por ejemplo añade más problemas de los que soluciona.
Pero en cualquier caso la idea sí creo que es buena y que se debería intentar aplicar dentro de lo posible.
#37 Tienes algun enlace donde se comente ese proyecto?
Lo que si se puede hacer hoy día es saber como han compilado un paquete y que opciones han usado y que ficheros fuente (por lo menos en muchas distribuciones) e incluso te los puedes compilar tu mismo automaticamente sin muchos conocimientos (usando utilidades que ya vienen en distribuciones como Debian por ejemplo) y tendrias el paquete compilado para tu maquina y en tu maquina desde fuentes abiertos y visibles. Podrias compilar de esa forma toda tu distribución (aunque tarde un poco) y así estar mas tranquilo (pero en las actualizaciones supongo que se tendrian que compilar el paquete de nuevo entero). Es un poco mas facíl que usar una distribución totalmente basada en codigo fuente, pero necesitas un poco de tiempo de compilaciones.
#39 El enlace que tengo es el que cito en #15.
Es este: http://gitian.org/
#39 apt-build world, para que el que tanga un SSD rápido sobre todo. Aunque en BSD recomiendan los binarios por los propios parches que aplican de los desarrollores de OpenBSD para evitar buffer overflows y demás. (parches públicos)
Jeje... dice que no mientras afirma con la cabeza. ¿Pero realmente la añadió? Eso es lo que queremos saber
#4 Puedes comprobarlo aquí: https://github.com/torvalds/linux
#8 Sí. Perfecto. Ahora demuestra que el kernel que te envía tu distribución no tiene algo más que lo que dice el código fuente del mismo. Ahí esta el problema.
Linus no lo ha introducido. ¿Se puede decir lo mismo de Red Hat, SuSe, Ubuntu, Debian, etc, etc, etc?
#11 Todas las distribuciones de Linux te tienen que dar el código fuente del kernel. De hecho, si no te fías, te puedes compilar tu uno.
No digo que todos vayan a hacer esto, digo que el hecho de que puedas hacerlo es garantía suficiente de que no te la están clavando.
#11 #12 En Ubuntu y Debian: Apt-get download linux-source . Tú mismo. Tienes incluso el GIT del kernel para Debian abierto en Alioth.
Y Debian no olvidemos que mantiene el código fuente de todo el repo main y contrib en sus repositotorios.
Dada la relevancia de Debian ten por seguro que alguien se habría enterado.
#14 Eso no te asegura que el kernel precompilado, que es el que usa la mayoría de gente, no incluya código malicioso.
Para llegar a esa conclusión el compilado debe ser determinístico creando paquetes idénticos bit a bit, sólo de esa forma puedes confirmar que el binario entregado es idéntico al que tú puedes compilar por ti mismo y del que tienes el código fuente.
Y eso no es habitual.
En el caso de Bitcoin utilizan el servicio Gitian que permite hacer precisamente eso, no lo conozco en profundidad pero sí parece que sería el camino a seguir: http://gitian.org/
#15 Yo uso OpenBSD. Compilar el kernel y userland tarda como 1/4 veces menos que Linux, y es un proceso muchísimo más simple . Aunque yo cogo snapshots, actualizo por FTP, sysmerge y a vivir.
Es todo tán simple y sencillo que me encanta. Documentado hasta el límite de forma exquisita. , todo. La API de C, el sistema, tras el arranque... (man afterboot) . Tengo KMS, así que no me privo de algún jueguillo.
#16 No tiene nada que ver con lo que yo estaba comentando pero bueno.
#17 Me refiero a que puedes compilar Debian si quieres, nada te lo impide. Incluso puedes hacer un debootstrap desde fedora y compilarlo desde ahí si no te fías.
#18 Eso no está en discusión.
¿Puedes admitir, ni que sea por un momento, que la inmensa mayoría de kernels que están ahora mismo funcionando no han sido compilados desde código fuente por el usuario final?
#19 Bueno, eso es su problema. Tienes también Trisquel el cual está recompilado por ellos mismos, y es un proyecto auspiciado y patrocinado por la FSF.
#20 Pues no, no es su poblema, es un problema de todos.
¿Si tú envías un correo electrónico a una persona te aseguras antes que esa persona haya compilado él mismo su propio kernel? ¿Y que lo hayan hecho todos los administradores de sistemas de los servidores de correo intermedios?
Sí es cierto que cualquiera de esos individuos, hagas lo que hagas, puede espiar voluntariamente tus correos. Pero aquí de lo que se trata es de si puede espiarlos una agencia gubernamental a quién nadie les ha dado permiso y con quien ni tú ni el administrador del servidor de correo ni el destinatario no tiene voluntad de colaborar.
Si tu crees que eso es "su problema" mal vamos.
Por cierto, ¿has compilado el kernel de tu teléfono móvil?
#21 Mira, si no te fias de los precompilados de las distribuciones, pues pasate a una distribucion que se base en codigo fuente como Gentoo o incluso te la fabricas si quieres (LFS - Linux from Scratch).
Nadie te va a asegurar nada 100%, pero si todo es compilado desde un codigo fuente y con unos parches que publican y controlan en detalle cada distribucion con una persona responsable para cada paquete y todo eso: tu crees que van a meter una puerta trasera asi por asi y si se descubre ya saben quien es el responsable???
A nivel de kernel no es tan facil meter una puerta trasera y que no se de cuenta nadie (ya no digo mirando codigo solamente, sino por conexiones no permitidas o sockets, entre otras cosas). Para ello y para hacerlo bien hay que poner a mucha gente de acuerdo en poner la "puerta trasera" y que no se pueda detectar por ningun lado ni con ninguna herramienta o mecanismo del kernel.
#16 Algunos estamos atados a Linux por culpa de drivers propietarios como antes estábamos con Window$
#62 ¿Nvidia? Tranquilo, OpenBSD anda portando KMS, y en un futuro la base de Nouveau junto con un servidor X mejorado (Xenocara) tirarán bastante bien.
De hecho la rama -current ya tiene soporte para las Intel.
#63 No, PowerVR: http://en.wikipedia.org/wiki/Intel_GMA#GMA_3600
#64 Eso va mal incluso en Linux. Las GMA son un horror .
#80 Ok ya lo vi. Tengo una ATI pero lo voy a usar solo en modo texto, aunque si me gustaria tener framebuffer en consola si puede ser.
Errónea, parece ser una coña de Linus
Ver vídeo en https://thehackernews.com/2013/09/us-government-asked-linus-torvalds-to.html
¡Ay, pillín, pillín!
"..Yet Torvalds considered that hardware innovation might at some point slow down. He said he's interested in seeing how the industry will react when Moore's Law no longer works. In his view, it's just a matter of physics with how far silicon innovation can go."
Linus no ha tenido en cuenta que el silicio está al limite, pero que en breve entraremos en el nivel cuántico cuando demos el salto al grafeno. Yo creo que la ley de Moore hasta podría quedarse corta..
Lo que no significa que los haya introducido. ¿No habia ya quedado esto desmentido en otra noticia?
http://sourceforge.net/projects/liveusb-openbsd/files/install53.img.7z/download Ésta, es lo mismo que la ISO de la 5.3 pero en versión pendrive. No tira con un unetbootin, tienes que usar DD.
Sobre el hardware y el netbook, si tienes una gráfica intel, bien; si es una ATI te envío un privado sobre como actualizarte a "current" desde FTP, que tiene su miga.
Tambien cuando te pregunte por X DM, dí que no, más adelante te digo como instalar Slim, pero por privado.
Si la NSA quisiera introducir una puerta trasera podría tratar de colarla con algún commit, al menos durante un tiempo funcionaría.