Один із можливих способів, хоча це потребуватиме дуже тривалий час на практиці, - це повернутися до коріння. Розробка 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 для створення системи, здатної виконувати корисні завдання.
Ні в якому разі система "компілятора" ніколи не може бути підключена до мережі будь-яким способом (у тому числі як VM на мережевому хості); ви ризикуєте проникнути через будь-який мережевий компонент, включаючи ядро. Якщо ви переживаєте за атаку компілятора Томпсона , вам доведеться сподіватися, що будь-який хостинг VM також може бути порушений. Використовуйте sneakernet, щоб отримати вихідний код і двійкові файли від фізичного хоста, на якому ви збираєте речі. Очікуйте проблем із ввімкненням та вимкненням файлів принаймні перед тим, як дістатися до точки, де реалізована підтримка масового зберігання USB. Якщо ви справді параноїк, надрукуйте списки вихідного коду та введіть їх вручну (і сподівайтеся, що драйвер принтера та принтер не мають у них подібного коду) або прочитати код на одному моніторі комп'ютера та ввести його на інший комп'ютер фізично поруч із ним, але не підключений до нього.
Так, це займе багато часу. Але перевага такого підходу полягає в тому, що кожен крок є поступовим, це означає, що будь-яке шкідливе значення буде набагато складніше, якщо це не буде поступово впроваджено протягом багатьох версій; це тому, що набір змін на кожному кроці порівняно невеликий і, таким чином, набагато простіше переглядати. Порівняйте набір патчів із журналом змін і переконайтеся, що ви можете точно визначити, який запис журналу змін відповідає кожній зміні вихідного коду. Знову ж таки, це передбачає, що у вас є можливість (можливо, через когось, кому ви довіряєте) переконатися, що такі зміни не проникли в кодову базу даних, але це повинно наблизити вас до настільки ж надійної системи, як лише програмне забезпечення, за винятком, підхід прошивки може.