Ein Release verifizieren

Restow ist Software, die Ihre Sicherungen und Ihre Schlüssel hält. Sie sollten daher prüfen können, dass das, was Sie betreiben, das ist, was das Projekt gebaut hat, und sehen können, was vor der Veröffentlichung getestet wurde. Diese Seite zeigt, wie, und sagt offen, wo die Prüfungen enden.

Was in einem Release steckt

Jedes Release ist ein GitHub-Release in restow-backup/restow, die Images liegen in der GitHub Container Registry. Ein Release enthält:

Vier Images in zwei Builds, jeweils für linux/amd64 und linux/arm64:
- der vollständige Build: ghcr.io/restow-backup/restow (API, Worker, Scheduler, restic, die Agent-Downloads und das eigenständige Restore-Werkzeug restow-restore, dazu die Business- und Service-Provider-Module) und ghcr.io/restow-backup/restow-web (der Caddy-Edge und die Weboberfläche),
- der Community-Build: ghcr.io/restow-backup/restow-community und ghcr.io/restow-backup/restow-web-community, dasselbe ohne jeden Code aus ee/.
Alle vier tragen denselben Tag und sind mit cosign signiert. Welchen Build Sie wählen, steht unter Erste Schritte als Administrator.
Die Smoke-Berichte: smoke-report.md (vollständiger Build, amd64), smoke-report-arm64.md, smoke-report-community.md und smoke-report-community-arm64.md, die Ergebnisse des unten beschriebenen Release-Smoke-Laufs. Die Release-Notes fassen sie im Abschnitt Verification zusammen.
Die Agent-Binärdateien für das Endpunkt-Backup: restow-agent_<version>_<os>-<arch> für Linux und macOS auf amd64 und arm64, und ihre Lizenzhinweise restow-agent-THIRD_PARTY_NOTICES.txt (die Lizenzen des Agents, von Go, von restic und von den Go-Modulen, die in restic einkompiliert sind).
Die signierte Prüfsummenliste des Agents: agent-SHA256SUMS und ihre Signatur agent-SHA256SUMS.sig (siehe Das Agent-Release prüfen).
Die SBOMs: <image>-<version>-linux-<arch>.spdx.json, eine je Image und Architektur (acht Dateien, zum Beispiel restow-0.4.7-linux-amd64.spdx.json oder restow-web-community-0.4.7-linux-arm64.spdx.json), im SPDX-Format.
Der Release-Stack: docker-compose.yml und env.example, die Dateien aus deploy/release/, gegen die der Smoke-Lauf testet.
Das Installationsskript: install.sh und seine Prüfsummendatei install.sh.sha256; es installiert den Release-Stack auf einer eigenen Linux-VM (siehe Erste Schritte).
SHA256SUMS (der SHA-256 jeder Datei oben: Release-Stack, Installationsskript, SBOMs, Smoke-Berichte, Agent-Binärdateien und ihre Lizenzhinweise) und SHA256SUMS.sigstore.json (die cosign-Signatur dieser Liste).

Die Release-Notes nennen außerdem die Digests der vier Multi-Architektur-Manifeste, je eine Zeile (restow: sha256:..., restow-web: sha256:..., restow-community: sha256:... und restow-web-community: sha256:...). Der optionale Updater prüft die gezogenen Images gegen die beiden Zeilen seines eigenen Builds.

Docker-Tags

0.x.y (Beta): :<version> und :beta. Ein :latest gibt es noch nicht.
Ab 1.0.0, ein stabiles Release: :<version>, :MAJOR.MINOR, :MAJOR und :latest.
Eine Vorabversion (-rc.N): nur :<version>.

Die Community-Images tragen dieselben Tags. Nennen Sie für alles, woran Ihnen liegt, die genaue Version in der .env (RESTOW_IMAGE, RESTOW_WEB_IMAGE) statt eines wandernden Tags, damit ein Update dann passiert, wenn Sie es entscheiden. Siehe Updates.

Eine Image-Signatur prüfen

Die Images sind mit cosign im schlüssellosen Modus (keyless) signiert. Es gibt keinen langlebigen Signaturschlüssel, der abfließen könnte: Der Release-Workflow auf GitHub Actions weist seine Identität über das OIDC-Token von GitHub gegenüber Sigstore nach und erhält ein kurzlebiges Zertifikat. Die Prüfung stellt fest, dass die Signatur von genau diesem Workflow, im Repository restow-backup/restow, für den Tag der Version erstellt wurde.

Der Aussteller (Issuer) ist immer https://token.actions.githubusercontent.com. Die Identität für eine Version ist genau der Release-Workflow am Tag dieser Version, hier v0.4.7:

cosign verify ghcr.io/restow-backup/restow:0.4.7 \
  --certificate-identity https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v0.4.7 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Das ist die Prüfung, die der optionale Updater ausführt, bevor er ein Image zieht. Die Release-Notes drucken eine lockerere Variante, die den Release-Workflow auf jedem Versions-Tag akzeptiert:

cosign verify ghcr.io/restow-backup/restow:0.4.7 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Führen Sie denselben Befehl für restow-web aus, beim Community-Build für restow-community und restow-web-community. Fehlt eine Signatur, stammt sie von einem anderen Workflow oder (mit der genauen Identität) für einen anderen Tag, oder gehört sie zu anderem Inhalt, beendet cosign den Befehl mit einem Fehler. Die Release-Pipeline signiert mit cosign 3.1.3, verwenden Sie daher ein aktuelles cosign.

Um genau das Manifest zu prüfen, das in den Release-Notes steht, setzen Sie statt des Tags seinen Digest ein: ghcr.io/restow-backup/restow@sha256:<Digest> mit denselben zwei Optionen. Die Signatur wurde über dieses Manifest erstellt.

Die SBOM prüfen

Jedes Image hat je Architektur eine Software-Stückliste (SBOM) im SPDX-Format, mit syft aus dem Image erzeugt. Sie erhalten sie zweimal:

als Datei <image>-<version>-linux-<arch>.spdx.json am GitHub-Release (zum Beispiel restow-0.4.7-linux-amd64.spdx.json), zum Lesen, Scannen und Archivieren, und
als cosign-Attestation vom Typ spdxjson, die am Image dieser Architektur hängt, sodass sie durch eine Signatur an das Image gebunden ist und nicht nur durch einen Dateinamen.

Die Attestation hängt am Image jeder einzelnen Architektur (an dessen eigenem Digest), nicht am Multi-Architektur-Tag. docker buildx imagetools inspect ghcr.io/restow-backup/restow:0.4.7 listet den Digest jeder Plattform auf. Die Optionen unten stammen aus dem Release-Workflow (--type spdxjson ist der Typ, mit dem er attestiert, die Identitäts-Optionen sind die der Signatur). Der Befehl selbst wurde noch nicht gegen ein veröffentlichtes Release ausgeführt. Schlagen Sie daher in der cosign-Dokumentation zu verify-attestation nach, falls er sich in Ihrer Version anders verhält:

cosign verify-attestation --type spdxjson \
  ghcr.io/restow-backup/restow@sha256:<Digest des Images linux/amd64 oder linux/arm64> \
  --certificate-identity https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v0.4.7 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Die Prüfsummen prüfen

SHA256SUMS listet den SHA-256 der Release-Dateien auf: der Agent-Binärdateien und ihrer Lizenzhinweise, der SBOMs, der Smoke-Berichte, der docker-compose.yml, der env.example, der install.sh und der install.sh.sha256. Die Liste ist mit cosign schlüssellos signiert, und SHA256SUMS.sigstore.json ist diese Signatur als Sigstore-Bundle. Laden Sie beide Dateien neben den Dateien herunter, die Sie prüfen möchten, und prüfen Sie dann die Signatur der Liste und die Dateien gegen die Liste. Die Option --bundle ist das Gegenstück zum --bundle, mit dem der Release-Workflow signiert, und die Identitäts-Optionen sind dieselben wie oben:

cosign verify-blob SHA256SUMS \
  --bundle SHA256SUMS.sigstore.json \
  --certificate-identity https://github.com/restow-backup/restow/.github/workflows/release.yml@refs/tags/v0.4.7 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

sha256sum -c --ignore-missing SHA256SUMS

--ignore-missing überspringt die Dateien, die Sie nicht heruntergeladen haben. Die Agent-Binärdateien im Release sind dieselben, die im smoke-getesteten Image liegen.

Das Agent-Release prüfen

Der Endpunkt-Agent hat eine eigene Signatur, unabhängig von GitHub und Sigstore. Jedes Agent-Release (Agent, restic und die Lizenzhinweise THIRD_PARTY_NOTICES.txt, für jede Plattform) signiert der Maintainer mit einem Ed25519-Schlüssel im OpenSSH-Signaturformat (ssh-keygen -Y sign, Namespace restow-agent-release) über die Prüfsummenliste des Agents. Der öffentliche Schlüssel ist agent/release-signing.pub im Repository am Release-Tag; er ist in den Agent einkompiliert und wird in die Install-Skripte geschrieben, die Ihre Instanz ausliefert.

Die Prüfsummenliste und ihre Signatur liegen am GitHub-Release als agent-SHA256SUMS und agent-SHA256SUMS.sig, und jede Instanz liefert sie unter /install/agent/<version>/SHA256SUMS und /install/agent/<version>/SHA256SUMS.sig aus. Mit OpenSSH 8.1 oder neuer:

printf 'restow-agent-release %s\n' "$(cut -d ' ' -f 1-2 release-signing.pub)" > allowed_signers
ssh-keygen -Y verify -f allowed_signers -I restow-agent-release -n restow-agent-release \
  -s agent-SHA256SUMS.sig < agent-SHA256SUMS

ssh-keygen -l -f release-signing.pub gibt den Fingerabdruck des Schlüssels aus. Er muss SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o lauten (ED25519, restow-agent-release), derselbe Wert, den die Release-Notes veröffentlichen. Die Liste nennt jede Datei als <os>-<arch>/restow-agent, <os>-<arch>/restic oder <os>-<arch>/THIRD_PARTY_NOTICES.txt; vergleichen Sie den SHA-256 einer heruntergeladenen Datei mit ihrer Zeile.

Das Install-Skript führt dieselbe Prüfung aus, bevor es irgendetwas ausführt: Es prüft die Signatur mit ssh-keygen -Y verify (oder OpenSSL 3), dann den SHA-256 von Agent, restic und Lizenzhinweisen, und gibt den Fingerabdruck des Release-Schlüssels aus, gegen den es geprüft hat (signature: OK (release key SHA256:...)). Vergleichen Sie ihn mit SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o. Der Agent lehnt ein Update ab, das unsigniert oder mit einem anderen Schlüssel signiert ist. Einen Rechner ohne eines der beiden Werkzeuge (zum Beispiel RHEL, Rocky oder Alma 8 oder Amazon Linux 2) können Sie installieren, nachdem Sie die Liste auf einem anderen Rechner geprüft haben, indem Sie ihren SHA-256 dem Installer als RESTOW_SHA256SUMS_SHA256 übergeben. Siehe Endpunkt-Backup: Installation.

Was der Release-Smoke-Lauf prüft

Bevor etwas veröffentlicht wird, startet ein Skript genau die Images, die veröffentlicht werden sollen, aus dem Release-Stack (deploy/release/docker-compose.yml) auf einem frischen Runner, auf amd64 und auf arm64, für den vollständigen und für den Community-Build, und führt die folgenden Prüfungen aus. Das Release hängt daran: Schlägt eine Prüfung fehl, wird nichts veröffentlicht. Dasselbe Skript läuft nachts auf main, ohne etwas zu veröffentlichen, und Sie können es selbst ausführen (pnpm smoke im Repository). Der Bericht jedes Laufs hängt am Release. Die Prüfungen:

Installation. Das Image trägt seine Metadaten (Version, Revision, Plattform), restic, restow-restore und die Agent-Downloads mit ihren Prüfsummen. Der Release-Compose-Stack startet auf einer leeren Datenbank mit allen angewendeten Migrationen. Gibt es ein früheres Release, wird ein Stack der vorherigen Images mit einem Mandanten und einem Backup auf die neuen Images umgestellt. Am Ende wird die API auf der gefüllten Datenbank neu gestartet und ändert nichts.
Health. /healthz und /readyz antworten, der Edge antwortet über HTTPS, Worker und Scheduler haben sich gemeldet, und kein Container startet ständig neu.
Passkey-Anmeldung. Erst-Einrichtung, dann in einem echten Browser: Notfall-Anmeldung, einen Passkey auf einem virtuellen Authenticator registrieren, abmelden und mit dem Passkey wieder anmelden, einen Mandanten im Assistenten anlegen, und jeder Bildschirm auf Deutsch und Englisch ohne fehlende Übersetzung.
Microsoft 365 gegen einen Entwicklermandanten. Läuft nur, wenn Zugangsdaten für einen Microsoft-365-Entwicklermandanten als Repository-Secrets konfiguriert sind, nie gegen einen Kundenmandanten, und sagt sonst in klaren Worten „übersprungen“.
IMAP-Backup und -Restore. Ein Postfach mit 24 Nachrichten in zwei Ordnern auf einem echten IMAP-Server, ein Backup, drei weitere Nachrichten und ein inkrementelles Backup, ein Restore neben die Originale mit jeder wiederhergestellten Nachricht per SHA-256 verglichen und die Restore-Prüfung grün.
Journal-Empfang und Kettenprüfung. Ein synthetischer Exchange-Journalbericht per SMTP, das Archivobjekt vorhanden, die Hash-Kette geprüft und durch einen zweiten Bericht fortgesetzt, eine unbekannte Journaladresse abgewiesen und der Archiv-Export (eine EML-ZIP mit MANIFEST.csv und SHA256SUMS) enthält die Originale byte-genau.
Eigenständiger Restore. restow-restore aus dem Image stellt bei gestopptem Server und ohne Netzwerk im Container den Speicher aus Prüfung 5 wieder her, und jede Datei stimmt überein. Eine Kopie mit einem beschädigten Byte wird abgewiesen.
Speicherziele. S3 (Garage), ein lokaler Pfad und ein eingehängtes Verzeichnis, das für eine NFS- oder SMB-Freigabe steht, bekommen je einen Schreibvorgang (ein Backup), einen Lesevorgang (die Restore-Prüfung) und einen Scrub.
Scans. Trivy auf dem Image und pnpm audit auf hohe und kritische Meldungen. Kritische Funde, für die es eine Korrektur gibt, lassen den Lauf scheitern. Kritische Funde ohne Korrektur stehen im Bericht, sie werden nicht verschwiegen.
Endpunkt-Backup und -Restore. Das echte Install-Skript installiert den Agent in einem Linux-Container aus dem laufenden Stack, meldet ihn mit einem Einmal-Token an, sichert einen Ordner, und eine Restore-Aufgabe legt ihn in einem neuen Verzeichnis ab, in dem jede Datei per SHA-256 übereinstimmt. Diese Prüfung läuft nur in einem Linux-Container: Der macOS-Installer und der Agent gehören nicht zu den Release-Prüfungen.
Mail-Import und -Export. EML-Dateien und eine MBOX im Import-Ordner des Servers sowie eine in Stücken hochgeladene MBOX werden zu einem importierten Postfach. Es wird als EML-ZIP und als MBOX-Dateien exportiert. Die EML-Dateien kommen byte-genau zurück, jede Nachricht per Message-ID, und beide Prüfsummenlisten stimmen mit den Dateien überein. Siehe Mail-Dateien importieren und exportieren.
Sicherung von Freigaben (seit 0.4.0). Der Mounter, den neue Installationen standardmäßig starten, ein Samba-Server in einem Container und, für Kopien, eine zweite Freigabe. Die erste Freigabe enthält Dateien in Ordnern, einen Dateinamen mit Nicht-ASCII-Zeichen, eine Datei mit expliziter ACL und eine Datei, die das Konto nicht lesen darf. Die Schritte: Der Verbindungstest liest die Freigabe und ihre Berechtigungen; ein Freigaben-Job mit Zeitplan und einem ausgeschlossenen Dateityp; eine Sicherung, die alles außer der nicht lesbaren Datei sichert und mit einer Warnung für diese Datei endet; Durchsuchen und eine Suche im Katalog; ein ZIP-Download von zwei Ordnern, per SHA-256 mit der Freigabe verglichen; die Restore-Prüfung, grün; eine zweite Sicherung nach einer Änderung und einer Löschung; ein Restore in einen neuen Ordner mit Vergleich der Dateien per SHA-256 und des expliziten ACL-Eintrags; ein Restore mit „Beide behalten“ an den ursprünglichen Ort; Verlauf und Dashboard zählen die Freigabe und ihre Läufe; ein Kopierjob im Modus mirror in einen Ordner der zweiten Freigabe (eine an der Quelle gelöschte Datei fehlt im Ziel, eine Datei außerhalb des Ordners bleibt unberührt); ein Spiegeln in die Wurzel einer Freigabe wird abgelehnt; ein falsches Passwort wird als share.auth_failed eingeordnet, und das richtige funktioniert wieder; eine geleerte Freigabe wird nicht als leer gesichert (share.empty_source), und ihre Sicherungsstände bleiben. Api und Worker dürfen während der gesamten Prüfung nicht neu starten. Siehe Freigaben.
Archiv-Erfassung (seit 0.4.4). Ein IMAP-Konto auf einem echten IMAP-Server (Dovecot) mit zwei Nachrichten im Posteingang aus der Zeit vor dem Archiv, ein Mandant und ein Mail-Job mit Archiv, IMAP-Archivierung und weitergeleiteten Kopien. Die Schritte: Der Erfassungsdienst aktiviert das Konto, und die einmalige Übernahme bringt die beiden alten Nachrichten ein, als nachträglich erfasst markiert; eine neue Nachricht erreicht das Archiv innerhalb von Sekunden über IMAP IDLE (Erfassungsweg imap_sync); die API stellt die Archivadresse des Kontos einmalig aus; dieselbe Nachricht, beim Transport weitergeleitet, wird ein Element, das das synchronisierte nennt, das es ersetzt (smtp_forward); eine Kopie an die Adresse des Kontos und an die Journal-Adresse des Mandanten in einer SMTP-Transaktion ist ein Element mit einer weiteren Erfassung, und das Konto zeigt sich als empfangend; die Hash-Kette stimmt über jedes erfasste Element. Die Erfassungswege sind Business-Module, deshalb überspringt der Community-Build diese Prüfung. Siehe Archivierung.

Was der Smoke-Lauf nicht tut

Der Bericht nennt jeden dieser Punkte, und keiner wird je als bestanden dargestellt. Die Zahlen unten werden aus den Smoke-Berichten des aktuellen Releases gelesen, 0.4.7 (29. Oktober 2026); der Bericht jedes Laufs hängt an seinem eigenen Release. Dieser Lauf bestand für den vollständigen Build 12 von 13 Prüfungen vollständig und übersprang 1 (Prüfung 4, Microsoft 365); für den Community-Build bestand er 9 vollständig und übersprang 4 (der Grund steht jeweils im Bericht, der dem Release 0.4.7 beiliegt). Der erste Lauf, von 0.1.0 am 01.10.2026, bestand 9 von 11 vollständig, 1 teilweise (Prüfung 1, deren Update-Pfad kein früheres Release als Ausgangspunkt hatte) und übersprang 1 (Prüfung 4).

Microsoft 365 gegen einen echten Mandanten. Prüfung 4 wurde noch nicht gegen einen echten Mandanten ausgeführt; sie wurde mangels Zugangsdaten übersprungen. Backup und Restore von Microsoft 365 sind nur durch Tests gegen eine simulierte Graph-API abgedeckt. Der Codepfad ist nach der API und dem dokumentierten Graph-Verhalten umgesetzt, und bei seinem ersten echten Lauf sind Korrekturen an Details zu erwarten. Das gilt auch für den Umgang mit deaktivierten, unlizenzierten und gesperrten Konten, OneDrives und Websites (seit 0.4.7), und der Ausschluss von Proxmox-VE-Gästen (seit 0.4.7) lief nicht gegen einen echten Proxmox-VE-Knoten. Das ist der wichtigste Grund, die Beta neben Ihren bestehenden Sicherungen zu betreiben.
Nur das Update vom vorherigen Release. Der Update-Schritt von Prüfung 1 startet die Images des vorherigen Releases mit einem Mandanten und einer Sicherung und stellt sie auf die neuen um. Für 0.1.0 hatte er kein früheres Release als Ausgangspunkt und meldete „nicht ausgeführt“; zum ersten Mal lief er für 0.2.0 und bestand seitdem in jedem Lauf, den von 0.4.7 eingeschlossen. Er probiert nicht jede ältere Version aus: Wenn Sie von 0.2.x kommen, lesen Sie die Update-Hinweise von 0.3.1.
Archiv-Erfassung nur gegen Dovecot und den Empfänger selbst. Prüfung 13 lässt die IMAP-Archivierung gegen Dovecot laufen und weitergeleitete Kopien gegen den Journal-Empfänger. Die Graph-Erfassung gehört nicht zum Smoke-Lauf: Sie wurde nur gegen eine simulierte Graph-API getestet, wie der Rest von Microsoft 365 (Prüfung 4 wird übersprungen). Ein echter Microsoft-365- oder Google-Workspace-Mandant, Postfix, mailcow oder ein Hoster war nicht beteiligt. Siehe die bekannten Probleme der Erfassungswege.
Freigaben nur gegen Samba. Prüfung 12 läuft gegen Samba, über SMB. NFS gehört nicht zum Smoke-Lauf (ein NFS-Server im Container braucht einen privilegierten Kernel-Server, den CI-Runner nicht zuverlässig bereitstellen), und Freigaben wurden nicht gegen Windows Server (NTFS-Berechtigungen, Backup-Operatoren, eine in Excel geöffnete Datei), eine Synology- oder TrueNAS-Freigabe oder einen Host mit aktivem SELinux getestet. Siehe Freigaben: Fehlerbehebung und Grenzen.
Journal-Objekte werden nicht mit ihrer Quelle verglichen. Die Prüfung liest die Journal-Adresse eines Mandanten über GET /api/v1/archive/journal, und keine API liefert die Rohbytes eines archivierten Objekts. Der Export ist daher der Zeuge dafür, dass die Originale unverändert zurückkommen.
Kritische Funde ohne Korrektur. Der Scan kann nichts gegen Kritisches tun, das die Distribution nicht behoben hat (zum Beispiel im Debian-Basisimage). Sie werden aufgelistet, nicht als Fehler gezählt.
Windows und macOS. 0.4.7 hat keinen Windows-Agent. Die Endpunkt-Prüfung (Prüfung 10) führte das echte Install-Skript nur in einem Linux-Container aus. Der macOS-Installer und der Agent gehörten nicht zu den Release-Prüfungen; die eigenen Tests des Agents liefen nativ auf macOS.

Was die CI bei jedem Pull Request prüft

Jeder Pull Request und jeder Push führt Folgendes aus, und ein Release wiederholt alles auf dem getaggten Commit:

Lint und eine Sperre, dass der Kern nie aus den ee/-Modulen importiert,
Typprüfung, Unit-Tests und die Tests gegen ein echtes PostgreSQL, mit einer Sperre, dass keine der PostgreSQL-Suiten übersprungen wurde,
i18n-Vollständigkeit: Jeder Schlüssel der englischen Übersetzung existiert auf Deutsch und umgekehrt,
der vollständige Build und ein Docker-Build beider Images mit einem Blick hinein (restic, restow-restore, die Agent-Prüfsummen, die Image-Labels),
pnpm audit auf hohe und kritische Meldungen,
Abhängigkeitslizenzen gegen eine Positivliste und aktuelle Hinweise zu Drittsoftware,
ein Secret-Scan über die Historie (gitleaks),
der Go-Agent: Formatierung, go vet, Tests mit Race-Detektor, ShellCheck, Integrationstests gegen das echte restic und einen Append-only-REST-Server, das Install-Skript und die Cross-Builds für Linux und macOS,
ShellCheck für jedes Shell-Skript und ein Linter für die Workflows.

Die Pipeline verwendet nur das GITHUB_TOKEN des Laufs: kein persönliches Zugriffstoken und keinen langlebigen Signaturschlüssel. Jede Drittanbieter-Action ist auf einen Commit festgelegt, und jedes Container-Image, das ein Schritt ausführt, ist per Digest festgelegt.

Wo die Prüfungen enden

Ehrlichkeit über die Lücken ist wichtiger als eine lange Liste grüner Prüfungen:

Die erste Agent-Installation vertraut Ihrer Instanz. Das Install-Skript kommt von Ihrer eigenen Restow-Instanz (wie bei jedem curl | sh) und bringt den Release-Schlüssel mit, gegen den es prüft. Vergleichen Sie den Fingerabdruck, den es ausgibt, mit SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o, dem in den Release-Notes veröffentlichten. Danach nimmt der Agent nur noch Updates an, die mit dem in ihn einkompilierten Schlüssel signiert sind.
Die Agent-Binärdateien tragen keine Code-Signatur des Betriebssystems. Die Release-Signatur oben deckt sie ab; eine Apple-Code-Signatur oder Notarisierung gibt es nicht.
Das erste Image, das Sie starten, prüfen Sie selbst. Der optionale Updater prüft die cosign-Signatur jedes Images, das er installiert, aber sein eigenes Image (RESTOW_UPDATER_IMAGE) und die Images Ihrer Erstinstallation prüfen Sie von Hand, wie oben gezeigt. Die Update-Prüfung liest nur die Release-Liste.
Der Quellcode-Modus wird nicht geprüft. Ein Update, das aus einem Repository gebaut wird (der Quellcode-Modus des Updaters, standardmäßig aus), prüft nur die Positivliste und https, nicht den Code. Siehe Updates.
Eine Signatur ist keine Prüfung des Inhalts. Sie belegt, welcher Workflow aus welchem Tag ein Image gebaut hat. Sie ersetzt nicht das Lesen der Release-Notes und den Test einer Wiederherstellung Ihrer eigenen Daten.