---
title: "Release-Provenance und Integrität"
manual: "HTTP Guard"
version: "0.1.4"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-http-guard:release-provenance@0.1.4"
source: "Development/ReleaseProvenance.rst"
rendered: "2026-10-18T14:31:43+00:00"
---

# Release-Provenance und Integrität {#release-provenance}

## Veröffentlichtes und geprüftes Alpha-Release {#release-provenance-existing}

[v0.1.1](https://github.com/netresearch/typo3_http_guard/releases/tag/v0.1.1)
gehört zum signierten Tag und Quellcommit
`3997089a259b6b919eed4e6c3bf7f6715b948ad1`. Die zehn Assets bestehen
aus zwei Quellarchiven, zwei SBOMs, `checksums.txt` und den fünf
passenden Sigstore-Bundles. TER und Packagist führen Version 0.1.1.

Der ursprüngliche Publisher erzeugt Release und Registry-Pakete, endet aber
mit einer fehlerhaften Verifikationsanweisung. Der korrigierte
[Verifikationslauf 37964411091](https://github.com/netresearch/typo3_http_guard/actions/runs/37964411091)
besteht gegen den ursprünglichen Publisher. Seine Veröffentlichungsjobs
werden übersprungen; kein vorhandenes Asset wird ersetzt. Daraus wird
kein erfolgreicher Abschluss des ursprünglichen Gesamtworkflows abgeleitet.

Der Lauf prüft fünf Keyless-Blob-Signaturen, die vier Ziele des signierten
Checksum-Manifests und die Provenance beider Archive. Die regulären Dateien
werden nach Entfernung des bekannten `nr-http-guard/`-Präfixes mit
dem kanonischen Quellmanifest verglichen. Der dokumentierte Release-Nachweis
enthält 131 übereinstimmende Dateien in ZIP, TAR und TER-Paket.

## Vorhandenes Release prüfen {#release-provenance-commands}

Die Signatur wird geprüft, bevor dem Checksum-Manifest vertraut wird.
Cosign und GitHub CLI sind externe Prüfwerkzeuge. Die folgenden Befehle
installieren und starten keine Extension-Dateien.

**Vorhandene v0.1.1-Assets herunterladen**

```bash
gh release download v0.1.1 \
    --repo netresearch/typo3_http_guard \
    --dir http-guard-0.1.1
cd http-guard-0.1.1
```

**ZIP-Signatur und signiertes Checksum-Manifest prüfen**

```bash
cosign verify-blob \
    --bundle nr-http-guard-0.1.1.zip.sigstore.json \
    --certificate-identity "https://github.com/netresearch/typo3-ci-workflows/.github/workflows/release-typo3-extension.yml@refs/heads/main" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
    nr-http-guard-0.1.1.zip
cosign verify-blob \
    --bundle checksums.txt.sigstore.json \
    --certificate-identity "https://github.com/netresearch/typo3-ci-workflows/.github/workflows/release-typo3-extension.yml@refs/heads/main" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
    checksums.txt
sha256sum --strict --check checksums.txt
```

Für TAR und jede SBOM wird die Blob-Prüfung mit ihrem eigenen Dateinamen
und passenden Bundle wiederholt. Eine passende Checksum allein bestätigt
nicht die Identität des Signierenden.

Der Workflow bindet die Archiv-Attestations zusätzlich an Quelldigest,
Tag, Zertifikatsidentität und den tatsächlich aufgelösten Digest des
ursprünglichen wiederverwendeten Signierworkflows. Selbst gehostete Runner
werden abgelehnt. Vertrauenswürdiger Verifier-Code liest die alte
Releasequelle nur als Paketdaten. Die genaue Prüfung steht in
[release.yml](https://github.com/netresearch/typo3_http_guard/blob/main/.github/workflows/release.yml).

## Umfang von Provenance und SBOM {#release-provenance-scope}

Das signierte SLSA-v1-Statement bindet **die beiden Quellarchive** an Quelle,
Tag und Builder. Es attestiert nicht die SBOMs. Eine projektgesteuerte
Ausführung mit signierter Provenance belegt für sich keinen isolierten
SLSA-Level-3-Build und keine entsprechende Zertifizierung.

Die Release-SBOMs in SPDX und CycloneDX sind ergänzende Repositoryinventare.
Sie sind weder aufgelöste PHP-/TYPO3-Abhängigkeitsgraphen noch reine
Archivdateiinventare. Die separaten Security-Jobs erstellen je Core-Major
einen tatsächlichen Produktionsgraphen mit Lock, Audit und CycloneDX-SBOM;
siehe [Gepatchte Core-Graphen](https://docs.typo3.org/permalink/netresearch/nr-http-guard:dependency-report-current@0.1.4).

Eine gültige Signatur belegt weder TER-/Packagist-Veröffentlichung noch
ein freigegebenes Onlinehandbuch. Die Registries sind für 0.1.1 separat
bestätigt. Die Intercept-Handbücher warten auf externe Freigabe; ihre
EN-/DE-Quellen liegen bereits im Paket. Menschliches Security-Review,
Betreiberpilot und OpenSSF-Stufen werden nicht aus Signaturen abgeleitet.