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

Відокремте компонент від продукту

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

Тому твердження на кшталт "наш застосунок з відкритим кодом" описують перший пункт і залишають решту без відповіді, що не так нечесність, як зсув категорії. Корисне питання: який репозиторій, на якому тегу, відповідає компоненту, на який ви покладаєтеся.

Ця відмінність також пояснює, чому два продукти з однаковими відкритими клієнтами можуть давати дуже різні гарантії. Клієнт — це частина, яку ви можете перевірити; поведінка оператора — частина, яку треба оцінювати іншими засобами.

Зіставте встановлену збірку з опублікованим тегом

Репозиторій — це запис про намір; бінарний файл на вашому диску — те, що виконується. Закрити цю прогалину — механічна вправа, і вона починається з точного визначення того, що встановлено, а не того, що обіцяла сторінка завантаження.

ComponentWhat inspection can showWhat it leaves untouched
Client sourceHow profiles, packets and optional telemetry are handledWhether the shipped binary matches that source
Build outputWhether a declared build reproduces a matching artefactWhether the source is correct or the toolchain is clean
Server softwareWhat the implementation is capable of loggingWhat the operator actually configures and retains
Account and support systemsAlmost nothing, unless they are separately publishedEverything about how those systems treat your data

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

Навіть ідеальний збіг доводить менше, ніж люди сподіваються. Він показує, що артефакт відповідає джерелу та рецепту збірки, але не те, що джерело без дефектів, і не те, що використаний ланцюг інструментів був надійним. І те й те варто знати, але це різні твердження.

dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg

Звідки зазвичай починається симптом

Скарга, що спричиняє це читання, рідко звучить як "код закритий". Зазвичай це конкретне спостереження: клієнт, який звертається кудись несподівано, версія, що відрізняється від приміток до випуску, або процес підтримки, що просить більше, ніж потрібно тунелю. Кожен із цих пунктів указує на інший компонент.

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

Називання компонента перетворює неясну недовіру на конкретну перевірку. На конкретну перевірку можна відповісти, з нею можна сперечатися або її закрити. Альтернатива — постійна підозра без наступного кроку.

Чого перевірка не може сягнути й що робити натомість

Зберігання на серверах провайдера — поза межами клієнта. Так само поведінка платіжного порталу, постачальника перевірки на шахрайство чи служби підтримки, що зберігає вкладення. Перевірка клієнта, розтягнута до "ми провели аудит сервісу", робить твердження, яке докази не підтримують.

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

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

Твердження про аудит завжди має називати свої компоненти й версії. Якщо звіт не може сказати, який репозиторій і яку збірку він дослідив, він описує намір, а не продукт.

Схожі статті