Reproducible Firmware Build — це збирання, за якого однаковий вихідний код, середовище й інструкції дають наперед визначені, побайтово однакові результати. Необхідно вказати версію, модель пристрою та межі порівняння, особливо якщо випуск містить додатковий підпис.
Твердження стосується визначеного результату, наприклад образу прошивки, а не автоматично кожного файла чи журналу. Однакової поведінки програми недостатньо: перевірка шукає однакові байти, зазвичай за допомогою криптографічного хешу. Відкритий код без повторюваного збирання сам не доводить цей зв’язок з опублікованим бінарним файлом. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Зафіксуйте точний commit, залежності та їхні версії, компілятор, параметри збирання, важливі змінні середовища й цільову модель. Назви проєкту або рухомої гілки недостатньо. Інформацію для повторення потрібно опублікувати або записати під час збирання; інакше різницю неможливо надійно оцінити. [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]
Корисний запис указує, хто збирав, з якого commit, за яким рецептом, для якої моделі та які файли порівнював. Додайте алгоритм хешування, результати й точні винятки для даних підпису. Інші незалежні збирачі зменшують залежність від одного видавця, але не замінюють перевірку коду, процесу оновлення та безпеки пристрою загалом. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Однаковий код, різна область підпису
Двоє збирачів використовують однакові commit, модель і середовище. Їхні локальні образи мають однаковий SHA-256, а офіційний підписаний образ — інший. Якщо документація точно визначає поля підпису, вони порівнюють копії після передбаченого перетворення. Тоді збіг стосується саме визначеного вмісту; початковий підпис перевіряють окремо. Інші відмінності не можна просто видаляти.
Для повної картини прочитайте також Hardware Wallet, Приватний ключ, Cold Storage, Secure Element. На цю статтю також посилаються COLDCARD RNG Incident (2026).
01Чи достатньо збігу хешу, щоб вважати прошивку безпечною?+
Ні. Збіг доводить результат конкретного порівняння, а не відсутність помилок. Шкідливий код або спільний ненадійний компілятор можуть створювати однакові результати. Потрібно розрізняти перевірку збирання, аудит коду та довіру до пристрою.
02Чи означає інший хеш підписаного випуску автоматично атаку?+
Ні. Підписаний образ може мати інші, заздалегідь описані поля підпису чи заголовки. Спочатку перевірте правильну версію, модель і процедуру порівняння. Проте непояснену розбіжність не можна оголосити успішною перевіркою або обійти довільним видаленням байтів.