Resumen

  • La guía publicada por LACNIC el 10 de agosto descarga fort-1.7.0.experimental.tar.gz, lo descomprime, compila y ejecuta sudo make install en Ubuntu Server 26.04; no incluye checksum, .asc, llavero ni verificación de firma.
  • La versión de GitHub ya contenía el tarball, su firma separada y fort.keyring. La captura del 31 de agosto coincide con los tres SHA-256 de la API y GnuPG devuelve GOODSIG y VALIDSIG para la huella 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • La firma válida es una defensa importante, no una confianza completa: el entorno aislado también devuelve TRUST_UNDEFINED, y la API describe la versión como no inmutable. Etiqueta, activo, clave y binario instalado requieren comprobaciones distintas.
  • Una fe de instalación útil uniría versión y commit, archivo y hash, firma y autoridad de la clave, entradas de compilación, binario final, activación y reversión.

“Verificada” describe el ensayo, no toda la procedencia

La palabra decisiva aparece antes de la primera orden. La guía española dice que ofrece un procedimiento paso a paso verificado para instalar FORT 1.7.0.experimental en Ubuntu Server 26.04. Eso comunica algo valioso: alguien probó una ruta concreta en amd64/x86_64 y documentó lo que ocurrió.

No comunica, por sí solo, que se verificó cada frontera de confianza de esa ruta.

El motivo del camino elegido también es concreto. Según el documento, el paquete .deb ensayado pedía libmicrohttpd12 y libxml2, mientras Ubuntu 26.04 proporcionaba paquetes con nombres diferentes. La solución documentada fue compilar con las bibliotecas de desarrollo nativas. Esta investigación no reprodujo de forma independiente aquel comportamiento del paquete; lo atribuye a la prueba relatada por la propia guía.

Después viene la receta: descargar fort-1.7.0.experimental.tar.gz, extraer, ejecutar ./configure, compilar con make -j"$(nproc)" y elevar privilegios con sudo make install. Al final se consulta fort --version, se inspeccionan bibliotecas con ldd, se hace una primera validación, se miran archivos de salida, se configura el servicio y RTR y se comprueba la sincronización del reloj.

La secuencia verifica que el programa instalado arranca y se comporta de ciertas maneras. No verifica qué bytes entraron en tar y, después, en el compilador. No aparece un SHA-256, una instrucción para comprobar un checksum, el nombre del .asc, una importación de fort.keyring ni una orden de GnuPG. La única familia léxica de firma en el PDF se refiere a objetos RPKI firmados, no al software descargado.

Por tanto, no hace falta negar que la guía fue probada. Hay que precisar qué fue probado y qué unión quedó fuera.

La versión ya traía los elementos de una comprobación

GitHub fecha la creación de 1.7.0.experimental el 16 de julio de 2026 a las 01:52:42Z y su publicación a las 03:45:33Z. La etiqueta anotada apunta al commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; la API del objeto informa que su firma es válida y está verificada.

Los activos aparecieron inmediatamente después: tarball a las 03:47:16Z, firma separada a las 03:47:19Z y fort.keyring a las 03:51:35Z. Es decir, los tres estaban disponibles semanas antes de la guía de LACNIC.

La API observada el 31 de agosto daba estos valores:

Objeto SHA-256 capturado
Tarball 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
Firma .asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

Los bytes obtenidos por separado coinciden con esos tres hashes actuales. Al importar el llavero suministrado y contrastar la firma con el tarball, GnuPG responde GOODSIG y VALIDSIG. La huella primaria es 8F9ABC7EF3BA565F9DF1578C72160FD57B242967; la firma lleva la hora 16 de julio de 2026, 01:55:02Z.

Ese resultado debe ocupar el centro, porque impide exagerar el problema. La evidencia consultada no muestra un archivo malicioso, sustituido o incorrecto. El tarball capturado coincide con el digest publicado actualmente por la API y su firma separada es matemáticamente válida bajo la clave pública suministrada.

GnuPG añade TRUST_UNDEFINED y advierte que la clave no estaba certificada por una firma de confianza en el entorno temporal. No contradice VALIDSIG. Responde a otra pregunta: se comprobó la relación matemática entre archivo, firma y clave importada; no se estableció de manera independiente quién controla esa clave ni con qué autoridad firma versiones de FORT.

Una etiqueta firmada no salta hasta /usr/local

La cadena puede dividirse en cuatro actos, cada uno con su propio comprobante.

La etiqueta firmada enlaza la etiqueta con c67d14b…. No autentica automáticamente el tarball subido como activo de la versión. Git y el almacén de activos de una página de Releases son superficies distintas.

El registro de la versión enlaza un nombre de archivo con un digest y unas horas observadas. En la captura, la API devuelve immutable: false, además de draft: false y prerelease: false. “No inmutable” no significa que algo cambiara. Significa que el estado y el hash deben fecharse; no pueden presentarse como prueba de lo que recibió cada descarga histórica.

La firma separada enlaza los bytes capturados con la clave privada correspondiente a la clave pública importada. Para convertir eso en una decisión operativa falta un ancla independiente: una huella obtenida por un canal autenticado, una declaración de autoridad de firma y reglas de rotación o revocación. Descargar tarball, firma y llave del mismo lugar no crea por sí mismo independencia de canal.

Finalmente, la compilación enlaza el código fuente con un ejecutable local mediante compilador, opciones de configure, cabeceras, bibliotecas y rutas. fort --version no da el hash del ejecutable; ldd no conserva todas las entradas de compilación. Las fuentes revisadas no plantean ni demuestran una construcción reproducible bit a bit.

Son límites ordinarios. Se vuelven operativamente importantes porque sudo make install concede capacidad de escribir en el sistema. No prueba que la receta sea peligrosa; hace más valioso saber qué artefacto recibió ese permiso.

La solución cabe en una ficha corta

Una revisión de la guía podría colocar, antes de tar -xzf, un bloque que:

  1. fije versión, URL y nombre exacto del activo;
  2. publique el SHA-256 esperado y calcule el observado;
  3. obtenga por una vía independiente la huella completa autorizada;
  4. verifique la firma separada;
  5. ordene detenerse y conservar evidencia ante cualquier diferencia.

Luego, una ficha local mantendría la continuidad:

Paso Evidencia mínima
Publicación Etiqueta, URL, commit, hora y estado de inmutabilidad observado
Descarga Nombre y URL del activo, SHA-256 esperado/observado, hora de descarga
Confianza Hashes de firma y llavero, huella completa, fuente independiente y decisión
Compilación SO, arquitectura, compilador, opciones y versiones de dependencias
Instalación Ruta y hash del binario, versión, hashes de configuración y servicio
Operación Fecha de activación, versión anterior, reversión, rotación/revocación y correcciones

La ficha reparte la autoridad con más honestidad. El proyecto mantiene una versión y una clave; GitHub distribuye objetos y expone su estado; Ubuntu aporta dependencias; el operador decide confianza y activación; LACNIC publica una ruta recomendada. Ninguna parte controla sola el proyecto, la plataforma, los paquetes y la política de cada red.

También evita otra confusión: validar objetos RPKI no valida retroactivamente el ejecutable. FORT puede aplicar correctamente reglas criptográficas a su entrada, mientras la organización carece del comprobante que une el programa instalado con una fuente y un firmante autorizados.

Un hallazgo sobre documentación, no sobre conducta

La ausencia está en el texto publicado. No autoriza a afirmar que un operador omitió la comprobación. Una red puede añadir sus propios hashes, claves, repositorios internos, compilaciones controladas o imágenes aprobadas sin que aparezcan en el PDF.

Tampoco hay indicio aquí de compromiso, sustitución, fallo de RPKI, fuga de rutas o secuestro. immutable: false no dice que un activo haya sido reemplazado. El digest actual no prueba qué bytes sirvió la plataforma en todos los momentos anteriores. Una firma buena con la clave suministrada no demuestra la identidad legal del firmante.

El límite temático es igualmente claro. Otra cobertura puede estudiar si FORT entrega ASPA por RTR o qué versión de protocolo negocia un router. Esta pieza se ocupa de la etapa anterior: el comprobante que permite reconstruir qué ejecutable produjo aquella salida.

LACNIC ya tiene una guía detallada después de la instalación y la versión ya tenía mecanismos para mejorar el tramo anterior. Unirlos no garantiza toda la cadena de suministro. Sí convierte una etiqueta reconocible en una decisión verificable y deja una vía de corrección si cambia la clave, el activo o la receta.

Fuentes