Un almacén de Nix es simplemente tres funciones HTTP

Fzakaria ha publicado un artículo técnico que desmonta la complejidad percibida de los almacenes binarios de Nix. La tesis central es simple: para ser un substituter válido, un servidor solo necesita responder a tres peticiones GET específicas: obtener la información de la caché (nix-cache-info), servir el metadatos del paquete (.narinfo) y entregar el archivo comprimido correspondiente. Si un servidor puede responder esas tres solicitudes, Nix lo trata como una fuente legítima de paquetes, independientemente de si es un CDN dedicado, un repositorio Git o un servicio de pastebin.

La confianza en las firmas, no en la red

Este nivel de laxitud en el transporte es posible porque Nix no confía en el canal de transferencia. El campo de firma (Sig) en el archivo .narinfo cubre el StorePath, el NarHash, el tamaño y las referencias, pero no la URL ni el hash del archivo final. Cuando el cliente de Nix descarga el archivo, lo descomprime y verifica que el NarHash coincida con el firmado. Esto significa que un paquete firmado por cache.nixos.org puede servir-se desde un medio intermedio arbitrario, como GitHub Releases, manteniendo la validez criptográfica. De hecho, la URL en el .narinfo puede apuntar a cualquier host o protocolo, siempre que el contenido final sea correcto.

El autor demuestra esto creando un almacén en GitHub Pages, aprovechando que este servicio sirve archivos estáticos con las cabeceras CORS necesarias para JavaScript. Además, explora otras alternativas inusuales:

• gachix: Almacena los archivos en la base de objetos de Git, aprovechando la deduplicación en delta para reducir el tamaño un 82% frente a una caché plana.
• nexus npm: Publica la clausura completa de un paquete en npm. Al ser nix copy --to file:// una estructura de directorios, encaja perfectamente con el modelo de publicación de npm, permitiendo distribuir dependencias a través del ecosistema JavaScript.
• DNS y pastebin: Se han creado pruebas de concepto que usan registros TXT de DNS para servir metadatos y fragmentos de archivo, o pastebins que actúan como almacenes efímeros con estrategia de expiración natural.

Implicaciones prácticas

Para los administradores de sistemas y desarrolladores que gestionan infraestructura de Nix, esto amplía radicalmente las opciones de despliegue de cachés. No se necesita montar un servidor HTTP complejo ni pagar por un CDN especial. Se puede utilizar la infraestructura existente de control de versiones o repositorios de paquetes. También abre la puerta a mecanismos de distribución más creativos para paquetes que no están en Nixpkgs, facilitando la prueba de conceptos y la distribución interna sin la sobrecarga operativa de un binario cache tradicional.

El artículo destaca la elegancia del diseño de Nix: al confiar en la verificación de integridad a nivel de contenido y no de transporte, el protocolo se vuelve agnóstico al medio. Cualquier sistema capaz de servir archivos estáticos de forma fiable puede convertirse en un nodo de distribución de paquetes, reduciendo la barrera de entrada para crear almacenes privados o experimentales.