Основна проблема: Поза двійковим кодом, перевірка довіри

Коли більшість людей завантажують Bitcoin Core, їхня взаємодія з системою збирання закінчується за кілька кліків. Вони беруть виконуваний бінарний файл програмного забезпечення, перевіряють підпис (сподіваємося!), і починають запускати ноду Bitcoin. Те, що вони відразу бачать, — це запущене програмне забезпечення. Те, чого вони не бачать, — це система збирання й масштабні процеси, які створили це програмне забезпечення. Система збирання, що відображає принципи біткоїна — децентралізацію, прозорість і перевірюваність.

За тим завантаженням стоять роки інженерної роботи, створеної для відповіді на просте запитання: «Чому хтось має довіряти цьому програмному забезпеченню?» Відповідь така: вам не варто цього робити. Ви маєте змогу перевіряти.

У час, коли атаки на ланцюг постачання програмного забезпечення потрапляють у світові заголовки — від скомпрометованих npm-пакетів, до вбудованих зрадницьких бібліотек, підступних CI-серверів — процес збирання Bitcoin Core є тихим проєктом дисципліни. Його методи можуть здаватися повільними й складними порівняно з безперешкодною зручністю «push to deploy», але в цьому й суть. Безпека не буває зручною.

Щоб зрозуміти систему збирання Bitcoin Core, ми маємо розуміти:

• Філософію системи збирання Bitcoin Core
• Відтворювані збірки
• Мінімізацію залежностей
• Відсутність автооновлень
• Безперервну інтеграцію
• Постійне адаптування

Філософія системи збирання Bitcoin Core

Коли йдеться про децентралізацію біткоїна, більшість людей фокусуються на майнерах, нодах і розробниках. Але децентралізація не зупиняється на учасниках протоколу. Вона поширюється на спосіб, яким саме програмне забезпечення створюють і розповсюджують.

Один із принципів у біткоїн-екосистемі — «не довіряй, перевіряй». Запуск власної ноди — це дія перевірки: звіряння кожного блоку й транзакції з правилами консенсусу. Але сама система збирання дає вам ще одну можливість перевіряти — на рівні програмного забезпечення. Біткоїн — це гроші без довірених посередників, і Bitcoin Core прагне бути програмним забезпеченням без довірених збирачів. Система збирання докладає значних зусиль, щоб будь-хто, де б він не був, міг незалежно відтворити абсолютно ті самі бінарні файли, які з’являються на вебсайті bitcoincore.org.

Ця філософія бере початок із есе Кена Томпсона 1984 року Reflections on Trusting Trust («Роздуми про довіру до довіри»), яке попереджало, що навіть чистий на вигляд вихідний код не можна вважати надійним, якщо компілятор, що зібрав це програмне забезпечення, сам був скомпрометований. Розробники Bitcoin взяли цей урок близько до серця. За словами дописувача Bitcoin Core Майкла Форда (fanquake):

«Відтворювані збірки критично важливі, бо жоден користувач нашого програмного забезпечення не має бути змушений довіряти тому, що всередині є саме тим, що ми стверджуємо. Це завжди має бути незалежно перевірюваним.»

Заява, яка є водночас технічною метою і частиною біткоїн-етосу.

У світі безпеки люди говорять про «поверхні атак». Система збирання Bitcoin Core розглядає сам процес збирання як поверхню атаки, яку потрібно мінімізувати й захистити.

Відтворювані збірки: перевірка аж донизу

Процес створення релізу Bitcoin Core починається з відкритого вихідного коду на GitHub. Кожна зміна є публічною. Кожен pull request переглядають. Але шлях від читабельного коду до виконуваного бінарного програмного забезпечення включає компілятори, сторонні бібліотеки та операційні системи, які самі по собі є потенційними векторами підробки, бекдорів або помилок.

«Довірені треті сторони — це діри в безпеці» – Нік Сабо (2001)

Щоб відповісти на ці занепокоєння, архітектор Bitcoin Core побудував конвеєр процесу збирання з використанням Guix — менеджера пакетів, створеного для створення відтворюваних, детермінованих середовищ програмного забезпечення.

Коли новий реліз Bitcoin Core позначають (tag), кілька незалежних дописувачів збирають бінарні файли з нуля, використовуючи Guix. Кожен збирач працює в ізольованому середовищі, яке гарантує однакові toolchain (набори інструментів), версії компіляторів і системні бібліотеки. Якщо всі збирачі отримують ідентичні біт-в-біт результати, вони знають, що збірка детермінована.

Після цього дописувачі криптографічно підписують отримані бінарні файли й публікують ці підписи в окремому репозиторії GitHub ‘guix.sigs’, який перераховує ці атестації для кожного релізу Bitcoin Core. Деякі збирачі — розробники Bitcoin Core, але це не вимога: процес атестації відкритий для будь-кого з публіки. Насправді, багато людей, які не є авторами коду, регулярно роблять внесок підписами.

Цей процес відомий як відтворювані збірки, і він є протиотрутою до «довіри до довіри» Томпсона. Це означає, що будь-хто може взяти відкритий вихідний код, те саме середовище Guix, і незалежно підтвердити, що офіційний бінарний файл відповідає тому, що вони зібрали самі. Хоча відтворювані збірки можуть підтвердити, що програмне забезпечення є справжнім відображенням вихідного коду програмного забезпечення, коректність самого програмного забезпечення лишається на процесах навколо ретельного тестування та code review (перегляду коду).

Більшість людей ніколи не виконують повну компіляцію або не перевіряють маніфести Guix, чи не порівнюють хеші збірки. Їм це не потрібно. Сам факт наявності цієї інфраструктури та людей, які її підтримують, дає кожному користувачу основу для заслуженої впевненості.

Офіційні бінарні файли на bitcoincore.org — це не просто «зроблено тими, хто підтримує Bitcoin Core». Це перетин результатів десятків незалежних збирачів. Те, що ви зрештою завантажуєте, — це те, що зібрали й перевірили автентичність усі інші.

Це перевірка аж донизу.

Мінімізація залежностей: менше того, кому треба довіряти

Відтворюваність — це одна сторона рівняння. Друга — мінімізувати те, що потрібно відтворювати. Код Bitcoin Core — не єдиний код, який виконується під час запуску Bitcoin Core. Bitcoin Core також покладається на зовнішній, сторонній код і бібліотеки, щоб пришвидшити розробку та продуктивність.

Протягом останнього десятиліття розробники Bitcoin Core послідовно прибирали ці непотрібні й інколи проблемні сторонні залежності, як-от OpenSSL і MiniUPnP. Незалежно від того, чи це зовнішня бібліотека або набір інструментів, такі залежності додають складності або підмішують приховані припущення. Проєкти на кшталт Boost і Libevent, які колись були невід’ємними частинами кодової бази Core, поступово виводять з використання або замінюють простішими, самодостатніми альтернативами.

Чому? Бо кожна успадкована залежність — це потенційний ризик ланцюга постачання. Це більше коду, який ви не писали, не можете повністю аудити й не здатні повністю контролювати. Зменшення залежностей робить систему збирання легшою, безпечнішою та простішою для перевірки.

Нещодавно Brink висвітлив цей напрям у своєму блозі «Minimizing Dependencies» [1], зазначивши, що це не лише питання простоти — це про збереження безпеки й автономії проєкту. Кожна видалена залежність — це менше зовнішніх сторін, яким проєкт має довіряти, і менше потенціалу для бекдору.

Належна остаточна мета — отримати повністю статичні бінарні файли: виконувані файли, які містять усе необхідне для запуску, без будь-яких динамічних або runtime-залежностей. Така самодостатність означає, що немає потреби покладатися на зовнішні бібліотеки, які можуть відрізнятися між однією операційною системою та іншою.

У світі, де більшість програмного забезпечення стає важчим і більше залежить від централізованих екосистем пакетів, Bitcoin Core рухається в протилежному напрямку: до мінімалізму та незалежності.

Відсутність автооновлень

У більшості сучасного програмного забезпечення користувачів убезпечують від рішень, до якої версії оновлювати, або навіть від рішень щодо того, чи оновлювати програмне забезпечення взагалі. Ви встановлюєте застосунок, і він тихо й автоматично оновлюється до останніх версій у фоновому режимі. Хоча це зручно, це суперечить філософії Bitcoin Core.

Bitcoin Core ніколи не включав автоматичні оновлення, і розробники заявили, що не включатимуть. Автоматичні оновлення концентрують владу. Вони створюють єдину групу, яка може проштовхувати (потенційно зловмисний) код на кожну ноду в мережі. Це саме той тип централізованого контролю, якого біткоїн створювали уникати. Потрібно, щоб користувачі вручну завантажували, перевіряли та встановлювали нові версії — так Bitcoin Core підсилює індивідуальну відповідальність і перевірювану згоду.

Система збирання та відсутність автооновлень — це дві половини одного принципу. Лише виконавець ноди вирішує, що запускати, і може перевірити, що програмне забезпечення, яке запущено, є автентичним.

Безперервна інтеграція: рухайся повільніше та виправляй

У Силіконовій долині безперервна інтеграція та безперервне розгортання (CI/CD) — це ознака гнучкої розробки програмного забезпечення. Відправляй швидко. Ітеруй швидше. Нехай автоматизація робить решту.

Bitcoin Core обирає інший підхід. Його системи CI існують не для прискорення розгортання, а для захисту цілісності. Автоматизовані збірки перевіряють узгодженість на різних платформах. Система збирання Bitcoin Core розроблена так, щоб бути якомога менш залежною від апаратного забезпечення та операційних систем. Проєкт може збирати бінарні файли для Linux, macOS і Windows, а також для кількох архітектур, зокрема x86_64, aarch64 (ARM) і навіть riscv64. Система безперервної інтеграції забезпечує сумісність і цілісність програмного забезпечення, виконуючи сотні тестів для кожної запропонованої зміни.

Результатом є культура, де «безперервна інтеграція» означає безперервне тестування, перевірку та безпеку, а не безперервні інновації.

Рухайся повільніше та виправляй речі.

Постійне адаптування: Ми вже закінчили?

Система збирання не є статичною. Розробники продовжують її вдосконалювати, зменшуючи залежності, покращуючи збірки для різних архітектур і досліджуючи майбутнє повністю статичної збірки без жодних runtime-залежностей.

Хоча система збирання Bitcoin Core прагне детермінованості, сама система збирання не може бути статичною. Світ, у якому вона працює, постійно змінюється. Операційні системи, компілятори, бібліотеки та архітектури апаратного забезпечення — усе це змінюється. Кожен новий реліз macOS або glibc, кожне скасування (deprecation) прапорця компілятора, або поява нової CPU-архітектури створює тонкі несумісності, які потрібно вирішувати. Система збирання, що стояла б на місці, з часом перестала б збирати взагалі.

Парадокс відтворюваних збірок полягає в тому, що вони потребують постійного розвитку, щоб залишатися відтворюваними. Розробники мають постійно фіксувати версії (pin), патчити, а інколи й замінювати toolchains, щоб зберігати детермінованість на тлі руху змін. Підтримання цього балансу між стабільністю та адаптивністю є частиною постійної стійкості біткоїна.

Отримайте свій примірник The Core Issue вже сьогодні!

Не пропустіть свій шанс стати власником The Core Issue — з матеріалами, написаними багатьма Core Developer’ами, які пояснюють проєкти, над якими вони працюють самі!

Цей матеріал — лист від редактора, який представлено в останньому Print-випуску Bitcoin Magazine, The Core Issue. Ми публікуємо його тут як ранній огляд ідей, що розглядаються в усьому повному випуску.

[1]