Una forma posible, aunque llevaría mucho tiempo en la práctica, sería volver a las raíces. El desarrollo de GNU comenzó en 1984, y la versión original de Minix (que se utilizó durante el desarrollo inicial de Linux con fines de arranque) se lanzó en 1987.
Toda esta respuesta se basa en su premisa de que "[usted] u otros tienen la capacidad de leer y comprender el código fuente por fallas de seguridad, por lo que el código fuente será examinado primero antes de compilar", y que puede confiar en el resultado de dicho análisis . Sin eso, esta respuesta es probablemente peor que inútil, ya que pasarás una gran cantidad de tiempo sin ningún beneficio.
Si puede encontrar una copia del libro original de Minix con el código fuente, puede escribirlo desde el libro. Compílelo y luego use un descompilador diferente en un sistema diferente para verificar que el compilador genere la salida binaria esperada en lenguaje máquina. (El código es de solo 12,000 líneas, presumiblemente C, por lo que hacerlo lleva mucho tiempo pero es razonable si se toma en serio este proyecto). Incluso podría escribir su propio desensamblador; eso no debería ser muy difícil.
Tome las versiones más antiguas de las utilidades de GNU que posiblemente pueda tener en sus manos (ya que presumiblemente tienen menos código y menos dependencias de bibliotecas externas), revise el código, compílelo para Minix (sin embargo, esto podría requerir algo de trabajo; absolutamente lo que quiero evitar es hacer ajustes al código fuente, porque eso hará que agregar parches más tarde sea muy propenso a errores) y pasar por un ciclo similar de desmontaje-verificación para las herramientas GNU. En ese momento, confía en el sistema operativo y la cadena de herramientas, por lo que solo necesita revisar el código fuente en el conjunto de parches (cualquier cosa que no esté en el conjunto de parches ya es confiable), pero las herramientas seguirán siendo muy primitivas y crudas en comparación con lo que se usa hasta hoy. Por ejemplo, no espere nada más que la funcionalidad más básica de las herramientas del sistema.Lee muchos XKCD.
En algún momento, tendrá un sistema que puede compilar y arrancar una versión inicial del kernel de Linux, al igual que se hizo a principios de la década de 1990 cuando Linux comenzó a ganar tracción entre los piratas informáticos. Sugeriría migrar a Linux en ese punto (reconstruir las bibliotecas del sistema y la cadena de herramientas contra Linux, construir el kernel de Linux, arrancar en Linux y posiblemente reconstruir el kernel de Linux y la cadena de herramientas GNU dentro de Linux; lo último prueba que el sistema ahora es auto- hosting), pero eso depende en gran medida de usted. Continúe verificando parches, parcheando el kernel, las bibliotecas y las herramientas básicas de GNU, y reconstruya hasta llegar a las versiones modernas.
Es entonces cuando tiene un sistema operativo y un compilador básicos confiables que se pueden utilizar para crear software moderno. Para entonces, puede seguir, por ejemplo, las guías de Linux From Scratch para crear un sistema capaz de realizar tareas útiles .
En ningún momento se puede conectar el sistema "compilador" a una red de ninguna manera (incluso como VM en un host en red); correría el riesgo de penetración a través de cualquier componente con capacidad de red, incluido el kernel. Si le preocupa un ataque del compilador Thompson , debe esperar que cualquier host VM también se vea comprometido. Use sneakernet para obtener el código fuente y los binarios del host físico en el que está compilando. Espere problemas para que los archivos entren y salgan del sistema al menos antes de llegar al punto donde se implementó el soporte de almacenamiento masivo USB. Si usted es realmente paranoico, listados de código fuente de impresión y las escribe en la mano (y la esperanza de que el controlador de la impresora y la impresora no tienen un código similar en ellas), o lea el código en un monitor de computadora y escríbalo físicamente en otra computadora que esté al lado, pero que no esté conectado a él.
Sí, esto llevará mucho tiempo. Pero la ventaja de este enfoque es que cada paso es incremental, lo que significa que sería mucho más difícil que se deslice cualquier cosa maliciosa a menos que se introduzca gradualmente durante un período de muchas versiones; Esto se debe a que el conjunto de cambios en cada paso es relativamente pequeño y, por lo tanto, mucho más fácil de revisar. Compare el conjunto de parches con el registro de cambios y asegúrese de poder determinar exactamente qué entrada del registro de cambios corresponde a cada cambio en el código fuente. Una vez más, esto supone que tiene la capacidad (posiblemente a través de alguien en quien confía) para verificar que dichos cambios no se hayan infiltrado en la base de código, pero debería acercarlo a un sistema confiable como un software solo, excepto- enfoque de firmware puede.