Klient VPN o otwartym kodzie: co kod dowodzi, a czego nie
Publiczne repozytorium jest dowodem dotyczącym kodu źródłowego, a nie zbudowanej wersji, którą zainstalowałeś, ani serwerów za nią. Dopasuj wydanie, a potem poszerz przegląd.
Kod źródłowy jest opublikowany, licencja czysta, a połączenia nadal nie da się zweryfikować od końca do końca. Ta luka jest zwyczajna i nie jest skandalem. Publikacja kodu czyni jeden komponent sprawdzalnym przez ludzi, których nie zaproszono, a to realna i niezwykła właściwość. Nie wynika z tego, że zainstalowany plik binarny pochodzi z tego kodu, ani że cokolwiek, co dostawca uruchamia po drugiej stronie, zostało w ogóle przejrzane.
Oddziel komponent od produktu
Cztery rzeczy mogą nosić etykietę otwartego kodu i rzadko wszystkie są otwarte. Aplikacja kliencka to ta, o której ludzie mówią. Implementacja protokołu pod nią to inny artefakt, czasem biblioteka, a czasem kod w drzewie. Oprogramowanie serwera to trzecia, a własna infrastruktura dostawcy, portal konta i narzędzia wsparcia to czwarta. Każde z nich może być otwarte lub zamknięte niezależnie.
Dlatego stwierdzenia typu "nasza aplikacja jest open source" opisują pierwszą pozycję i pozostawiają resztę bez odpowiedzi, co nie jest nieuczciwością, lecz raczej przesunięciem kategorii. Użyteczne pytanie brzmi, które repozytorium, na którym tagu, odpowiada komponentowi, na którym polegasz.
Ta różnica wyjaśnia też, dlaczego dwa produkty z identycznymi otwartymi klientami mogą oferować bardzo różne gwarancje. Klient to część, którą możesz sprawdzić; zachowanie operatora to część, którą musisz ocenić innymi środkami.
Dopasuj zainstalowaną kompilację do opublikowanego tagu
Repozytorium jest zapisem intencji; plik binarny na twoim dysku jest tym, co się wykonuje. Zamknięcie tej luki jest ćwiczeniem mechanicznym i zaczyna się od ustalenia, co dokładnie jest zainstalowane, a nie od tego, co reklamowała strona pobierania.
| 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 |
Metadane pakietu podają wersję i pochodzenie, co wyklucza trywialny przypadek nieaktualnego lub podmienionego pakietu. Nie mówią, jak ten pakiet skompilowano, a właśnie na to pytanie odpowiadają kompilacje odtwarzalne. Kompilacje odtwarzalne pozwalają niezależnej stronie przebudować z tego samego źródła i porównać wynik bajt po bajcie, tak że niezgodność staje się dowodem, a nie podejrzeniem.
Nawet idealna zgodność dowodzi mniej, niż ludzie mają nadzieję. Pokazuje, że artefakt odpowiada źródłu i recepturze kompilacji, a nie że źródło jest bez wad ani że użyty łańcuch narzędzi był godny zaufania. Jedno i drugie warto wiedzieć, ale to różne twierdzenia.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgGdzie zwykle zaczyna się objaw
Skarga, która wywołuje tę lekturę, rzadko brzmi "kod jest zamknięty". Zwykle to konkretna obserwacja: klient, który łączy się z nieoczekiwanym miejscem, wersja różna od noty wydania albo proces wsparcia proszący o więcej, niż tunel powinien potrzebować. Każdy z tych punktów wskazuje inny komponent.
Nieoczekiwany ruch sieciowy klienta to kwestia kodu źródłowego klienta i można na nią odpowiedzieć, czytając ścieżkę kodu, która otwiera połączenie. Rozbieżność wersji to kwestia pakowania. Proces wsparcia żądający dokumentów tożsamości to kwestia systemu kont, a żaden audyt klienta tego nie rozwiąże.
Nazwanie komponentu zamienia mgliste podejrzenie w konkretne sprawdzenie. Na konkretne sprawdzenie można odpowiedzieć, spierać się z nim albo je zamknąć. Alternatywą jest trwała podejrzliwość bez następnego kroku.
Czego przegląd nie może dosięgnąć i co zrobić zamiast tego
Przechowywanie na serwerach dostawcy jest poza zasięgiem klienta. Podobnie zachowanie portalu rozliczeniowego, dostawcy kontroli oszustw albo biura wsparcia, które zachowuje załączniki. Przegląd klienta rozciągnięty do "audytowaliśmy usługę" czyni twierdzenie, którego dowody nie wspierają.
Przeczytaj, co operator publikuje o przechowywaniu i żądaniach, odnotuj datę i traktuj to jako oświadczenie strony zainteresowanej, a nie pomiar. To słabsza forma dowodu, a wyraźne wskazanie różnicy jest użyteczniejsze niż podnoszenie jej rangi w opowieści.
Następnie użyj tego, co masz, jako jednego z kilku wejść: tożsamości zainstalowanego wydania, tego, czy oprogramowanie jest utrzymywane, konfiguracji klienta i tego, co operator mówi o własnych systemach. Otwarty kod wzmacnia tę ocenę w jednym punkcie. Nie zastępuje reszty.
Twierdzenie o audycie powinno zawsze wymieniać swoje komponenty i wersje. Jeśli raport nie potrafi powiedzieć, które repozytorium i którą kompilację zbadał, opisuje intencję, a nie produkt.