Основная проблема: Под бинарным кодом — проверка доверия

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

За этим скачиванием стоят годы инженерной работы, призванной ответить на простой вопрос: «Почему вообще кто-то должен доверять этому программному обеспечению?» Ответ: вам не должно быть нужно доверять. Вы должны иметь возможность проверять.

Во времена, когда атаки на цепочки поставок ПО попадают в мировые заголовки — из-за скомпрометированных npm-пакетов, внедренных бэкдоров в библиотеки, rogue CI-серверов — процесс сборки Bitcoin Core стоит как тихий проект дисциплины. Его методы могут казаться медленными и запутанными по сравнению с беспрепятственным удобством «нажми и разверни», но в этом и смысл. Безопасность не бывает удобной.

Чтобы понять сборочную систему Bitcoin Core, следует понять:

• Философия сборочной системы Bitcoin Core
• Воспроизводимые сборки
• Минимизация зависимостей
• Нет автО-обновлений
• Непрерывная интеграция
• Постоянная адаптация

Философия сборочной системы Bitcoin Core

Когда речь заходит о децентрализации Bitcoin, большинство людей фокусируются на майнерах, нодах и разработчиках. Но децентрализация не заканчивается участниками протокола. Она распространяется и на то, как само программное обеспечение создается и распространяется.

Один из принципов в экосистеме Bitcoin — «не доверяй, проверяй». Запуск собственной ноды — это акт проверки: вы сверяете каждый блок и каждую транзакцию с правилами консенсуса. Но сама сборочная система дает вам еще одну возможность проверять — уже на уровне программного обеспечения. Bitcoin — это деньги без доверенных посредников, и Bitcoin Core работает как программное обеспечение без доверенных создателей. Сборочная система предпринимает большие усилия, чтобы любой, где бы он ни находился, мог независимо воссоздать ровно те же бинарники, которые появляются на сайте bitcoincore.org.

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

«Воспроизводимые сборки критически важны, потому что ни один пользователь нашего ПО не должен быть вынужден доверять тому, что внутри — это то, что мы утверждаем. Это всегда должно быть независимо проверяемо.»

Заявление, которое одновременно является технической целью и частью «кредо» Bitcoin.

В мире безопасности люди говорят об «attack surfaces» (поверхностях атаки). Сборочная система Bitcoin Core рассматривает сам процесс сборки как поверхность атаки, которую нужно минимизировать и защищать.

Воспроизводимые сборки: проверка до самого дна

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

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

Чтобы справиться с этими опасениями, архитектор Bitcoin Core выстроил конвейер сборочного процесса с помощью Guix — менеджера пакетов, созданного для формирования воспроизводимых, детерминированных сред разработки ПО.

Когда новый релиз Bitcoin Core помечается тегом, несколько независимых соавторов собирают бинарники с нуля, используя Guix. Каждый сборщик работает в изолированной среде, которая гарантирует идентичные toolchains, версии компиляторов и системные библиотеки. Если все сборщики производят одинаковые на битовом уровне выходные данные, они знают, что сборка детерминирована.

Затем соавторы криптографически подписывают получившиеся бинарники и публикуют эти подписи в отдельном репозитории 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 был построен избегать. Требуя от пользователей вручную скачивать, проверять и устанавливать новые версии, Bitcoin Core усиливает индивидуальную ответственность и проверяемое согласие.

Сборочная система и отсутствие автО-обновлений — это две половины одного принципа. Только запускатель ноды решает, что запускать, и может проверить, что запускаемое программное обеспечение является подлинным.

Непрерывная интеграция: двигаться медленно и исправлять

В Силиконовой долине непрерывная интеграция и непрерывное развертывание (CI/CD) — отличительные признаки гибкой разработки ПО. Отправляйте быстро. Итераируйте быстрее. А остальное пусть делает автоматизация.

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

В результате формируется культура, где «непрерывная интеграция» означает непрерывное тестирование, проверку и безопасность, а не непрерывные инновации.

Двигаться медленно и исправлять.

Постоянная адаптация: мы уже закончили?

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

Хотя сборочная система Bitcoin Core стремится к детерминизму, сама сборочная система не может оставаться статичной. Мир, в котором она работает, постоянно меняется. Операционные системы, компиляторы, библиотеки и аппаратные архитектуры — все это изменяется. Каждое новое издание macOS или glibc, любое устаревание опции компилятора, или появление новой архитектуры CPU вносят тонкие несовместимости, которые нужно устранять. Сборочная система, которая стояла бы на месте, со временем перестала бы собираться вообще.

Парадокс воспроизводимых сборок в том, что для сохранения воспроизводимости требуется постоянная эволюция. Разработчики должны постоянно фиксировать, патчить и иногда заменять toolchains, чтобы сохранять детерминизм на фоне постоянных изменений. Поддержание этого баланса между стабильностью и адаптивностью — часть постоянной устойчивости Bitcoin.

Получите свой экземпляр The Core Issue уже сегодня!

Не упустите шанс стать владельцем The Core Issue — с материалами, написанными многими Core Developers, которые объясняют проекты, над которыми они работают сами!

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

[1]