Reproducible Firmware Build — сборка, при которой одинаковые исходный код, среда и инструкции дают побайтово одинаковые, заранее определённые результаты. Необходимо указать версию, модель устройства и область сравнения, особенно если выпуск содержит дополнительную подпись.
Утверждение относится к определённому результату, например образу прошивки, а не автоматически к каждому файлу или журналу. Одинаковой работы программы недостаточно: проверка ищет одинаковые байты, обычно с помощью криптографического хеша. Открытый исходный код без повторяемой сборки сам по себе не подтверждает эту связь с выпущенным бинарным файлом. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Зафиксируйте точный коммит, зависимости и их версии, компилятор, параметры сборки, значимые переменные среды и целевую модель. Одного названия проекта или изменяющейся ветки недостаточно. Информацию, необходимую для повторения, следует публиковать или записывать при сборке; иначе надёжно оценить различие невозможно. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Компилятор может записать путь к рабочему каталогу в отладочную информацию. Тогда один и тот же исходный код в двух каталогах даст разные файлы. Путь можно задать заранее или нормализовать поддерживаемым способом. Такое правило должно входить в рецепт; удаление неизвестных различий задним числом обесценит проверку. [Reproducible Builds — Build paths]
Действительная подпись связывает выпуск с соответствующим ключом подписи в рамках данной модели доверия. Независимая сборка проверяет связь между исходниками и бинарным результатом. Официальный подписанный файл может содержать данные, которых нет в локальной неподписанной сборке. Тогда простое сравнение файлов целиком может оказаться неверным тестом заявленной воспроизводимости. [Trezor — Reproducible build verification]
Документация Trezor задаёт выбор версии и модели, сборку образа в определённой среде и сравнение с официальным выпуском. Перед сравнением она описывает обнуление точно указанных полей подписи; в старых форматах также отличаются заголовки. Структура зависит от модели и версии. Поэтому процедуру для одного образа нельзя вслепую применять к другому, а проверку исходной подписи необходимо проводить отдельно. [Trezor — Reproducible build verification]
Сначала проверьте совпадение ревизии, модели, варианта прошивки, зависимостей и заявленных преобразований образа. Сохраните исходные файлы и запись различий. Причиной может быть ошибка рецепта или среды, а также изменение распространяемого бинарного файла; само несовпадение причину не определяет. Не объявляйте результат проверенным, пока различие не объяснено и проверка не повторена. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Ошибочный или вредоносный исходный код может быть полностью воспроизводимым. Общий недоверенный компилятор способен вставить одинаковое изменение во все результаты; повторное использование того же инструмента не является независимым аудитом компилятора. Закрытые бинарные части ограничивают то, что можно пересобрать из доступных исходников. Совпадение файлов также не проверяет подлинность оборудования или то, что действительно загружено в конкретное устройство. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Полезная запись указывает, кто выполнял сборку, из какого коммита, по какому рецепту, для какой модели и какие файлы сравнивал. Добавьте алгоритм хеширования, результаты и точные исключения для данных подписи. Дополнительные независимые сборщики уменьшают зависимость от одного издателя, но не заменяют проверку исходников, процесса обновления и безопасности устройства в целом. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Одинаковый код, разная область подписи
Два сборщика используют одинаковые коммит, модель и среду. Их локальные образы имеют одинаковый SHA-256, а официальный подписанный образ — другой. Если документация точно определяет поля подписи, они сравнивают копии после предписанного преобразования. Совпадение тогда относится к содержимому, определённому таким способом; исходную подпись проверяют отдельно. Просто удалять другие различия нельзя.
Для полной картины прочитайте эту статью вместе с Hardware Wallet, Приватный ключ, Cold Storage, Secure Element. На эту статью также ссылаются COLDCARD RNG Incident (2026).
01Достаточно ли совпадения хеша, чтобы признать прошивку безопасной?+
Нет. Совпадение подтверждает результат конкретного сравнения, а не отсутствие ошибок. Вредоносные исходники или общий недоверенный компилятор могут создавать одинаковые результаты. Необходимо разделять проверку сборки, проверку исходников и доверие к устройству.
02Означает ли другой хеш подписанного выпуска автоматически атаку?+
Нет. Подписанный образ может иметь отличающиеся, заранее описанные поля подписи или заголовки. Сначала проверьте правильность версии, модели и процедуры сравнения. Однако необъяснённое несовпадение нельзя объявить успешной проверкой или обойти произвольным удалением байтов.