Cliente VPN de código aberto: que demostra o código e que non pode
Un repositorio público é unha proba sobre o código fonte, non sobre a compilación que instalou nin sobre os servidores que hai detrás. Emparexe a versión e despois amplíe a revisión.
O código fonte está publicado, a licenza está limpa e a conexión segue sen poder verificarse de extremo a extremo. Esa lagoa é normal e non é un escándalo. Publicar o código fai que un compoñente sexa inspeccionable por persoas que non foron invitadas, e iso é unha propiedade real e pouco habitual. Diso non se segue que o binario que instalou proveña dese código, nin que se revisase en absoluto nada do que o provedor opera na outra banda.
Separe o compoñente do produto
Catro cousas poden levar a etiqueta de código aberto, e raramente están todas abertas. A aplicación cliente é a que a xente quere dicir. A implementación do protocolo que hai debaixo é outro artefacto, ás veces unha biblioteca e ás veces código dentro da árbore. O software do servidor é o terceiro, e a infraestrutura propia do provedor, o portal de conta e as ferramentas de soporte son o cuarto. Cada un pode ser aberto ou pechado de forma independente.
Polo tanto, afirmacións como "a nosa aplicación é de código aberto" describen o primeiro elemento e deixan o resto sen abordar, o que non é deshonestidade senón máis ben un deslizamento de categoría. A pregunta útil é que repositorio, en que etiqueta, corresponde ao compoñente no que confía.
Esa distinción tamén explica por que dous produtos con clientes abertos idénticos poden ofrecer garantías moi distintas. O cliente é a parte que pode comprobar; o comportamento do operador é a parte que debe avaliar por outros medios.
Emparexe a compilación instalada coa etiqueta publicada
Un repositorio é un rexistro de intencións; o binario do seu disco é o que se executa. Pechar esa fenda é un exercicio mecánico, e comeza por identificar exactamente que está instalado e non que anunciaba a páxina de descarga.
| 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 |
Os metadatos do paquete dinlle a versión e a orixe, o que descarta o caso trivial dun paquete obsoleto ou substituído. Non lle din como se compilou ese paquete, e precisamente esa pregunta existen para responder as compilacións reproducibles. Compilacións reproducibles permiten que unha parte independente volva compilar desde a mesma fonte e compare a saída byte a byte, de xeito que unha discrepancia se converte en proba e non en sospeita.
Incluso unha coincidencia perfecta demostra menos do que a xente espera. Mostra que o artefacto corresponde á fonte e á receita de compilación, non que a fonte estea libre de defectos nin que a cadea de ferramentas utilizada fose fiable. Ambas as dúas cousas merecen saberse, pero son afirmacións distintas.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgOnde adoita comezar un síntoma
A queixa que motiva esta lectura raramente é "o código está pechado". Normalmente é unha observación concreta: un cliente que chama a un lugar inesperado, unha versión que difire das notas da versión, ou un proceso de soporte que pide máis do que o túnel debería necesitar. Cada un deses puntos sinala un compoñente distinto.
O tráfico de rede inesperado do cliente é unha cuestión do código fonte do cliente, e pódese responder lendo a ruta de código que abre a conexión. Unha discrepancia de versión é unha cuestión de empaquetado. Un proceso de soporte que solicita documentos de identidade é unha cuestión do sistema de contas, e ningunha auditoría do cliente o resolverá.
Nomear o compoñente converte unha desconfianza vaga nunha comprobación concreta. Unha comprobación concreta pódese responder, discutir ou pechar. A alternativa é unha sospeita permanente sen paso seguinte.
Que non alcanza a revisión e que facer no seu lugar
A retención nos servidores do provedor queda fóra do alcance do cliente. Tamén o comportamento dun portal de facturación, dun provedor de verificación de fraude ou dun servizo de soporte que garda anexos. Unha revisión do cliente que se estira ata "auditamos o servizo" fai unha afirmación que as probas non apoian.
Lea o que o operador publica sobre retención e solicitudes, anote a data e tráteo como unha declaración dunha parte interesada e non como unha medición. É unha forma máis feble de proba, e ser explícito sobre a diferenza é máis útil que elevala ao contalo de novo.
Despois use o que ten como unha entrada entre varias: a identidade da versión instalada, se o software se mantén, como está configurado o cliente e que di o operador sobre os seus propios sistemas. O código aberto reforza esa avaliación nun punto. Non substitúe o resto.
Toda afirmación de auditoría debería nomear os seus compoñentes e versións. Se un informe non pode dicir que repositorio e que compilación examinou, describe unha intención e non un produto.