Client VPN de codi obert: què demostra el codi i què no pot demostrar
Un repositori públic és una prova sobre el codi font, no sobre la compilació que heu instal·lat ni sobre els servidors que hi ha al darrere. Feu coincidir la versió i després amplieu la revisió.
El codi font és publicat, la llicència és neta i la connexió encara no es pot verificar d’un extrem a l’altre. Aquest buit és normal i no és cap escàndol. Publicar el codi fa que un component sigui inspeccionable per persones que no hi van ser convidades, i això és una propietat real i poc habitual. Això no implica que el binari que heu instal·lat provingui d’aquell codi, ni que s’hagi revisat gens del que el proveïdor executa a l’altre costat.
Separeu el component del producte
Quatre coses poden portar l’etiqueta de codi obert, i poques vegades són obertes totes. L’aplicació client és la que la gent vol dir. La implementació del protocol que hi ha a sota és un altre artefacte, de vegades una biblioteca i de vegades codi dins de l’arbre. El programari del servidor és el tercer, i la infraestructura pròpia del proveïdor, el portal de compte i les eines de suport són el quart. Cadascun pot ser obert o tancat de manera independent.
Per tant, afirmacions com "la nostra aplicació és de codi obert" descriuen el primer element i deixen la resta sense tractar, cosa que no és deshonestedat sinó més aviat un lliscament de categoria. La pregunta útil és quin repositori, amb quina etiqueta, correspon al component en què confieu.
Aquesta distinció també explica per què dos productes amb clients oberts idèntics poden oferir garanties molt diferents. El client és la part que podeu comprovar; el comportament de l’operador és la part que heu d’avaluar per altres mitjans.
Feu coincidir la compilació instal·lada amb l’etiqueta publicada
Un repositori és un registre d’intencions; el binari del vostre disc és allò que s’executa. Tancar aquest buit és un exercici mecànic, i comença per identificar exactament què està instal·lat i no què anunciava la pàgina de descàrrega.
| 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 |
Les metadades del paquet us diuen la versió i l’origen, cosa que descarta el cas trivial d’un paquet obsolet o substituït. No us diuen com es va compilar aquell paquet, i precisament aquesta és la pregunta que les compilacions reproduïbles existeixen per respondre. Compilacions reproduïbles permeten que una part independent torni a compilar des de la mateixa font i compari la sortida byte a byte, de manera que una discrepància esdevé una prova i no un sospita.
Fins i tot una coincidència perfecta demostra menys del que la gent espera. Mostra que l’artefacte correspon a la font i a la recepta de compilació, no que la font estigui lliure de defectes ni que la cadena d’eines utilitzada fos fiable. Totes dues coses val la pena saber-les, però són afirmacions diferents.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgOn sol començar un símptoma
La queixa que origina aquesta lectura poques vegades és "el codi és tancat". Normalment és una observació concreta: un client que truca a un lloc inesperat, una versió que difereix de les notes de la versió, o un procés de suport que demana més del que el túnel hauria de necessitar. Cadascun d’aquests punts assenyala un component diferent.
El trànsit de xarxa inesperat del client és una qüestió del codi font del client, i es pot respondre llegint el camí de codi que obre la connexió. Una discrepància de versió és una qüestió d’empaquetatge. Un procés de suport que demana documents d’identitat és una qüestió del sistema de comptes, i cap auditoria del client ho resoldrà.
Anomenar el component converteix una desconfiança vaga en una comprovació concreta. Una comprovació concreta es pot respondre, discutir o tancar. L’alternativa és un sospita permanent sense cap pas següent.
Què no pot abastar la revisió i què fer en lloc d’això
La retenció als servidors del proveïdor queda fora de l’abast del client. També el comportament d’un portal de facturació, d’un proveïdor de verificació de fraus o d’un servei de suport que guarda adjunts. Una revisió del client que s’estira fins a "hem auditat el servei" fa una afirmació que les proves no sostenen.
Llegiu què publica l’operador sobre retenció i sol·licituds, anoteu la data i tracteu-ho com una declaració d’una part interessada i no com un mesurament. És una forma més feble de prova, i ser explícit sobre la diferència és més útil que elevar-ne la categoria en explicar-ho.
Després feu servir el que teniu com una entrada entre diverses: la identitat de la versió instal·lada, si el programari es manté, com està configurat el client i què diu l’operador sobre els seus propis sistemes. El codi obert enforteix aquesta avaluació en un punt. No substitueix la resta.
Una afirmació d’auditoria hauria d’anomenar sempre els seus components i versions. Si un informe no pot dir quin repositori i quina compilació ha examinat, descriu una intenció i no un producte.