¿Es más seguro compilar código de código abierto que simplemente ejecutando el binario?

La mayoría de las veces, es apenas más seguro y, a veces, es menos seguro.

  

¿En qué condiciones puedo simplemente descargar el archivo ejecutable (recortable?)

Los paquetes firmados de las principales distribuciones se crean en los servidores de compilación de la Distribución. En ese sentido, es casi seguro que es mejor utilizar el sistema de embalaje.

  

¿Hay ocasiones en que debo compilar el binario desde la fuente?

En general, un repositorio de control de origen, como git , crea un historial no acreditado que puede observarse en oposición a la salida binaria que podría modificarse por separado. En ese sentido, el código fuente es más seguro, pero solo si realmente lo está revisando. Es posible que se coloquen binarios maliciosos, o que el sistema del desarrollador de paquetes se vea comprometido con un compilador malicioso, pero las instancias registradas del primero son raras, y las últimas son casi desconocidas.

La compilación también puede exponerlo a errores desconocidos. Si usa diferentes opciones de compilador, puede introducir un error que no se ve en el binario distribuido regularmente. Hay muchos casos de fallas dependientes de la máquina o cambios en el comportamiento debido a diferentes banderas del compilador. En ese sentido, compilar desde la fuente podría ser menos seguro.

La respuesta definitiva aquí se reduce a cuánto crees que vale la pena en forma de tiempo que estás dispuesto a gastar para verificar la fuente del código binario o fuente.

Primero, permítame decir que no conozco ningún caso donde solo el archivo ejecutable precompilado de un proyecto FOSS contenga código malicioso. Entonces, si está buscando ejemplos concretos, esta respuesta probablemente no sea para usted.

La mayor ventaja de compilar el código usted mismo es la capacidad de leer dicho código y determinar lo que realmente hace el código. Esto a menudo se promociona como la principal ventaja del código FOSS. Ver la Ley de Linus.

  

Dados suficientes globos oculares, todos los errores son superficiales

Personalmente, el enfoque que tomaré depende de la reputación del proyecto FOSS en cuestión. Si es algo enorme y de buena reputación como el kernel de Linux, solo usaré los binarios que proporcionen y confiaré en los muchos desarrolladores para detectar códigos maliciosos y solucionar problemas de manera inmediata. Si el proyecto no es de buena reputación, intentaría revisar el código fuente para ver si hay algún indicio de código malicioso antes de compilarlo. Si eso no fuera posible, cuestionaría el uso de dicho proyecto FOSS y en su lugar buscaría uno más confiable o incluso escribiría la funcionalidad yo mismo.

El código fuente es "más seguro" de las siguientes maneras:

• Plantar una puerta trasera discreta en el código fuente (a diferencia del código binario) es difícil, en proporción con la cantidad de personas que revisan el código fuente.
• Muy pocos virus infectarán automáticamente el código fuente.

La primera forma no es una garantía fuerte. En primer lugar, ya que está imaginando un autor hostil, entonces debe considerar las formas en que ese autor podría darle a usted un código fuente específico con una puerta trasera, distinta del código fuente visto por todos los demás. Por lo tanto, el conjunto de personas que están en posición de revisar la fuente que está a punto de compilar puede reducirse a una sola persona, es decir, usted. En ese caso, si usted , personalmente, no está dispuesto a realizar una revisión completa del código fuente, la compilación del código fuente no lo hará más seguro que usar un binario, al menos contra un autor hostil que Quiere plantar una puerta trasera.

En segundo lugar, las puertas traseras y otras vulnerabilidades son errores. Se ha demostrado ampliamente que ninguna revisión de código puede detectar todos los errores, incluso los muy graves, incluso para los errores que son errores honestos. Si no podemos descubrir de manera confiable los errores que son producto de la mera mala suerte y la falta de atención, ¿cómo podemos esperar reconocer los errores creados intencionalmente por un atacante supuestamente inteligente que intenta evitar la detección?

Una referencia clásica que debe leerse es Conferencia sobre el premio Turing de Ken Thompson . Para una historia más reciente, vea todo el drama sobre el supuesta puerta trasera en la implementación IPSec de OpenBSD , que resultó ser (oficialmente) un fracaso. Si bien en este último caso parece que no hubo una puerta trasera real (no me he comprobado), destaca el hecho de que plantar una puerta trasera en un PRNG sutilmente defectuoso parece altamente posible, incluso como código fuente que está a la vista de muchas personas.

Al final, es una cuestión de riesgo . Desde el punto de vista del atacante, poner la puerta trasera en el código fuente es arriesgado: si dicho código fuente está ampliamente disponible, entonces el riesgo de ser atrapado es mayor; mientras que una puerta trasera en código binario es mayormente segura, nuevamente, para el atacante. Confiar en que el código fuente sea más seguro para usted significa confiar en la racionalidad del atacante , es decir, usar el código fuente porque cree que el atacante no estaría lo suficientemente enojado como para correr el riesgo de poner La puerta trasera en el código fuente visible.

La protección contra virus probablemente tenga un valor práctico más alto, al menos en los binarios para Windows. Al utilizar el código fuente, es inmune a la mayoría de los virus que pueden ejecutarse en la máquina del autor del software (pero, por supuesto, no contra el virus en su propia máquina, pero estos ya están ahí).

En primer lugar, como han dicho otros, el código abierto no significa que aquellos que miran el código tengan la habilidad suficiente para detectar los problemas que mencionas. Además, se puede hacer que el código parezca benigno cuando en realidad hace algo entre bambalinas: consulte el concurso de código C debajo de la mano para obtener un ejemplo:

  

una competencia que desafía a los programadores a resolver un problema simple de procesamiento de datos al escribir un código C de apariencia inocente que sea tan legible, claro y aparentemente confiable como sea posible, pero que implemente una función maliciosa.

En segundo lugar, incluso si el código no necesariamente tiene bits maliciosos explícitos, podría ser vulnerable a ataques que puedan comprometer el sistema. Heartbleed podría ser el ejemplo más obvio aquí.

Suponiendo que confía en el autor (es) y en la comunidad, y que no hay problemas sutiles como vulnerabilidades en generación de números aleatorios , el problema ahora es: ¿cuándo puedo confiar en el binario y cuándo es más recomendable compilar desde la fuente?

Para responder a esta pregunta, le sugiero que revise compilaciones reproducibles . Se están implementando en debian y otros incluyendo tor . Si el programa FOSS en el que está interesado proporciona compilaciones reproducibles y un sistema automatizado para distribuir sumas de comprobación, las posibilidades de que un binario se vea comprometido son escasas. En particular, vea cómo El proyecto Qubes cuando se trata de firmar.

Por último, no olvides que el problema podría no estar en el código fuente de la aplicación en un escenario donde tu compilador está comprometido . En este caso, es mejor estar con binarios (de confianza).

Usted está más seguro con la solución más utilizada. Si no hay sumas de comprobación, entonces no se ponderará de ninguna manera. También esto es dependiente del tiempo y dependiente de la cultura.