Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/en/RELEASE-RECORD-CONTRACT.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Out of scope, kept as separate, later work (the trust gates): the external trust
* **Source commit**: the git commit the release is made from, `provenance.source_commit`.
* **Artifact**: a file, identified by its path in the tree of the source commit, that the record releases.
* **Blob bytes**: the content of the git blob at that path in the source commit, exactly as stored (no filter, no line-ending conversion, no normalization).
* **Digest**: `sha256:` followed by 64 lowercase hexadecimal digits, the SHA-256 of the blob bytes. This is the form of the receipt fields (`primitive_build_hash`, `grammar_sha256`), so a consumer needs no re-encoding for the new fields. The algorithm is carried in the value itself.
* **Digest**: `sha256:` followed by 64 lowercase hexadecimal digits, the SHA-256 of the blob bytes. This is the form the digest fields of a receipt take (`sha256:` and 64 lowercase hex), so a consumer needs no re-encoding of an `artifacts` digest. It holds for the `artifacts` digests **only**: `release.build_hash`, `provenance.grammar_sha256`, `provenance.grammar_schema_sha256`, `provenance.dependency_lock_sha256` and `specs[].meta_hash` remain base64 SHA-256 (the legacy form, below), so a receipt field that takes one of them needs the conversion that the consumer's own contract defines; this contract does not define it. The algorithm of an `artifacts` digest is carried in the value itself.

## 4. Envelope 3

Expand Down
2 changes: 1 addition & 1 deletion docs/hu/RELEASE-RECORD-CONTRACT.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Az angol változat (`docs/en/RELEASE-RECORD-CONTRACT.md`) a normatív forrás; e
* **Cél.** A fogyasztó a release rekordból magából ellenőrizhesse, hogy a release pontosan a pinelt bájtokat tartalmazza. Az envelope 2-ben a rekord csak a séma-forrásokat és két grammar-fájlt digesteli (base64); a többi a `source_commit`-ra támaszkodik, ami `null` is lehet. A tulajdonos döntése (2026-11-01): a rekord minden artifactról saját digestet és algoritmust hordoz; a `source_commit` kötelező marad, de nem helyettesíti a digesteket.
* **Hatókör.** A rekord állításai a kiadott fájlokról, kódolásuk és az elutasítás feltételei. Nincs benne: trust anchor, aláíró jogosultsága, tanúsítvány-érvényesség, manifest-eredet, hitelesség. Az aláírási mechanizmus nem változik. Ennek a szerződésnek a teljesítése nem jelent hitelességet.
* **A compiler nem a fogyasztótól tanulja, mit digesteljen.** Az artifact-halmazt a termelő deklarálja a `project.yaml`-ban, **kizárólag explicit, repo-gyökérhez viszonyított fájlútvonalakkal** (`compiler_settings.release_artifacts.paths`); az első verzióban nincs glob, `include` vagy `exclude` (az később, külön verziózott bővítés lehet). Az útvonalak kizárólag a `source_commit` Git-fájából oldódnak fel, nem a munkakönyvtárból; a fogyasztó pin-manifestjét a compiler nem olvassa. Hiányzó deklaráció, üres lista, nem szabályos (abszolút, `..`, `.`, üres szegmens, visszaper, NUL), duplikált vagy a fában nem található útvonal, valamint könyvtár, szimbolikus link vagy submodule: a compiler elutasít (`declaration_*`, `declared_path_*`). A fogyasztó a saját követelményét ellenőrzi a halmaz ellen.
* **Rekord (envelope 3).** `provenance.source_commit`: 40 kisbetűs hex, kötelező, sosem `null`. `artifacts.files[]`: `{path, digest}` útvonal szerint bájtsorrendben rendezve, egyedi útvonalakkal; `digest` = `sha256:` + 64 kisbetűs hex, a git blob nyers bájtjainak SHA-256-ja szűrés és normalizálás nélkül. `artifacts.manifest_digest`: a `sha256sum` formátumú sorok SHA-256-ja. A forma azonos a receipt mezőivel, ezért a fogyasztónak nem kell átkódolnia. A `build_hash` az envelope 2 szabálya szerint a teljes csomagot fedi, tehát az új tagokat a meglévő aláírás is köti; ez a lefedettség követelmény, amíg a 12. szakasz golden vektorai nem bizonyítják, nem bizonyított tulajdonság.
* **Rekord (envelope 3).** `provenance.source_commit`: 40 kisbetűs hex, kötelező, sosem `null`. `artifacts.files[]`: `{path, digest}` útvonal szerint bájtsorrendben rendezve, egyedi útvonalakkal; `digest` = `sha256:` + 64 kisbetűs hex, a git blob nyers bájtjainak SHA-256-ja szűrés és normalizálás nélkül. `artifacts.manifest_digest`: a `sha256sum` formátumú sorok SHA-256-ja. A forma azonos a receipt digest-mezőinek formájával, ezért az `artifacts` digesteket a fogyasztónak nem kell átkódolnia. Ez **csak** az `artifacts` digesteire igaz: a `release.build_hash`, a `provenance.grammar_sha256`, a `provenance.grammar_schema_sha256`, a `provenance.dependency_lock_sha256` és a `specs[].meta_hash` base64 SHA-256 marad (a régi forma), így az a receipt-mező, amely ezek egyikét veszi át, a fogyasztó saját szerződése szerinti átalakítást igényli; ezt ez a szerződés nem határozza meg. A `build_hash` az envelope 2 szabálya szerint a teljes csomagot fedi, tehát az új tagokat a meglévő aláírás is köti; ez a lefedettség követelmény, amíg a 12. szakasz golden vektorai nem bizonyítják, nem bizonyított tulajdonság.
* **Útvonal-karakterkészlet.** Az útvonal nem tartalmazhat vezérlőkaraktert (U+0000–U+001F, U+007F; LF, CR, TAB, NUL is tiltott), mert a manifest soralapú, és egy sortörés az útvonalban kétértelművé tenné a sorhatárt. Új manifest-formátum nem kell; a hiba `artifact_path_form`, illetve a compilerben `declaration_path_form`.
* **Egyediség.** Az `artifacts.files[].path` és a `specs[].source_path` egyedi; a verifier elutasítja a duplikátumot, nem engedi, hogy a későbbi felülírja a korábbit. A rendezetlen listát elutasítja, nem rendezi csendben.
* **Legacy envelope 1.** Az a rekord legacy envelope 1, és csak az, amelyben nincs `provenance` tag, a `release` leképezés `envelope` nélkül, és a `release.build_hash` és `release.sign` nem üres szöveg (pl. `release/cic-primitives-v0.1.5.yaml`): `envelope_too_old`. Más, mindkét envelope-mezőt nélkülöző rekord `envelope_unsupported`; pontosan az egyik hiánya `envelope_mismatch`. **Hiányzó `cic_countersign`:** nem elutasítás és nem siker; a verifier `INCOMPLETE`-nek jelenti, és egy későbbi, ellenjegyzést előíró release-policy nem teljesül tőle.
Expand Down
Loading