# Lokale reproduzierbare Entwicklungsbuilds

`scripts/build-release.py` baut einen **expliziten vorhandenen nativen Snapshot**,
nicht den möglicherweise veränderten Arbeitsbaum. Es benötigt Python 3 mit
Standardbibliothek, einen separat gewählten vertrauenswürdigen Go-Compiler und
ein vertrauenswürdiges vorhandenes MeshForge-Binary für den lokalen Export.
Git, Container, npm und fremde Python-/Go-Module sind nicht erforderlich.

```sh
python scripts/build-release.py \
  --go /absolute/tools/go/bin/go \
  --exporter /absolute/tools/mf \
  --repository /absolute/workspace/decentralhub \
  --snapshot FULL_NATIVE_SNAPSHOT_SHA256 \
  --output /absolute/artifacts/new-build
```

Das Zielverzeichnis muss neu sein und außerhalb des Quellprojekts unter einem
vertrauenswürdigen, bereits vorhandenen Parent liegen. Vorhandene Ausgabe wird
nicht ersetzt. Export und Compiler sind lokale Vertrauenseingaben; das Skript
führt keine heruntergeladenen Installer oder erzeugten Programmdateien aus.

Standardziele sind Linux amd64, Windows amd64 und Windows arm64. `--target`
kann eines oder mehrere dieser Ziele ausdrücklich auswählen. `--source-date-epoch`
setzt den festen Archivzeitpunkt, standardmäßig 0. Er dient nur reproduzierbaren
Metadaten und ist keine vertrauenswürdige Releasezeit.

## Was geprüft und ausgegeben wird

Der Exporter rekonstruiert denselben Snapshot zweimal in verschiedene absolute
Verzeichnisse. Alle regulären Quelldateien werden nach Pfad, SHA-256 und Größe
verglichen; Symlinks und unerwartete Dateien werden abgewiesen. `go list -m all`
muss weiterhin ausschließlich das lokale Modul `decentralhub` melden.

Jedes Ziel wird aus beiden Verzeichnissen kompiliert. `CGO_ENABLED=0`,
`GOTOOLCHAIN=local`, `GOPROXY=off`, `GOSUMDB=off`, `GOWORK=off`, `GOENV=off`,
leere `GOFLAGS`, feste Architekturgrundwerte sowie `-trimpath -buildvcs=false
-ldflags=-buildid=` verhindern typische Host-/Pfad-/Netzabhängigkeiten.
Geerbte Go-Experiment-/Compilerkonfiguration wird entfernt; nur ein ausdrücklich
vorhandener GOCACHE darf als lokaler Compiler-Cache weiterverwendet werden.
Abweichende Binärbytes zwischen beiden Quellpfaden brechen den Build ab.

Die lokale Ausgabe enthält:

- Pro Ziel das Binary und ein deterministisches tar.gz mit Binary, Lizenz,
  README, Source-Manifest, SBOM und Provenienz. Namen, Eigentümer, Modi,
  Reihenfolge und Zeitstempel im Archiv sind festgelegt.
- Ein deterministisches Quellarchiv ohne `.dh`-Historie und ein vollständiges
  `source-manifest.json` für die exakt exportierten Dateien.
- Pro Ziel eine SPDX-2.3-Komponentenliste mit Quellsnapshot, Go-Toolchain und
  tatsächlich für dieses Ziel eingebundenen Standardbibliotheks-Importpfaden.
  Sie ersetzt keine Lizenzprüfung von Go-Distributionsbestandteilen.
- Pro Ziel eine `mf.build-provenance/1`-Datei mit Snapshot, Source-Manifesthash,
  Compiler-Version/-Dateihash, Buildflags, relevanten Umgebungswerten,
  Binärhash/-größe, SBOM-Hash und Ergebnis des Vergleichs beider Builds.
- `SHA256SUMS` für die erzeugten Artefakte. `release-build.json` wird als
  Abschlussnachweis **zuletzt** installiert; ohne diese Datei ist eine Ausgabe
  unvollständig. Ein Fehler nach Anlage des Zielverzeichnisses erfordert ein
  neues Ziel, kein Wiederverwenden oder stilles Überschreiben.

Zwei vollständige Aufrufe mit denselben Eingaben müssen dieselben Artefaktbytes
erzeugen. Die im Info-Projekt gespeicherte unabhängige Prüfung
`check-reproducible-build.py` vergleicht solche Ausgaben und kontrolliert
Prüfsummen, Provenienzbindungen, SPDX-Felder und Archivmetadaten.

## Vertrauensgrenzen

Das ist lokale Build-Evidenz, **keine authentifizierte Buildbescheinigung** eines
unabhängigen Dienstes und keine Produktionsfreigabe. Derselbe kompromittierte
Compiler kann zweimal dieselben falschen Bytes erzeugen. Native Snapshot-ID und
Source-Manifest beweisen Unverändertheit unter dem vorhandenen Format; sie
bestätigen weder Herkunft, Lizenz noch eine reale Founder-Identität.

Diese Werkzeuge veröffentlichen nichts, provisionieren keine Schlüssel,
signieren nichts und installieren nichts. Für echte Freigaben weiterhin separat
bestätigte Roots, Reviews, Sicherheitsabnahme und echte Plattformtests verwenden.
Der Hash der Provenienzdatei kann ausdrücklich in ein anschließend geprüftes
Release-Manifest übernommen werden; ihr Vorhandensein autorisiert kein Release.
Windows-Crossbuilds und zwei lokale Builds ersetzen keine Windows-Hardwaretests
oder unabhängige Reproduktion auf einem anderen vertrauenswürdigen Rechner.