VPN клиент с отворен код: какво доказва кодът и какво не може
Публичното хранилище е доказателство за изходния код, а не за компилацията, която сте инсталирали, или за сървърите зад нея. Съпоставете изданието, после разширете прегледа.
Изходният код е публикуван, лицензът е чист, а връзката все още не може да бъде проверена от край до край. Тази разлика е обичайна и не е скандал. Публикуването на код прави един компонент проверим от хора, които не са били канени, а това е реално и необичайно свойство. От това не следва, че двоичният файл, който сте инсталирали, идва от този код, нито че нещо, което доставчикът управлява от другата страна, изобщо е било прегледано.
Отделете компонента от продукта
Четири неща могат да носят етикета „отворен код“ и рядко всички те са отворени. Клиентското приложение е това, което хората имат предвид. Реализацията на протокола под него е друг артефакт, понякога библиотека, а понякога код в дървото. Сървърният софтуер е трети, а собствената инфраструктура на доставчика, порталът за акаунти и инструментите за поддръжка са четвърти. Всяко от тях може да бъде отворено или затворено независимо.
Затова твърдения като „нашето приложение е с отворен код“ описват първия елемент и оставят останалите без отговор, което не е нечестност, а по-скоро подмяна на категорията. Полезният въпрос е кое хранилище, при кой етикет, отговаря на компонента, на който разчитате.
Това разграничение обяснява и защо два продукта с идентични отворени клиенти могат да предлагат много различни гаранции. Клиентът е частта, която можете да проверите; поведението на оператора е частта, която трябва да оцените по други начини.
Съпоставете инсталираната компилация с публикувания етикет
Хранилището е запис на намерение; двоичният файл на вашия диск е това, което се изпълнява. Затварянето на тази разлика е механично упражнение и започва с точно установяване какво е инсталирано, а не какво е рекламирала страницата за изтегляне.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
Метаданните на пакета ви казват версията и произхода, което изключва простия случай на остарял или подменен пакет. Те не ви казват как е компилиран този пакет, а точно на този въпрос съществуват възпроизводимите компилации, за да отговорят. Възпроизводими компилации позволяват на независима страна да прекомпилира от същия източник и да сравни резултата байт по байт, така че несъответствието става доказателство, а не подозрение.
Дори идеалното съвпадение доказва по-малко, отколкото хората се надяват. То показва, че артефактът отговаря на източника и на рецептата за компилация, но не че източникът е без дефекти и не че използваната верига от инструменти е била надеждна. И двете си струва да се знаят, но това са различни твърдения.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgОткъде обикновено започва симптомът
Оплакването, което поражда това четене, рядко е „кодът е затворен“. Обикновено е конкретно наблюдение: клиент, който се обажда на неочаквано място, версия, която се различава от бележките към изданието, или процес за поддръжка, който иска повече, отколкото тунелът би трябвало да изисква. Всяка от тези точки сочи към различен компонент.
Неочакваният мрежов трафик от клиента е въпрос на клиентския изходен код и може да получи отговор чрез четене на кодовия път, който отваря връзката. Несъответствието на версията е въпрос на пакетиране. Процес за поддръжка, който изисква документи за самоличност, е въпрос на системата за акаунти и никакъв одит на клиента няма да го реши.
Назоваването на компонента превръща смътното недоверие в конкретна проверка. На конкретна проверка може да се отговори, да се спори с нея или да се приключи. Алтернативата е постоянно подозрение без следваща стъпка.
Какво прегледът не може да достигне и какво да правим вместо това
Задържането на данни на сървърите на доставчика е извън обсега на клиента. Такова е и поведението на портал за плащания, на доставчик за проверка на измами или на бюро за поддръжка, което пази прикачени файлове. Преглед на клиента, разтеглен до „одитирахме услугата“, прави твърдение, което доказателствата не подкрепят.
Прочетете какво публикува операторът за задържане и заявки, отбележете датата и го третирайте като изявление на заинтересована страна, а не като измерване. Това е по-слаба форма на доказателство и изричното посочване на разликата е по-полезно, отколкото повишаването ѝ при преразказа.
След това използвайте това, което имате, като един от няколко входа: самоличността на инсталираното издание, поддържа ли се софтуерът, как е конфигуриран клиентът и какво казва операторът за собствените си системи. Отвореният код подсилва тази оценка в една точка. Той не заменя останалото.
Всяко твърдение за одит трябва винаги да назовава компонентите и версиите си. Ако един доклад не може да каже кое хранилище и коя компилация е прегледал, той описва намерение, а не продукт.