Downloads mit cURL und b2sum verifizieren

Tim Koschützki

Mitgründer · Berlin, Deutschland ·

Laden Sie in eine temporäre Datei herunter, vergleichen Sie deren BLAKE2b-Prüfsumme mit dem Wert eines vertrauenswürdigen Herausgebers und erstellen Sie die Zieldatei nur, wenn die Bytes übereinstimmen. Das folgende Bash-Skript kombiniert cURL und b2sum, ohne eine bestehende Datei zu ersetzen. Anschließend zeigt ein Beispiel mit einer echten Release-Prüfsumme den Ablauf.

Die erwartete Prüfsumme vom Herausgeber beziehen

Wenn Sie b2sum auf einen Download anwenden, erhalten Sie dessen aktuelle Prüfsumme. Das sagt Ihnen nicht, wie die Prüfsumme lauten sollte. Beziehen Sie den erwarteten Wert für genau das betreffende Release, die Architektur und den Dateinamen von einem Herausgeber, dem Sie vertrauen, etwa von dessen offizieller HTTPS-Release-Seite oder aus einem Prüfsummenmanifest, dessen Signatur verifiziert wurde. Eine Prüfsumme vom selben nicht vertrauenswürdigen Mirror wie der Download liefert keine vertrauenswürdige Referenz.

GNU b2sum verwendet standardmäßig BLAKE2b-512: 64 Digest-Bytes, dargestellt als 128 Hexadezimalzeichen. Dieses Skript erfordert dieses Format. BLAKE2s, ein kürzerer BLAKE2b-Digest und SHA-256 sind damit nicht austauschbar. Liefert der Herausgeber nur SHA-256, verwenden Sie einen Ablauf zur SHA-256-Verifizierung, statt selbst eine BLAKE2b-Referenz durch Hashen der heruntergeladenen Datei zu erfinden.

Die Linux-Voraussetzungen prüfen

Verwenden Sie einen Linux-Rechner, auf dem GNU Bash, cURL mit HTTPS-Unterstützung und GNU Coreutils bereits installiert sind. Coreutils stellt b2sum, mktemp, ln und rm bereit. Dieses Beispiel wurde mit Bash 5.3.15, cURL 8.22.0 und Coreutils 9.11 getestet; es ist keine Anleitung für macOS oder PowerShell. Prüfen Sie Ihre Werkzeuge:

bash --version && curl --version && b2sum --version

Führen Sie das Skript in einem Verzeichnis aus, das Sie kontrollieren, auf einem Dateisystem mit Hardlink-Unterstützung. Das Ziel ist ein Dateiname in diesem Verzeichnis, kein Pfad in ein anderes Verzeichnis. Leerzeichen und führende Bindestriche sind erlaubt; Schrägstriche, Zeilenumbrüche, . und .. werden abgelehnt. Die Datei wird mit Lese- und Schreibrechten nur für den Eigentümer gespeichert. Bestehende Dateien, Verzeichnisse oder symbolische Links bleiben unangetastet.

Das vollständige Verifizierungsskript speichern

Speichern Sie dies als neue Datei mit dem Namen verify-download.sh. Führen Sie sie mit bash aus. Fügen Sie das Skript nicht in Ihre interaktive Shell ein, denn seine Fehlerausstiege sollen das gespeicherte Programm beenden.

#!/usr/bin/env bash
set -euo pipefail
export LC_ALL=C
umask 077

if (( $# != 3 )); then
  printf 'Usage: bash verify-download.sh HTTPS_URL BLAKE2B_512_HEX FILENAME\n' >&2
  exit 2
fi

url=$1
expected=${2,,}
filename=$3
if [[ ! $expected =~ ^[0-9a-f]{128}$ ]]; then
  printf 'Expected checksum must contain exactly 128 hexadecimal characters.\n' >&2
  exit 2
fi
if [[ $url != https://* ]]; then
  printf 'The download URL must use HTTPS.\n' >&2
  exit 2
fi
if [[ -z $filename || $filename == */* || $filename == . || $filename == .. ||
      $filename == *$'\n'* || $filename == *$'\r'* ]]; then
  printf 'Use a filename without slashes or line breaks.\n' >&2
  exit 2
fi

destination="./$filename"
if [[ -e $destination || -L $destination ]]; then
  printf 'Destination already exists: %s\n' "$destination" >&2
  exit 1
fi

temporary=$(mktemp -d ./.b2-download.XXXXXXXX)
trap 'rm -rf -- "$temporary"' EXIT
if ! curl -q -fsSL --globoff --proto '=https' --proto-redir '=https' \
    --max-redirs 5 --connect-timeout 10 --max-time 300 \
    --output "$temporary/payload" --url "$url"; then
  printf 'Download failed; no file saved.\n' >&2
  exit 1
fi
if ! printf '%s  %s\n' "$expected" "$temporary/payload" |
    b2sum --check --strict --status -; then
  printf 'Checksum mismatch or unreadable download; no file saved.\n' >&2
  exit 1
fi
if ! ln -T -- "$temporary/payload" "$destination"; then
  printf 'Destination exists or cannot be created; no file saved.\n' >&2
  exit 1
fi
printf 'Verified and saved: %s\n' "$destination"

Die Prüfsummeneingabe verwendet das GNU-Format: Digest, zwei Leerzeichen, dann der Dateiname. Das Skript erstellt diesen Datensatz für seine eigenen temporären Nutzdaten, statt lokale Pfade durch ein heruntergeladenes Manifest bestimmen zu lassen. --strict lehnt fehlerhaft formatierte Prüfsummendatensätze ab. Die Argumentprüfung erzwingt vor jeder Übertragung eine Digest-Länge von 512 Bit.

Der letzte Schritt verwendet einen Hardlink, nicht mv: GNU ln -T ohne --force schlägt fehl, wenn das Ziel existiert, auch wenn es erst nach der ersten Prüfung angelegt wird. Da die temporäre Datei im Zielverzeichnis liegt, ist kein Dateisystem-übergreifender Link nötig. Der Exit-Trap entfernt das private temporäre Verzeichnis sowohl bei regulärem Erfolg als auch bei Fehlern. Bei abruptem Abbruch oder Stromausfall kann es zurückbleiben; dies ist kein System zur Wiederherstellung nach Abstürzen.

Ein Release mit veröffentlichter BLAKE2b-Prüfsumme herunterladen

Die Downloadseite von Arch Linux verlinkt das BLAKE2b-Manifest. Verwenden Sie für ein reproduzierbares Beispiel den Bootstrap-Tarball vom 1. September 2026, keine veränderliche „latest“-URL. Dabei wird ein etwa 121 MiB großes Archiv heruntergeladen. Dies ist keine Anleitung, dieses Release zu installieren, zu entpacken oder auszuführen.

Lesen Sie das versionierte Manifest des Herausgebers über HTTPS:

curl -q -fsSL --proto '=https' --proto-redir '=https' --max-time 30 \
  --url 'https://archive.archlinux.org/iso/2026.09.01/b2sums.txt'

Suchen Sie die Zeile, die mit archlinux-bootstrap-2026.09.01-x86_64.tar.zst endet. Kopieren Sie deren erstes Feld, nicht die Prüfsumme der ISO-Datei oder eine lokal erzeugte Prüfsumme. Der folgende Aufruf verwendet diesen veröffentlichten Wert mit 128 Zeichen und speichert den dazu passenden Tarball:

(
  url='https://archive.archlinux.org/iso/2026.09.01/archlinux-bootstrap-2026.09.01-x86_64.tar.zst'
  expected='3893c310ec7d52fd5dee7eec51bc9d611200a5636985c8b627871d1ee85d83821284bcb9a6843afa011a6607ee9ce3202f7e7f5f168f29a07541c0836eeaefd0'
  bash verify-download.sh "$url" "$expected" archlinux-bootstrap-2026.09.01-x86_64.tar.zst
)

Bei Erfolg gibt das gespeicherte Programm Folgendes aus:

Verified and saved: ./archlinux-bootstrap-2026.09.01-x86_64.tar.zst

Erst dann wird die Zieldatei erstellt. Auch eine leere Datei ist gültig, wenn ihre erwartete Prüfsumme übereinstimmt. Das Skript verifiziert Bytes, nicht, ob sie ein brauchbares Archiv bilden.

Fehler einordnen, bevor Sie die Datei verwenden

Prüfsumme stimmt nicht überein: Es wird keine Zieldatei erstellt und der temporäre Download wird entfernt. Prüfen Sie erneut das Release, die Architektur und den vertrauenswürdigen erwarteten Wert. „Beheben“ Sie die Abweichung nicht, indem Sie die Prüfsumme des Downloads selbst als erwarteten Wert verwenden.
HTTP-, TLS- oder Fehler bei unvollständiger Übertragung: cURL schlägt fehl, das Skript gibt einen Rückgabewert ungleich null zurück und unvollständige Nutzdaten werden entfernt. Für die Übertragung gilt ein Zeitlimit von fünf Minuten. Passen Sie es für größere Downloads oder langsamere Verbindungen bewusst an.
Ziel existiert bereits: Das Skript gibt einen Rückgabewert ungleich null zurück und erhält die Bytes des Ziels. Wählen Sie einen anderen Dateinamen, statt einen früheren Download ungeprüft zu löschen.
Fehler beim Bereitstellen der Zieldatei: Eine nicht unterstützte Hardlink-Operation oder ein während der Übertragung erstelltes Ziel verhindert den Erfolg. Verifizierung allein bedeutet nicht, dass die Datei gespeichert wurde.

Die cURL-Optionen machen Übertragungsfehler sichtbar: -f behandelt die meisten HTTP-Fehlerantworten als Fehler, -sS blendet die Fortschrittsanzeige aus, behält aber Diagnosemeldungen bei, und -L folgt Weiterleitungen. Sowohl die Ausgangs-URL als auch Weiterleitungen sind auf HTTPS beschränkt, mit höchstens fünf Weiterleitungen. -q steht an erster Stelle, damit eine lokale curl-Konfiguration die Optionen dieses Befehls nicht unbemerkt ändern kann. Auch reine HTTPS-Weiterleitungen können den Host wechseln; die vertrauenswürdige Prüfsumme bleibt die Referenz auf Byte-Ebene.

Verstehen, was eine übereinstimmende Prüfsumme belegt

Eine Übereinstimmung belegt, dass der Digest dem erwarteten Wert entspricht, nicht, dass die Datei harmlos ist oder von einer bestimmten Person veröffentlicht wurde. In diesem Beispiel ist die Vertrauensbasis die HTTPS-Website des Herausgebers Arch Linux. Kontrolliert ein Angreifer sowohl das Artefakt als auch diese Prüfsummenquelle, kann er beide ersetzen. Um den Herausgeber über diese Vertrauensbasis hinaus zu authentifizieren, folgen Sie dessen Anleitung zur Signaturverifizierung und stellen Sie die Identität des Signaturschlüssels gesondert fest.

Das Skript setzt außerdem voraus, dass andere Prozesse Ihr Arbeitsverzeichnis oder die gespeicherte Datei nicht böswillig verändern können. Es ist eine lokale Downloadprüfung, keine Sandbox und keine Garantie dafür, dass die Bytes nach der Verifizierung unverändert bleiben. Bewahren Sie in einem Workflow zur Medienkatalogisierung die erwartete Prüfsumme zusammen mit ihrer Quelle und den Release-Informationen auf, damit ein späterer Vergleich auf einer nachvollziehbaren Referenz beruht.