Un modo possibile, anche se in pratica richiederebbe molto tempo, sarebbe quello di tornare alle origini. Lo sviluppo di GNU iniziò nel 1984, e la versione originale di Minix (che fu usata durante lo sviluppo iniziale di Linux per scopi di bootstrap) fu rilasciata nel 1987.
L'intera risposta si basa sulla tua premessa che "[tu] o altri hanno la capacità di leggere e comprendere il codice sorgente per i difetti di sicurezza, quindi il codice sorgente verrà controllato prima della compilazione" e che ci si può fidare del risultato di tale analisi . Senza questo, questa risposta è probabilmente peggio che inutile, in quanto trascorrerai un sacco di tempo senza assolutamente alcun beneficio.
Se riesci a trovare una copia del libro Minix originale con il codice sorgente, puoi digitarlo dal libro. Compilarlo e quindi utilizzare un decompilatore diverso su un sistema diverso per verificare che il compilatore generi l'output binario del linguaggio macchina previsto. (Il codice ha solo 12.000 righe, presumibilmente C, quindi farlo richiede molto tempo ma è ancora ragionevole se si prende sul serio un progetto del genere.) Si potrebbe persino scrivere il proprio disassemblatore; non dovrebbe essere molto difficile.
Prendi le versioni più vecchie delle utility GNU sulle quali puoi eventualmente mettere le mani (dato che presumibilmente hanno meno codice e meno dipendenze da librerie esterne), vai attraverso il codice, costruiscilo per Minix (questo potrebbe richiedere del lavoro, però; assolutamente da evitare è apportare modifiche al codice sorgente, poiché ciò renderà l'aggiunta di patch in seguito molto soggetta a errori) e passerà attraverso un ciclo di verifica disassemblaggio simile per gli strumenti GNU. A quel punto ti fidi del sistema operativo e della toolchain, quindi devi solo passare attraverso il codice sorgente nel patchset (tutto ciò che non è nel patchset è già attendibile), ma gli strumenti saranno ancora molto primitivi e rozzi rispetto a ciò che sei usato ad oggi. Ad esempio, non aspettarti altro che le funzionalità di base degli strumenti di sistema.Leggi un sacco di XKCD.
Ad un certo punto, avrai un sistema in grado di compilare e avviare una versione iniziale del kernel Linux, proprio come è stato fatto nei primi anni '90 quando Linux ha iniziato a guadagnare terreno tra gli hacker. Suggerirei di migrare su Linux a quel punto (ricostruire le librerie di sistema e la toolchain contro Linux, costruire il kernel Linux, avviare Linux e possibilmente ricostruire il kernel Linux e la toolchain GNU all'interno di Linux; l'ultimo dimostra che il sistema ora è auto- hosting), ma dipende in gran parte da te. Continua a verificare patch, patch del kernel, librerie e strumenti GNU di base e ricostruzione fino ad arrivare alle versioni moderne.
Questo è quando hai un sistema operativo e un compilatore di base affidabili che possono essere utilizzati per creare software moderno. A quel punto, puoi seguire, ad esempio, le guide di Linux From Scratch per creare un sistema in grado di svolgere attività utili .
In nessun caso il sistema "compilatore" potrà mai essere collegato a una rete in alcun modo (incluso come VM su un host in rete); rischieresti di penetrare attraverso qualsiasi componente abilitato alla rete incluso il kernel. Se sei preoccupato per un attacco del compilatore Thompson , dovresti aspettarti che anche qualsiasi host di macchine virtuali possa essere compromesso. Usa sneakernet per ottenere codice sorgente e binari dall'host fisico su cui stai compilando le cose. Aspettatevi problemi nell'ottenere e spegnere i file dal sistema almeno prima di arrivare al punto in cui è stato implementato il supporto di archiviazione di massa USB. Se siete veramente paranoico, listati di codice sorgente di stampa e digitare a mano (e la speranza che il driver di stampa e la stampante non hanno un codice simile a loro) o leggi il codice sul monitor di un computer e digitalo in un altro computer fisicamente accanto ma non collegato ad esso.
Sì, ci vorrà molto tempo. Ma il vantaggio di questo approccio è che ogni passaggio è incrementale, il che significa che sarebbe molto più difficile far passare qualsiasi cosa maliziosa a meno che non venga introdotta molto gradualmente in un periodo di molte versioni; questo perché l'insieme delle modifiche ad ogni passaggio è relativamente piccolo e quindi molto più facile da guardare. Confronta il patchset con il log delle modifiche e assicurati di poter determinare esattamente quale voce del log delle modifiche corrisponde a ogni modifica del codice sorgente. Ancora una volta, ciò presuppone che tu abbia la possibilità (possibilmente attraverso qualcuno di cui ti fidi) di verificare che tali modifiche non siano state introdotte di nascosto nella base di codice, ma dovrebbe avvicinarti a un sistema fidato come un software, tranne- l'approccio del firmware può.