Один из возможных способов, хотя на практике это займет очень много времени, - вернуться к истокам. Разработка GNU началась в 1984 году, а оригинальная версия Minix (которая использовалась во время ранней разработки Linux для целей начальной загрузки) была выпущена в 1987 году.
Весь этот ответ основан на вашей предпосылке, что «[вы] или другие люди имеют возможность читать и понимать исходный код на наличие недостатков безопасности, поэтому исходный код будет проверен в первую очередь перед компиляцией», и что вы можете доверять результатам такого анализа , Без этого этот ответ, вероятно, хуже, чем бесполезный, так как вы будете тратить огромное количество времени на абсолютно никакой пользы.
Если вы можете найти копию оригинальной книги Minix с исходным кодом, вы можете ввести ее из книги. Скомпилируйте его, а затем используйте другой декомпилятор в другой системе, чтобы убедиться, что компилятор генерирует ожидаемый двоичный вывод машинного языка. (Код состоит всего из 12 000 строк, предположительно C, поэтому это занимает много времени, но все еще в пределах разумного, если вы серьезно относитесь к такому проекту.) Вы могли бы даже написать свой собственный дизассемблер; это не должно быть очень сложно.
Возьмите самые старые версии утилит GNU, которые вы можете получить (поскольку они, вероятно, имеют меньше кода и меньше зависимостей от внешних библиотек), просмотрите код, создайте его для Minix (хотя это может потребовать некоторой работы; абсолютно необходимо избегать внесения изменений в исходный код, потому что это сделает добавление патчей позже очень подверженным ошибкам) и пройдет аналогичный цикл дизассемблирования-проверки для инструментов GNU. В этот момент вы доверяете ОС и инструментальной цепочке, поэтому вам нужно только просмотреть исходный код в наборе патчей (все, что не входит в набор патчей, уже доверено), но инструменты все равно будут очень примитивными и грубыми по сравнению с тем, что вы используете на сегодня. Например, не ожидайте, что будет работать что-то большее, чем самые базовые функции системных инструментов.Читать много XKCD.
В какой-то момент у вас будет система, которая может скомпилировать и загрузить раннюю версию ядра Linux, так же, как это было сделано в начале 1990-х годов, когда Linux начал завоевывать популярность среди хакеров. В этот момент я бы предложил перейти на Linux (перестроить системные библиотеки и набор инструментов для Linux, собрать ядро Linux, загрузиться в Linux и, возможно, пересобрать ядро Linux и набор инструментов GNU в Linux; последнее доказывает, что система теперь является саморегулируемой хостинг), но это во многом зависит от вас. Проверяйте исправления, исправляйте ядро, библиотеки и базовые инструменты GNU и перестраивайте, пока не доберетесь до современных версий.
Тогда у вас есть надежная базовая ОС и компилятор, который можно использовать для создания современного программного обеспечения. К тому времени вы можете, например, следовать указаниям Linux From Scratch, чтобы создать систему, способную выполнять полезные задачи.
Ни при каких условиях система «компилятор» не может быть подключена к сети каким-либо образом (в том числе в качестве виртуальной машины на сетевом хосте); вы рискуете проникнуть через любой сетевой компонент, включая ядро. Если вас беспокоит атака компилятора Томпсона , вам следует ожидать, что любой виртуальный хост также может быть взломан. Используйте sneakernet для получения исходного кода и двоичных файлов с физического хоста, на котором вы компилируете вещи. Ожидайте проблем с получением файлов в системе и из системы, по крайней мере, до того момента, когда вы достигнете точки, где была реализована поддержка USB-накопителей. Если вы действительно параноик, источник печати списки кодов и введите их вручную (и надеемся , что драйвер принтера и принтер не похожий код в них) или прочитайте код на одном мониторе компьютера и введите его на другом компьютере, физически рядом с ним, но не подключенным к нему.
Да, это займет много времени. Но преимущество этого подхода состоит в том, что каждый шаг является инкрементным, а это означает, что было бы намного труднее проскользнуть через что-либо злонамеренное, если оно не будет постепенно внедрено в течение периода многих версий; Это связано с тем, что набор изменений на каждом шаге сравнительно невелик, и поэтому его намного легче просматривать. Сравните набор исправлений с журналом изменений и убедитесь, что вы можете точно определить, какая запись журнала изменений соответствует каждому изменению в исходном коде. Опять же, это предполагает, что у вас есть возможность (возможно, через кого-то, кому вы доверяете), чтобы убедиться, что такие изменения не проникли в кодовую базу, но это должно приблизить вас к такой надежной системе, как только программное обеспечение, за исключением Прошивка подойти может.