fix(dialect): compute pinned dialect hash from canonical bytes #5

Merged

hugooconnor merged 0 commits from refs/pull/5/head into main 2026-07-15 06:24:48 +00:00

Conversation 0 Commits - Files changed -

hugooconnor commented 2026-07-15 06:23:13 +00:00 (Migrated from codeberg.org)

Copy link

Problem

./release.sh failed cutting v0.1.1 because core::dialect::tests::dialect_hash_is_pinned panicked:

thread '...dialect_hash_is_pinned' panicked at src/core/dialect.rs:58:38:
hash computed on install

The test read d.hash, which cbcl-core only populates from a self-declared (hash "...") field in the .cbcl file. The vendored cbcl-elephant.cbcl declares none, so d.hash was None and .expect("hash computed on install") panicked. cbcl-core never computes a hash on install, so this test could not pass as written.

Fix

PINNED_DIALECT_HASH is a sha256 over cbcl-rs's canonical dialect bytes (the same bytes used for signing) — which is why elephant depends on sha2 and cbcl-core exposes dialect_canonical_bytes. This adds a dialect_hash() helper that recomputes that hash from content and compares it against the pin.

The test now does what its own comment always claimed: a silent change to the vendored file or to cbcl-rs canonicalisation breaks the build visibly — and it no longer trusts a self-declared field a tamperer could just edit. The pinned value sha256:9042… matches the computed canonical hash unchanged, confirming it was correct all along.

Cargo.lock: cbcl-core no longer depends on sha2 (sibling path-dep regeneration).

Verification

cargo test --lib   → 141 passed, 1 ignored

The v0.1.1 version bump is intentionally not in this branch — ./release.sh owns versioning/tag/push and can be re-run cleanly once this merges.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q6GBsN4CfVF7QXAycnK2ip

## Problem `./release.sh` failed cutting v0.1.1 because `core::dialect::tests::dialect_hash_is_pinned` panicked: ``` thread '...dialect_hash_is_pinned' panicked at src/core/dialect.rs:58:38: hash computed on install ``` The test read `d.hash`, which cbcl-core only populates from a self-declared `(hash "...")` field in the `.cbcl` file. The vendored `cbcl-elephant.cbcl` declares none, so `d.hash` was `None` and `.expect("hash computed on install")` panicked. cbcl-core never computes a hash on install, so this test could not pass as written. ## Fix `PINNED_DIALECT_HASH` is a `sha256` over cbcl-rs's **canonical** dialect bytes (the same bytes used for signing) — which is why elephant depends on `sha2` and cbcl-core exposes `dialect_canonical_bytes`. This adds a `dialect_hash()` helper that recomputes that hash from content and compares it against the pin. The test now does what its own comment always claimed: a silent change to the vendored file *or* to cbcl-rs canonicalisation breaks the build visibly — and it no longer trusts a self-declared field a tamperer could just edit. The pinned value `sha256:9042…` matches the computed canonical hash unchanged, confirming it was correct all along. `Cargo.lock`: cbcl-core no longer depends on `sha2` (sibling path-dep regeneration). ## Verification ``` cargo test --lib → 141 passed, 1 ignored ``` The v0.1.1 version bump is intentionally **not** in this branch — `./release.sh` owns versioning/tag/push and can be re-run cleanly once this merges. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Q6GBsN4CfVF7QXAycnK2ip

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

anuna-research/elephant!5

No description provided.