Zusammenfassung

  • LACNICs Anleitung vom 10. August lädt fort-1.7.0.experimental.tar.gz unter Ubuntu Server 26.04, entpackt und kompiliert den Quelltext und führt sudo make install aus, ohne Prüfsumme oder abgetrennte Signatur zu kontrollieren.
  • Tarball, .asc und fort.keyring waren bereits veröffentlicht. Die am 31. August erfassten Dateien entsprechen den aktuellen SHA-256-Werten der API; GnuPG meldet GOODSIG und VALIDSIG für den Fingerprint 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • Das ist ein starker Befund zugunsten der erfassten Datei, aber noch kein vollständiger Vertrauensentscheid: Dieselbe Prüfung liefert TRUST_UNDEFINED, und die API meldete die Release zum Beobachtungszeitpunkt als nicht unveränderlich.
  • Ein belastbarer Build-Beleg muss Tag und Commit, Asset und Digest, Signatur und unabhängige Schlüsselautorität, Compiler und Abhängigkeiten sowie installiertes Binary, Aktivierung und Rollback verbinden.

Ein erfolgreicher Start ist kein Herkunftsnachweis

Die achtseitige Anleitung ist auf einen konkreten Engpass zugeschnitten. Sie nennt FORT 1.7.0.experimental, Ubuntu Server 26.04 und amd64/x86_64. Das getestete .deb verlangte dem Dokument zufolge libmicrohttpd12 und libxml2, während das Betriebssystem anders benannte Pakete bereitstellte. Deshalb kompiliert der beschriebene Weg gegen die nativen Entwicklungsbibliotheken. Diese Analyse hat das Paketproblem nicht eigenständig reproduziert; sie gibt die dokumentierte Testerfahrung wieder.

Der Ablauf lädt den Tarball, entpackt ihn, führt ./configure aus, kompiliert mit make -j"$(nproc)" und installiert per sudo make install. Danach folgen fort --version, eine Prüfung mit ldd, die erste Validierung, Kontrollen der Ausgabedateien, Dienst- und RTR-Konfiguration sowie der Hinweis auf eine synchronisierte Uhr.

Damit belegt die Anleitung, dass ein erzeugtes Programm in der Testumgebung bestimmte Eigenschaften zeigte. Sie belegt nicht, welche Bytes den Compiler erreichten. Im PDF fehlen SHA-256, checksum, .asc, keyring und ein Signaturprüfbefehl. Die spanische Verwendung des Wortstamms für Signatur betrifft signierte RPKI-Objekte, nicht das heruntergeladene Softwareartefakt. Auch die auf den Release-Commit fixierte Upstream-Installationsdatei lädt Pakete oder Archive und installiert sie ohne Digest- oder Signaturprüfung.

fort --version ist deshalb ein Funktionssignal, kein Build-Beleg. Ein Versionsstring kann weder den Quell-Hash noch Compiler, Flags, Header und Zielbinary rekonstruieren.

Die Release liefert einen positiven, aber begrenzten Befund

GitHub datiert die Erstellung von 1.7.0.experimental auf den 16. Juli 2026 um 01:52:42Z und die Veröffentlichung auf 03:45:33Z. Der annotierte Tag verweist auf Commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; die Tag-Objekt-API bezeichnet seine Signatur als gültig und verifiziert.

Der Tarball wurde um 03:47:16Z, die abgetrennte Signatur um 03:47:19Z und fort.keyring um 03:51:35Z angelegt. Alle drei Assets waren somit vor LACNICs Veröffentlichung am 10. August verfügbar.

Bei der Erfassung am 31. August nannte die Releases API folgende Werte:

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

Die unabhängig abgerufenen Bytes stimmen mit allen drei aktuellen API-Digests überein. Nach Import des mitgelieferten Keyrings liefert die Prüfung der Signatur gegen den Tarball GOODSIG und VALIDSIG. Der primäre Fingerprint lautet 8F9ABC7EF3BA565F9DF1578C72160FD57B242967; die Signatur trägt den Zeitstempel 16. Juli, 01:55:02Z.

Dieser Befund spricht für das erfasste Artefakt. Es gibt in den geprüften Quellen keinen Hinweis auf einen bösartigen, ausgetauschten oder fehlerhaften Tarball und keinen Beleg für einen Validierungs- oder Routingvorfall. Die Datei entspricht dem aktuellen API-Digest, und ihre abgetrennte Signatur ist unter dem gelieferten öffentlichen Schlüssel mathematisch gültig.

GnuPG meldet zugleich TRUST_UNDEFINED und weist darauf hin, dass der Schlüssel in der temporären Umgebung nicht durch eine vertrauenswürdige Signatur zertifiziert war. Das widerspricht VALIDSIG nicht. Die Prüfung bestätigt die Zuordnung zum passenden privaten Schlüssel; sie bestätigt allein weder dessen Inhaber noch die organisatorische Berechtigung, FORT-Releases zu signieren.

Der Build-Beleg hat vier Gelenke

Das erste Gelenk verbindet Tag und Commit. Ein gültig signierter Tag auf c67d14b… authentifiziert nicht automatisch ein separat hochgeladenes Release-Asset.

Das zweite verbindet Release-Datensatz und Asset-Bytes. Die API hält Name, Zeitpunkt und aktuellen Digest fest. Sie meldete außerdem immutable: false, draft: false und prerelease: false. Nicht unveränderlich bedeutet nicht verändert. Der Zustand muss zusammen mit dem Beobachtungszeitpunkt gespeichert werden; der heutige Digest darf nicht für jeden historischen Download stehen.

Das dritte verbindet Asset und Signierschlüssel. Die gültige Signatur weist die Nutzung des zugehörigen privaten Schlüssels nach. Ein Operator braucht zusätzlich einen unabhängig authentisierten Fingerprint, eine Benennung der Signierbefugnis sowie Regeln für Rotation und Widerruf. Tarball, Signatur und Schlüssel vom selben Kanal erlauben mathematische Kontrolle, aber keine unabhängige Vertrauenswurzel.

Das vierte verbindet Source und lokales Binary. Betriebssystem, Compiler, Configure-Optionen, Header und Bibliotheksversionen beeinflussen das Ergebnis. ldd zeigt Laufzeitverknüpfungen; es ist kein vollständiges Build-Protokoll. Die untersuchten Unterlagen erheben keinen Anspruch auf bitgenau reproduzierbare Builds.

Keines dieser Gelenke ist ein Vorwurf. Jedes verhindert nur, dass ein erfolgreicher Nachweis für ein Objekt stillschweigend auf ein anderes übertragen wird.

Ein Build-Beleg kann kurz und vollständig sein

Vor tar -xzf sollte die Anleitung Release, Tag und Asset-URL festlegen, den erwarteten und den gemessenen SHA-256 vergleichen, den vollständigen Fingerprint über einen unabhängigen authentisierten Kanal beziehen und die .asc-Signatur prüfen. Bei Abweichung muss der Ablauf anhalten und eine Korrektur verlangen.

Nach make install kann ein kompakter Datensatz die restlichen Übergänge bewahren:

Abschnitt Mindestnachweis
Release Tag, URL, Ziel-Commit, Veröffentlichungszeit, beobachteter Immutable-Status
Asset Exakter Name und URL, erwarteter/gemessener Digest, Prüfzeit
Signatur Digests von .asc und keyring, voller Fingerprint, unabhängige Quelle, Vertrauensentscheid
Build OS, Architektur, Compiler, Flags, Namen und Versionen der Abhängigkeiten
Installation Pfad und Digest des Binary, Versionsausgabe, Digests von Konfiguration und Dienst
Betrieb Aktivierung, Vorgängerversion, Rollback, Schlüsselrotation/-widerruf, Korrekturen

Die Rollen bleiben getrennt. Das FORT-Projekt verantwortet Release und Signieridentität, GitHub eine Verteilungsoberfläche, Ubuntu die Abhängigkeiten, der Operator Vertrauen und Aktivierung. LACNIC kontrolliert diese Akteure nicht allein. Es kann aber den empfohlenen Übergang so schreiben, dass ihre Zuständigkeiten nicht zu einer einzigen angenommenen Garantie verschwimmen.

Besonders beim privilegierten Installationsschritt ist der lokale Digest entscheidend. sudo make install ist kein Beleg für Gefahr; es ist eine Autoritätsübergabe. Der Build-Beleg hält fest, welchem Ergebnis sie erteilt wurde.

Präzision setzt der Kritik Grenzen

Aus einer fehlenden Anweisung folgt nicht, dass ein Betreiber keine eigene Prüfung vorgenommen hat. Interne Spiegel, genehmigte Schlüssel, festgelegte Digests oder kontrollierte Build-Systeme können den öffentlichen Ablauf ergänzen.

Ebenso folgt aus immutable: false keine Asset-Änderung. Der aktuelle Digest beweist nicht die Bytes jedes früheren Downloads. Eine gute Signatur mit dem mitgelieferten Schlüssel beweist nicht allein die rechtliche Identität des Signierenden. Die Quellen tragen keine Aussage über Kompromittierung, Austausch oder Routingauswirkung.

Der Gegenstand unterscheidet sich auch von FORTs ASPA-Ausgabe und der RTR-Versionsaushandlung. Dort geht es um die Schnittstelle zum Router. Hier geht es um die Herkunft des Programms, das die Daten für diese Schnittstelle erzeugt.

LACNICs Anleitung ist nach der Installation ausführlich und die Release stellt brauchbare Signaturartefakte bereit. Der fehlende Build-Beleg liegt genau zwischen diesen Stärken. Er lässt sich schließen, ohne Sicherheit zu versprechen, die keine einzelne Institution kontrollieren kann.

Quellen