El 2025-08-03, SSP Wallet v1.25.0 publicó dos cambios que, juntos, corrigen una de las debilidades más antiguas y silenciadas de la distribución de wallets: ya no hace falta confiar en que el binario de la tienda es el binario del repositorio. Las versiones ahora se compilan de forma determinista dentro de Docker y se firman con GPG. Cualquiera — no solo nosotros, no solo un auditor — puede recompilar desde el código y comprobar que lo que obtiene coincide, byte por byte, con lo que publicamos.
No confíes, verifica — aplicado a los binarios de wallets
La máxima bitcoin «no confíes, verifica» suele decirse sobre transacciones. Aplica, con la misma fuerza, al software que las firma. El código de una wallet puede ser abierto y auditado y aun así enviar un binario comprometido, porque el camino del código al binario pasa por un servidor de build, un paso de empaquetado, una clave de firma y una subida a la tienda. Cualquier eslabón puede envenenarse. Un token de CI filtrado, un binario intercambiado en el pipeline, un agente de build manipulado — nada de esto toca el repositorio público ni es visible desde un git log.
La respuesta defensiva a ese modelo de amenaza es que el binario mismo tiene que ser verificable. No «verificable porque lo prometemos». Reproducible por desconocidos.
Compilaciones deterministas con Docker
Eso es lo que entrega v1.25.0. Cada release de SSP ahora se compila dentro de un contenedor Docker con imagen base fijada, versiones de toolchain fijadas y un entorno totalmente aislado. La build carece de acceso a la red donde no lo necesita, no filtra el sistema de archivos del host, no incrusta marcas temporales en la salida ni rutas específicas de la máquina. La salida es una función determinista de las entradas.
La consecuencia práctica: un código fuente idéntico produce binarios idénticos con sumas de verificación coincidentes. Toma la etiqueta, compílala en el contenedor documentado en tu máquina y obtendrás la misma SHA-256 que nosotros. Si no la obtienes, algo divergió entre la etiqueta y el binario publicado — y esa es justo la señal que quieres, porque el único resultado honesto es «el binario coincide con el código» o «no coincide».
Esta es la mitigación contra ataques a la cadena de suministro. No asume que el servidor de build es honesto. No asume que el portátil del desarrollador está limpio. No asume nada y entrega a desconocidos las herramientas para comprobarlo.
Releases firmadas con GPG
La reproducibilidad te dice que un binario corresponde a un árbol de código. No te dice, por sí sola, cuál árbol de código es el real. Eso lo resuelve la firma GPG.
Cada artefacto de v1.25.0 — los paquetes de la extensión, el archivo de checksums — viene firmado con la clave de release de SSP. La firma se publica junto al release en GitHub. Para verificar una descarga, importas la clave pública una vez, ejecutas gpg --verify contra la firma y la herramienta te dice si el archivo está íntegro y si la clave que firmó es la que esperabas.
Los dos mecanismos componen. La firma GPG demuestra «este es el archivo que SSP publicó». La build determinista demuestra «este archivo corresponde a este commit». Juntos eliminan el hueco de confianza entre commit e instalación.
Cómo verificar una release tú mismo
La página del release en GitHub es la fuente autoritativa de los pasos exactos — huella de la clave pública, nombres de archivos de firma, comando Docker para reproducir una build. Versión corta: importa la clave de release de SSP, descarga el archivo de checksums y su firma, ejecuta gpg --verify sobre la firma y luego sha256sum -c con los checksums contra el binario que descargaste. Si ambos pasan, el artefacto es íntegro y auténtico.
Los usuarios avanzados que quieran ir más allá pueden clonar la etiqueta, ejecutar la build Docker documentada y confirmar que la SHA-256 resultante coincide con el checksum publicado. La mayoría nunca lo hará. El punto es que algunos sí, y que cualquiera de ellos detecte una discrepancia delata un ataque al instante.
Lo que esto cambia
SSP es código abierto desde la v1.0.0 y está auditado por Halborn de cabo a rabo desde la revisión integral publicada a comienzos de 2025. v1.25.0 cierra el tercer lado de ese triángulo. Código abierto significa que puedes leer el código; auditado significa que expertos lo examinaron; reproducible más firmado significa que lo que tienes en la máquina es realmente el código que leíste.
Las tres garantías son independientes y componen. Un binario open-source no reproducible aún puede esconder compromiso en el pipeline de build. Un proyecto auditado no reproducible aún puede enviar un binario manipulado que los auditores nunca vieron. Con v1.25.0, «verifica antes de instalar» deja de ser una aspiración y se vuelve una lista concreta.
Esa es la historia de cadena de suministro de una wallet auto-custodial, contada como honestamente puede contarse.