Cliente VPN de código aberto: o que o código prova e o que não pode

O código-fonte está publicado, a licença está limpa, e a conexão continua sem poder ser verificada de ponta a ponta. Essa lacuna é comum e não é um escândalo. Publicar o código torna um componente inspecionável por pessoas que não foram convidadas, e isso é uma propriedade real e incomum. Daí não se segue que o binário que instalou venha desse código, nem que algo que o provedor opera do outro lado tenha sido examinado.

Separe o componente do produto

Quatro coisas podem carregar o rótulo de código aberto, e raramente estão todas abertas. A aplicação cliente é o que as pessoas querem dizer. A implementação do protocolo por baixo é outro artefato, às vezes uma biblioteca e às vezes código dentro da árvore. O software do servidor é o terceiro, e a infraestrutura do próprio provedor, o portal da conta e as ferramentas de suporte são o quarto. Cada um pode estar aberto ou fechado de forma independente.

Portanto, afirmações como "a nossa aplicação é de código aberto" descrevem o primeiro item e deixam o resto sem resposta, o que não é desonestidade mas antes um deslizamento de categoria. A pergunta útil é qual repositório, em qual etiqueta, corresponde ao componente em que confia.

Essa distinção também explica por que dois produtos com clientes abertos idênticos podem oferecer garantias muito diferentes. O cliente é a parte que pode verificar; o comportamento do operador é a parte que tem de avaliar por outros meios.

Confira a compilação instalada com a etiqueta publicada

Um repositório é um registo de intenção; o binário no seu disco é o que corre. Fechar essa lacuna é um exercício mecânico, e começa por identificar exatamente o que está instalado, e não o que a página de descarga anunciava.

Os metadados do pacote dizem-lhe a versão e a origem, o que exclui o caso trivial de um pacote obsoleto ou substituído. Não dizem como esse pacote foi compilado, e é precisamente a essa pergunta que as compilações reproduzíveis existem para responder. Compilações reproduzíveis permitem que uma parte independente reconstrua a partir da mesma fonte e compare a saída byte a byte, de modo que uma discrepância se torne prova em vez de suspeita.

Mesmo uma correspondência perfeita prova menos do que as pessoas esperam. Mostra que o artefato corresponde à fonte e à receita de compilação, não que a fonte esteja livre de defeitos nem que a cadeia de ferramentas usada fosse fiável. Ambas as coisas merecem ser conhecidas, mas são afirmações diferentes.

dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg

Onde um sintoma costuma começar

A queixa que origina esta leitura raramente é "o código é fechado". Normalmente é uma observação concreta: um cliente que contacta um lugar inesperado, uma versão que difere das notas de lançamento, ou um processo de suporte que pede mais do que o túnel deveria precisar. Cada um desses pontos aponta para um componente diferente.

O tráfego de rede inesperado do cliente é uma questão de código-fonte do cliente, e pode ser respondida lendo o caminho de código que abre a conexão. Uma discrepância de versão é uma questão de empacotamento. Um processo de suporte que pede documentos de identidade é uma questão do sistema de contas, e nenhuma auditoria do cliente o resolverá.

Nomear o componente transforma uma desconfiança vaga numa verificação concreta. Uma verificação concreta pode ser respondida, discutida ou encerrada. A alternativa é uma suspeita permanente sem passo seguinte.

O que a revisão não alcança e o que fazer em vez disso

A retenção nos servidores do provedor está fora do alcance do cliente. Também o comportamento de um portal de faturação, de um fornecedor de verificação de fraude ou de um serviço de suporte que guarda anexos. Uma revisão do cliente esticada até "auditámos o serviço" faz uma afirmação que as provas não sustentam.

Leia o que o operador publica sobre retenção e pedidos, anote a data e trate-o como uma declaração de uma parte interessada e não como uma medição. É uma forma mais fraca de prova, e ser explícito sobre a diferença é mais útil do que elevá-la ao recontar.

Depois use o que tem como uma entrada entre várias: a identidade da versão instalada, se o software é mantido, como está configurado o cliente e o que o operador diz sobre os seus próprios sistemas. O código aberto reforça essa avaliação num ponto. Não substitui o resto.

Uma afirmação de auditoria deve sempre nomear os seus componentes e versões. Se um relatório não consegue dizer que repositório e que compilação examinou, descreve uma intenção e não um produto.