Uma maneira possível, embora demorasse muito tempo na prática, seria voltar às raízes. O desenvolvimento do GNU começou em 1984, e a versão original do Minix (usada durante o desenvolvimento inicial do Linux para fins de inicialização) foi lançada em 1987.
Esta resposta inteira é baseada na sua premissa de que "[você] ou outras pessoas têm a capacidade de ler e entender o código-fonte quanto a falhas de segurança, para que o código-fonte seja examinado primeiro antes da compilação" e que você pode confiar no resultado dessa análise . Sem isso, essa resposta provavelmente é pior do que inútil, pois você estará gastando uma quantidade enorme de tempo sem absolutamente nenhum benefício.
Se você puder encontrar uma cópia do livro original do Minix com o código-fonte, poderá digitá-la no livro. Compile-o e, em seguida, use um descompilador diferente em um sistema diferente para verificar se o compilador gera a saída binária da linguagem de máquina esperada. (O código tem apenas 12.000 linhas, presumivelmente C, portanto, isso leva tempo, mas ainda está dentro do razoável, se você levar a sério esse projeto.) Você pode até escrever seu próprio desmontador; isso não deve ser muito difícil.
Pegue as versões mais antigas dos utilitários GNU em que você pode ter as mãos (como presumivelmente possuem menos código e menos dependências de bibliotecas externas), analise o código e construa-o para o Minix (isso pode levar algum trabalho; absolutamente querer evitar é fazer ajustes no código-fonte, porque isso tornará a adição de patches mais tarde propensa a erros) e passará por um ciclo semelhante de desmontagem-verificação para as ferramentas GNU. Nesse ponto, você confia no sistema operacional e na cadeia de ferramentas, portanto, você só precisa passar pelo código-fonte no conjunto de patches (qualquer coisa que não esteja no conjunto de patches já é confiável), mas as ferramentas ainda serão muito primitivas e grosseiras em comparação com o que você está usando para hoje. Não espere nada além da funcionalidade mais básica das ferramentas do sistema, por exemplo.Leia muitos XKCD.
Em algum momento, você terá um sistema que pode compilar e inicializar uma versão inicial do kernel Linux, como foi feito no início dos anos 90, quando o Linux começou a ganhar força entre os hackers. Eu sugiro migrar para o Linux nesse ponto (reconstruir as bibliotecas do sistema e o conjunto de ferramentas contra o Linux, criar o kernel do Linux, inicializar no Linux e, possivelmente, reconstruir o kernel do Linux e o conjunto de ferramentas GNU no Linux; o último prova que o sistema agora é auto- hospedagem), mas isso depende muito de você. Continue verificando as correções, corrigindo o kernel, as bibliotecas e as ferramentas básicas do GNU e reconstruindo até chegar às versões modernas.
É quando você tem um sistema operacional e um compilador básicos confiáveis que podem ser usados para criar software moderno. Até então, você pode seguir, por exemplo, os guias Linux From Scratch para criar um sistema capaz de executar tarefas úteis .
Em nenhum momento o sistema "compilador" pode ser conectado a uma rede de forma alguma (inclusive como uma VM em um host em rede); você arriscaria a penetração através de qualquer componente com capacidade de rede, incluindo o kernel. Se você estiver preocupado com um ataque do compilador Thompson , seria de esperar que qualquer host de VM também seja comprometido. Use o sneakernet para obter o código-fonte e os binários do host físico em que você está compilando as coisas. Espere problemas ao conectar e desconectar arquivos do sistema pelo menos antes de chegar ao ponto em que o suporte ao armazenamento em massa USB foi implementado. Se você é realmente paranóico, listagens de código fonte de impressão e digitá-los com a mão (e espero que o driver da impressora ea impressora não tem um código semelhante em -los) ou leia o código em um monitor de computador e digite-o em outro computador fisicamente próximo a, mas não conectado a ele.
Sim, isso levará muito tempo. Mas a vantagem dessa abordagem é que cada etapa é incremental, o que significa que seria muito mais difícil escapar qualquer coisa maliciosa, a menos que seja introduzida gradualmente durante um período de várias versões; isso porque o conjunto de alterações em cada etapa é comparativamente pequeno e, portanto, muito mais fácil de examinar. Compare o conjunto de patches com o changelog e verifique se você pode determinar exatamente qual entrada do changelog corresponde a cada alteração no código-fonte. Novamente, isso pressupõe que você tem a capacidade (possivelmente através de alguém em quem confia) de verificar se essas alterações não foram infiltradas na base de código, mas deve aproximar você de um sistema confiável como um software somente, exceto: abordagem de firmware pode.