Summary

  • LACNIC’s 10 August installation guide downloads fort-1.7.0.experimental.tar.gz, extracts it, compiles it and runs sudo make install on Ubuntu Server 26.04, but gives no checksum or detached-signature verification command.
  • The release had already published the tarball, a .asc signature and fort.keyring. Bytes captured on 31 August match the GitHub API’s SHA-256 digests, and GnuPG returns GOODSIG and VALIDSIG for the tarball under fingerprint 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • That is strong evidence for the captured pair, not a complete trust decision: the same isolated check reports TRUST_UNDEFINED, while GitHub reports the release as non-immutable. A signed tag, a signed asset and an installed binary remain separate objects.
  • A defensible installation receipt should join the release, commit, asset digest, signature, independently trusted fingerprint, build inputs and installed binary, then preserve activation and rollback evidence.

The missing line sits between wget and tar

LACNIC describes its eight-page document as a verified, step-by-step installation of FORT 1.7.0.experimental on Ubuntu Server 26.04. The guide is specific about the environment: amd64/x86_64, a server installation, and a source build chosen because the tested .deb asked for libmicrohttpd12 and libxml2 while the operating system exposed differently named packages.

Its command sequence is easy to follow. It fetches fort-1.7.0.experimental.tar.gz, runs tar -xzf, enters the source tree, configures it, compiles with make -j"$(nproc)", and installs with sudo make install. The document then checks fort --version, inspects linked libraries with ldd, performs a first validation, looks at output, configures a service and RTR listener, and reminds the operator to keep the clock synchronized.

Those are useful downstream checks. They do not answer the upstream question: which bytes were admitted to the build?

There is no SHA-256 value in the PDF, no checksum command, no reference to the release’s .asc file or fort.keyring, and no gpg --verify step. The only use of the Spanish root firma concerns signed RPKI objects, not authentication of the downloaded software. The installation document pinned to the release commit has the same boundary: it explains how to download packages or source archives and install them, without joining the archive to a checksum or detached signature.

The omission is unusually visible because the evidence needed for a better step was already beside the tarball.

The release supplied three artifacts before the guide existed

GitHub records release 1.7.0.experimental as created on 16 July 2026 at 01:52:42Z and published at 03:45:33Z. Its annotated tag points to commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; the tag-object API reports a valid verified signature.

The release assets followed within minutes. The tarball was attached at 03:47:16Z, its detached signature at 03:47:19Z, and fort.keyring at 03:51:35Z. All three therefore predate LACNIC’s 10 August guide. The installation page did not have to wait for a signing mechanism to be invented or for an artifact to be published.

At the 31 August observation, the Releases API supplied a SHA-256 digest for every asset:

Artifact Captured SHA-256
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
fort-1.7.0.experimental.tar.gz.asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

The independently captured files match those current API digests. A bounded GnuPG test, using the supplied keyring and detached signature, returns both GOODSIG and VALIDSIG. It identifies fingerprint 8F9ABC7EF3BA565F9DF1578C72160FD57B242967 and a signature timestamp of 16 July 2026 at 01:55:02Z.

That is the strongest defence of the release, and it belongs in the account. The observed tarball is not an unexplained archive: it matches the current API digest and the detached signature is mathematically valid for the supplied public key. Nothing in the checked record shows that the archive was malicious, substituted, broken or responsible for a routing failure.

Yet GnuPG also reports TRUST_UNDEFINED and warns that the key was not certified through a trusted signature in the temporary environment. That is not a bad-signature result. It is a boundary around the result: the software established that the signature corresponds to the private key behind the imported public key, but the test did not independently establish who controls that key or why an operator should accept it as the authorised FORT release key.

Four valid checks are not one continuous chain

Software provenance becomes slippery when several good-looking signals are treated as interchangeable.

First, the signed annotated tag joins a tag to commit c67d14b…. It does not, by itself, prove that an uploaded tarball contains exactly that commit. Release assets are uploaded objects with their own bytes and lifecycle.

Second, the GitHub API joins an asset name to a current digest and timestamps. At capture time it also reports immutable: false, draft: false and prerelease: false. Non-immutable status is not evidence that an asset changed. It means the observation should be dated and preserved rather than promoted into a timeless claim about every download ever served.

Third, the detached signature joins the captured tarball to a signing key. Mathematical validity is valuable, but signer identity and key authority require a trust decision that should not be obtained only from the same release page that supplied the archive, signature and keyring. An operator needs an independently authenticated fingerprint or another explicit trust anchor, plus a view of rotation and revocation.

Fourth, the build joins source bytes to a local executable through the compiler, configure choices, dependency headers and installation paths. fort --version reports the program’s version string; ldd reports linked libraries. Neither result proves a reproducible build or records the hash of the installed binary. The public materials inspected here do not make or test a bit-for-bit reproducibility claim.

These distinctions matter more, not less, when the last command is sudo make install. The command crosses a privilege boundary and writes into the system. It does not make the guide unsafe by definition. It raises the value of preserving what received that authority.

A compact receipt would make the guide auditable

LACNIC need not turn an installation guide into a treatise on supply-chain security. One verified download block and a small receipt can close most of the public gap.

The download block should name the exact release and tag, pin the asset URL, state the expected digest, calculate the observed digest, import a fingerprint whose authority was established through an independent channel, and verify the detached signature. It should say what a mismatch means: stop, preserve the evidence and seek a corrected instruction rather than continuing to extract.

The receipt should then carry the chain into the local system:

Boundary Minimum durable record
Release Tag, release URL, target commit, publication time and observed immutability state
Asset Exact filename and URL, expected and observed SHA-256, download and verification time
Signature .asc and keyring digests, full fingerprint, independent fingerprint source, trust decision and result
Build OS and architecture, compiler, configure flags, dependency package names and versions
Install Executable path, binary digest, fort --version, configuration and service-file digests
Operation Activation time, previous version, rollback procedure, key rotation or revocation status and corrections

This record does not ask the registry to own every layer. FORT’s maintainers control project releases; GitHub controls a distribution surface; Ubuntu supplies build dependencies; an operator decides which key and binary to trust; routers consume results under local policy. LACNIC’s leverage is narrower and still important: its guide can make those handoffs explicit instead of allowing one recognisable release label to stand in for all of them.

The same restraint applies to the .deb explanation. The guide reports that its tested package requested dependency names unavailable on Ubuntu 26.04, which is why it used the source route. The present evidence does not independently reproduce that packaging behaviour. It is the guide author’s tested premise, not a fresh laboratory result.

What this finding does—and does not—say

The finding is about published instructions. It is not evidence that any reader followed them without additional checks. Experienced operators may already have local procedures, mirrors, pinned digests, internal build systems or trusted keys. Their practice cannot be inferred from an eight-page public guide.

Nor is this a repeat of the question whether FORT exposes ASPA information over RTR or which protocol version a router negotiates. That is an output and interoperability surface. Here the object is earlier: how the executable producing validation output is tied to a recorded source artifact and an authorised signer.

The evidence supports a precise conclusion. LACNIC published a careful operational path after installation, but left the release-to-build handoff implicit even though the release already contained usable verification artifacts. Adding that handoff would not prove every dependency, eliminate trust judgement or guarantee routing correctness. It would make one consequential transition visible, repeatable and correctable.

Sources