Відтворювані збірки VPN-застосунків: що доводить збіг
Збіжна перезбірка пов'язує поширюваний двійковий файл із заявленим вихідним кодом і інструментами. Вона нічого не каже про VPN-сервіс за цим файлом чи про його журнали.
Відтворюваність — властивість ланцюга постачання: ті самі заявлені вхідні дані мають давати той самий артефакт. Для VPN-клієнта це твердження пов'язує завантажений вами інсталятор із вихідним кодом і набором інструментів, який може перезібрати кожен. Про сервіс, до якого підключається клієнт, воно не каже нічого.
Тому корисне питання вузьке й має відповідь. Чи публікує проєкт процедуру, і чи відповідає їй саме ваш артефакт?
Де збірка перестає бути детермінованою
Компілятори вбудовують позначки часу, абсолютні шляхи та імена хостів збирання, якщо їм не заборонити це робити. Архіви записують порядок файлів і час зміни, компонувальники змінюють вивід залежно від версії набору інструментів, а паралельне стиснення може переставляти блоки. Будь-що з цього змушує дві збірки одного вихідного коду відрізнятися в байтах, хоча нічого лиховісного не відбувається. Детермінізм вбудовується в збірку інженерно й ніколи не успадковується за замовчуванням.
Проєкт, що заявляє відтворюваність, мусить назвати застосовувану нормалізацію: фіксовані позначки часу, відображені шляхи, відсортовані записи архіву, закріплені версії компілятора й залежностей. Без цього списку розбіжність неможливо витлумачити, бо простір допустимих варіацій не визначений.
Заявлені вхідні дані теж мають бути повними. URL сховища без тегу — не ревізія, файл блокування без хешу — не набір залежностей, а скрипт збирання, що завантажує інструмент під час виконання, має вхід, який ніхто не може закріпити. Кожна прогалина згодом стає розбіжністю. Доповніть список, перш ніж щось порівнювати, бо неповний список не може зазнати невдачі так, щоб це щось означало.
| Input | How it drifts | What pins it |
|---|---|---|
| Source | Branch moves after release | Commit hash in the build metadata |
| Toolchain | Compiler patch level differs | Container image digest |
| Packaging | Archive order and mtimes vary | Normalised archive settings |
Що насправді перевіряє порівняння
Незалежна сторона перезбирає в заявленому середовищі й порівнює вивід з опублікованим артефактом. Побітова ідентичність — сильна форма; задокументований крок нормалізації, коли зафіксовану розбіжність обертають і результати потім збігаються, — слабша, але все ще корисна форма.
Порівняння стосується двійкового файлу. Підпис відповідає на інше питання: він пов'язує випуск із ключем, а ключ з особою, і проєкт може мати чинні підписи над артефактами, які ніхто не перезбирав. Дві перевірки додаються одна до одної, а не замінюють.
sha256sum wireguard-installer.msi gpg --verify wireguard-installer.msi.sig wireguard-installer.msi
Запустіть обидві перед встановленням і порівняйте хеш з опублікованим для того самого випуску й платформи. Хеш, що збігається зі сторінкою постачальника, доводить, що завантаження прибуло цілим; перезібраний двійковий файл, що збігається з опублікованим хешем постачальника, доводить дещо сильніше про те, як його створено.
Чому розбіжність не є доказом втручання
Більшість розбіжностей походить із вхідних даних, які ніхто не контролював. Інший випуск виправлення компілятора, шлях збирання, що протік у символи налагодження, локаль, яка змінила порядок сортування, або крок пакування, застосований після порівняння, — усі дають інший хеш, ніж чесна робота.
Тому розбіжність треба читати проти задокументованої процедури, перш ніж вона стане історією. Якщо процедура закріплює все, а різниця лишається нез'ясованою, це справжня знахідка, яку варто повідомити проєкту. Якщо процедура мовчить про пакування, різниця може бути цілком очікуваною.
Симетрія тут теж важлива: збіг не доводить, що вихідний код вільний від дефектів, а лише те, що двійковий файл йому відповідає. Добре перевірений код і відтворюваний код — різні властивості, і проєкт може мати одне без іншого.
Що твердження каже про сервіс за застосунком
Клієнт — це програма на вашому пристрої; сервіс — це сервери, системи облікових записів і політики зберігання в іншому місці. Відтворюваність обмежує перше й нічого не каже про друге, хоч би як ретельно перевіряли інсталятор.
Конфігурація кінцевої точки також може змінитися після встановлення — через віддалені налаштування або профіль, яким керує постачальник. Ці зміни надходять мережею і не охоплюються жодним хешем, обчисленим до підключення.
Прочитайте твердження в його реальному обсязі, а потім окремо перевірте сусіднє питання: що постачальник записує і за якої юрисдикції відповідає на запити. Перевірений двійковий файл і неперевірений сервіс можуть співіснувати, і саме цей випадок перевірка ланцюга постачання покликана зробити видимим, а не виправити.