Em 2025-08-03, a SSP Wallet v1.25.0 publicou duas mudanças que, juntas, corrigem uma das mais antigas fraquezas silenciosas da distribuição de carteiras: você já não precisa confiar que o binário na loja é o binário do repositório. As releases agora são compiladas de forma determinista dentro do Docker e são assinadas com GPG. Qualquer um — não só nós, não só um auditor — pode recompilar a partir do código e verificar que o que obteve coincide, byte por byte, com o que publicamos.
Não confie, verifique — aplicado a binários de carteiras
A máxima bitcoin «não confie, verifique» costuma ser dita sobre transações. Aplica-se, com o mesmo peso, ao software que as assina. O código de uma carteira pode ser aberto e auditado e ainda assim enviar um binário comprometido, porque o caminho do código ao binário passa por um servidor de build, um passo de empacotamento, uma chave de assinatura e um upload à loja. Qualquer elo pode ser envenenado. Um token de CI vazado, um binário trocado no pipeline, um agente de build adulterado — nada disso toca o repositório público nem é visível em um git log.
A resposta defensiva a esse modelo de ameaça é que o próprio binário precisa ser verificável. Não «verificável porque prometemos». Reprodutível por estranhos.
Builds determinísticas com Docker
É isso que a v1.25.0 entrega. Cada release SSP agora é compilada dentro de um contêiner Docker com imagem base fixada, versões de toolchain fixadas e um ambiente totalmente isolado. A build não tem acesso à rede onde não precisa, não vaza o sistema de arquivos do host, não embute timestamps na saída nem caminhos específicos da máquina. A saída é uma função determinista das entradas.
A consequência prática: código fonte idêntico produz binários idênticos com checksums coincidentes. Pegue a tag, compile no contêiner documentado na sua máquina e você obterá o mesmo SHA-256 que nós. Se não obtiver, algo divergiu entre a tag e o binário publicado — e esse é exatamente o sinal que se quer, porque o único resultado honesto é «o binário bate com o código» ou «não bate».
Essa é a mitigação contra ataques de cadeia de suprimentos. Não pressupõe que o servidor de build é honesto. Não pressupõe que o laptop do desenvolvedor está limpo. Não pressupõe nada e entrega a estranhos as ferramentas para conferir.
Releases assinadas com GPG
Reprodutibilidade diz que um binário corresponde a uma árvore de código. Não diz, por si só, qual árvore é a verdadeira. Isso a assinatura GPG resolve.
Cada artefato da v1.25.0 — os pacotes da extensão, o arquivo de checksums — vem assinado com a chave de release da SSP. A assinatura é publicada ao lado da release no GitHub. Para verificar um download, você importa a chave pública uma vez, roda gpg --verify contra a assinatura e a ferramenta diz se o arquivo está íntegro e se a chave que assinou é a que você esperava.
Os dois mecanismos compõem. A assinatura GPG prova «este é o arquivo que a SSP publicou». A build determinista prova «este arquivo corresponde a este commit». Juntos eliminam a lacuna de confiança entre o commit e a instalação.
Como verificar uma release você mesmo
A página da release no GitHub é a fonte autoritativa para os passos exatos — impressão digital da chave pública, nomes dos arquivos de assinatura, comando Docker para reproduzir uma build. Versão curta: importe a chave de release SSP, baixe o arquivo de checksums e sua assinatura, rode gpg --verify na assinatura e depois sha256sum -c com os checksums contra o binário que baixou. Se ambos passarem, o artefato está íntegro e autêntico.
Usuários avançados que quiserem ir além podem clonar a tag, rodar a build Docker documentada e confirmar que o SHA-256 resultante bate com o checksum publicado. A maioria nunca fará isso. O ponto é que alguns farão, e qualquer um deles descobrindo uma divergência expõe um ataque na hora.
O que isso muda
A SSP é código aberto desde a v1.0.0 e está auditada pela Halborn de ponta a ponta desde a revisão completa publicada no início de 2025. A v1.25.0 fecha o terceiro lado desse triângulo. Código aberto significa que você pode ler o código; auditado significa que especialistas o examinaram; reprodutível mais assinado significa que o que está na sua máquina é, de fato, o código que você leu.
As três garantias são independentes e compõem. Um binário open-source não reprodutível ainda pode esconder comprometimento no pipeline de build. Um projeto auditado não reprodutível ainda pode enviar um binário adulterado que os auditores nunca viram. Com a v1.25.0, «verifique antes de instalar» deixa de ser aspiração e vira uma lista concreta.
Essa é a história da cadeia de suprimentos de uma carteira self-custodial, contada da única forma honesta possível.