Il 2025-08-03, SSP Wallet v1.25.0 ha rilasciato due cambiamenti che, presi insieme, sistemano una delle più antiche debolezze taciute della distribuzione dei wallet: non c'è più bisogno di fidarsi che il binario sullo store sia il binario del repository. Le release ora vengono compilate in modo deterministico dentro Docker e firmate con GPG. Chiunque — non solo noi, non solo un auditor — può ricompilare dal sorgente e verificare che ciò che ottiene coincide, byte per byte, con quello che abbiamo pubblicato.
Non fidarti, verifica — applicato ai binari del wallet
Il motto bitcoin «non fidarti, verifica» di solito si dice delle transazioni. Vale, con la stessa forza, per il software che le firma. Il codice di un wallet può essere aperto e auditato e comunque consegnare un binario compromesso, perché il percorso dal codice al binario passa per un server di build, un passo di pacchettizzazione, una chiave di firma e un upload sullo store. Ogni anello può essere avvelenato. Un token di CI trapelato, un binario sostituito nella pipeline, un agente di build manomesso — niente di tutto questo tocca il repository pubblico e niente è visibile in un git log.
La risposta difensiva a quel modello di minaccia è che il binario stesso deve essere verificabile. Non «verificabile perché lo promettiamo». Riproducibile da estranei.
Build deterministiche con Docker
È quello che v1.25.0 consegna. Ogni release SSP ora viene compilata dentro un container Docker con immagine di base bloccata, versioni di toolchain bloccate e ambiente completamente isolato. La build non ha accesso di rete dove non serve, non lascia trapelare il filesystem dell'host, non incorpora timestamp nell'output né percorsi specifici della macchina. L'output è una funzione deterministica degli ingressi.
La conseguenza pratica: codice sorgente identico produce binari identici con checksum coincidenti. Prendi il tag, compilalo nel container documentato sulla tua macchina e otterrai lo stesso SHA-256 che otteniamo noi. Se non lo ottieni, qualcosa è divergiato tra il tag e il binario pubblicato — ed è esattamente il segnale che si vuole, perché l'unico esito onesto è «il binario coincide col codice» o «non coincide».
Questa è la mitigazione contro gli attacchi alla supply chain. Non presume che il server di build sia onesto. Non presume che il portatile dello sviluppatore sia pulito. Non presume nulla e consegna agli estranei gli strumenti per controllare.
Release firmate con GPG
La riproducibilità ti dice che un binario corrisponde a un albero di sorgenti. Non ti dice, da sola, quale albero di sorgenti sia quello vero. A questo serve la firma GPG.
Ogni artefatto di v1.25.0 — i bundle dell'estensione, il file dei checksum — è firmato con la chiave di release SSP. La firma è pubblicata accanto alla release su GitHub. Per verificare un download, importi la chiave pubblica una volta, esegui gpg --verify sulla firma e lo strumento ti dice se il file è intatto e se la chiave che ha firmato è quella attesa.
I due meccanismi si compongono. La firma GPG dimostra «questo è il file che SSP ha pubblicato». La build deterministica dimostra «questo file corrisponde a questo commit». Insieme rimuovono lo spazio di fiducia tra commit e installazione.
Come verificare una release da soli
La pagina della release su GitHub è la fonte autorevole per i passaggi esatti — impronta della chiave pubblica, nomi dei file di firma, comando Docker per riprodurre una build. Versione breve: importa la chiave di release SSP, scarica il file dei checksum e la sua firma, esegui gpg --verify sulla firma e poi sha256sum -c sui checksum contro il binario scaricato. Se entrambi passano, l'artefatto è intatto e autentico.
Gli utenti avanzati che vogliono andare oltre possono clonare il tag, eseguire la build Docker documentata e confermare che lo SHA-256 risultante coincida con il checksum pubblicato. La maggior parte non lo farà mai. Il punto è che alcuni sì, e che uno qualunque di loro che trovi una discrepanza svela un attacco all'istante.
Cosa cambia
SSP è open source dalla v1.0.0 ed è auditato da Halborn end-to-end dalla revisione completa pubblicata all'inizio del 2025. v1.25.0 chiude il terzo lato di quel triangolo. Open source vuol dire che puoi leggere il codice; auditato vuol dire che esperti l'hanno esaminato; riproducibile più firmato vuol dire che ciò che gira sulla tua macchina è davvero il codice che hai letto.
Le tre garanzie sono indipendenti e si compongono. Un binario open-source non riproducibile può ancora nascondere compromessi nella pipeline di build. Un progetto auditato non riproducibile può ancora consegnare un binario manomesso che gli auditor non hanno mai visto. Con v1.25.0, «verifica prima di installare» smette di essere un'aspirazione e diventa una checklist concreta.
Questa è la storia di supply chain di un wallet self-custody, raccontata nell'unico modo in cui può essere raccontata onestamente.