release: define and prove the first honest dev-preview release #181

Activity

1. 0monish

   added

   foundationOpen-source foundation readiness and its evidenceOpen-source foundation readiness and its evidence

   on Sep 7, 2026
2. amishabenramani commented on Sep 16, 2026

   

   amishabenramani

   on Sep 16, 2026 – with ChatGPT Codex Connector

   Member

   More actions

   2026-09-16 release-scope preflight — no release publication yet

   The current dependency state supports only a future source-preview candidate, not a binary-distribution claim:

   • Signed macOS prebuilt-host work is still a draft/in-progress spec (KEL-103); it explicitly does not authorize installers or notarization execution.
   • The canonical package/update filesystem contract (KEL-137) is still In Progress; executable modes, links/metadata and hostile extraction cases are not yet closed.
   • No-Rust macOS prebuilt CLI/host distribution (KEL-141) remains backlog/blocked on its owning specs and requires real clean-machine arm64 evidence.

   Therefore this issue should not create a DMG/installer/tag merely to satisfy readiness. After foundation prerequisites #177/#179/#180 are complete, the smallest honest preview scope is:

   1. pin one reviewed Keld source commit;
   2. label it explicitly source preview / pre-alpha;
   3. reproduce the documented source build + keld create / doctor / dev path on the exact platforms actually claimed;
   4. publish release notes/known limits from landed facts only;
   5. attach no binary artifact unless its separate packaging/signing/clean-machine acceptance has completed.

   Binary distribution remains a later release scope behind KEL-103/KEL-137/KEL-141 and their real-machine evidence. No tag or release is being created by this comment.
3. amishabenramani commented on Oct 5, 2026

   

   amishabenramani

   on Oct 5, 2026

   Member

   More actions

   Requirement from the KEL-19 ExpectedAppIdentity container spec (PR #382, owner-approved 2026-10-06)

   The authenticated Keld release channel that docs/specs/kel254-expected-identity-container.md (atom 12, §6 T3, §10) requires is tracked on this issue. The owner directed that work with no nearby Linear issue be tracked in GitHub issues.

   What the release must publish: for each claimed Windows target, the unsigned packaging-input keld-host.exe and its SHA-256 digest. Both must come from a channel that keld build can authenticate.

   How keld build uses them: it verifies that digest before embedding the app's ExpectedAppIdentity (spec AC12). If the digest is mismatched, missing, or fails channel authentication, it refuses before embedding.

   Why the input is unsigned: the app publisher applies the only Authenticode signature, after the identity has been embedded.

   Open decisions for this issue:

   • how the digest is authenticated: for example, a manifest signed with a Keld release key, or a build-provenance attestation, and how keld build pins that trust root;
   • distribution: GitHub Releases and/or the npm binary resolver (@keld/cli);
   • rollback and revocation of a published host.

   What this blocks: only the container spec's T3 (the keld build integration). T1 (the writer and reader), T2 (the signed-coverage proof) and KEL-96 T3 Part B (installed boot) do not depend on it.

   Related: Linear KEL-19 (comments eebf7987, 9ac5ecb2), KEL-254, KEL-270 D4.