Client VPN a codice aperto: cosa dimostra il codice e cosa non può
Un repository pubblico è una prova sul codice sorgente, non sulla build che avete installato né sui server che ci sono dietro. Fate combaciare la versione, poi ampliate la revisione.
Il codice sorgente è pubblicato, la licenza è pulita, e la connessione resta non verificabile da un capo all’altro. Questo divario è normale e non è uno scandalo. Pubblicare il codice rende un componente ispezionabile da persone che non sono state invitate, ed è una proprietà reale e insolita. Da ciò non segue che il binario che avete installato provenga da quel codice, né che sia stato esaminato qualcosa che il fornitore gestisce dall’altra parte.
Separate il componente dal prodotto
Quattro cose possono portare l’etichetta open source, e raramente sono tutte aperte. L’applicazione client è quella che la gente intende. L’implementazione del protocollo sottostante è un altro artefatto, a volte una libreria e a volte codice dentro l’albero. Il software del server è il terzo, e l’infrastruttura del fornitore, il portale dell’account e gli strumenti di supporto sono il quarto. Ognuno può essere aperto o chiuso in modo indipendente.
Quindi affermazioni come "la nostra app è open source" descrivono il primo elemento e lasciano il resto senza risposta, il che non è disonestà ma piuttosto uno slittamento di categoria. La domanda utile è quale repository, a quale tag, corrisponda al componente su cui fate affidamento.
Questa distinzione spiega anche perché due prodotti con client aperti identici possano offrire garanzie molto diverse. Il client è la parte che potete controllare; il comportamento dell’operatore è la parte che dovete valutare con altri mezzi.
Fate combaciare la build installata con il tag pubblicato
Un repository è un registro di intenzioni; il binario sul vostro disco è ciò che viene eseguito. Chiudere quel divario è un esercizio meccanico, e comincia con l’identificare esattamente cosa è installato, non cosa pubblicizzava la pagina di download.
| 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 |
I metadati del pacchetto vi dicono la versione e l’origine, il che esclude il caso banale di un pacchetto obsoleto o sostituito. Non vi dicono come è stato compilato quel pacchetto, ed è proprio a questa domanda che esistono le build riproducibili. Build riproducibili permettono a una parte indipendente di ricostruire dalla stessa fonte e confrontare l’output byte per byte, così una discrepanza diventa prova e non sospetto.
Anche una corrispondenza perfetta dimostra meno di quanto la gente speri. Mostra che l’artefatto corrisponde alla fonte e alla ricetta di build, non che la fonte sia priva di difetti, né che la toolchain usata fosse affidabile. Entrambe le cose vale la pena saperle, ma sono affermazioni diverse.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgDove di solito inizia un sintomo
La lamentela che dà origine a questa lettura raramente è "il codice è chiuso". Di solito è un’osservazione concreta: un client che chiama da qualche parte in modo inatteso, una versione diversa dalle note di rilascio, o un processo di supporto che chiede più di quanto il tunnel dovrebbe richiedere. Ognuno di questi punti indica un componente diverso.
Il traffico di rete inatteso del client è una questione di codice sorgente del client, e si può rispondere leggendo il percorso di codice che apre la connessione. Una discrepanza di versione è una questione di impacchettamento. Un processo di supporto che chiede documenti d’identità è una questione di sistema degli account, e nessun audit del client lo risolverà.
Dare un nome al componente trasforma una diffidenza vaga in una verifica concreta. A una verifica concreta si può rispondere, si può discutere o si può chiudere. L’alternativa è un sospetto permanente senza passo successivo.
Cosa la revisione non può raggiungere, e cosa fare invece
La conservazione sui server del fornitore è fuori dalla portata del client. Lo è anche il comportamento di un portale di fatturazione, di un fornitore di controllo frodi o di un servizio di supporto che conserva gli allegati. Una revisione del client estesa fino a "abbiamo verificato il servizio" fa un’affermazione che le prove non sostengono.
Leggete ciò che l’operatore pubblica su conservazione e richieste, annotate la data, e trattatelo come una dichiarazione di una parte interessata e non come una misurazione. È una forma di prova più debole, ed essere espliciti sulla differenza è più utile che elevarla nel racconto.
Poi usate ciò che avete come uno tra diversi input: l’identità della versione installata, se il software è mantenuto, come è configurato il client e cosa dice l’operatore dei propri sistemi. Il codice aperto rafforza questa valutazione su un punto. Non sostituisce il resto.
Un’affermazione di audit dovrebbe sempre nominare i suoi componenti e le sue versioni. Se un rapporto non sa dire quale repository e quale build abbia esaminato, sta descrivendo un’intenzione e non un prodotto.