chore(deps)(deps): bump sha2 from 0.10.9 to 0.11.0

[dependabot]

Bumps sha2 from 0.10.9 to 0.11.0.

Commits

• ffe0939 Release sha2 0.11.0 (#806)
• 8991b65 Use the standard order of the [package] section fields (#807)
• 3d2bc57 sha2: refactor backends (#802)
• faa55fb sha3: bump keccak to v0.2 (#803)
• d3e6489 sha3 v0.11.0-rc.9 (#801)
• bbf6f51 sha2: tweak backend docs (#800)
• 155dbbf sha3: add default value for the DS generic parameter on TurboShake128/256...
• ed514f2 Use published version of keccak v0.2 (#799)
• 702bcd8 Migrate to closure-based keccak (#796)
• 827c043 sha3 v0.11.0-rc.8 (#794)
• Additional commits viewable in compare view

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[nikhilunni]

@dependabot recreate

[github-actions]

Auto-approved: version-update:semver-minor via Dependabot.

[nikhilunni]

@dependabot rebase

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[nikhilunni]

@claude please fix the failing CI on this PR. The Dependabot bump from sha2 0.10.9 to 0.11.0 has API/trait-bound changes that broke our hashing call sites. Investigate the cargo compile errors across the failing checks and push fix commits — keep the dep bump intact, adjust the call sites only.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[dependabot]

Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot recreate.

[dependabot]

Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot recreate.

[nikhilunni]

@dependabot recreate

[engrams-agent]

✅ engrams review — complete. 0 findings posted. · View details

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[engrams-agent]

Engrams review

Verdict: No findings.
Severity: Critical 0 · High 0 · Medium 0 · Low 0

View the full engrams review

[nikhilunni]

@dependabot recreate

[engrams-agent]

⚠️ engrams review — the run failed. It will retry on the next push or @mention.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[engrams-agent]

✅ engrams review — complete. 0 findings posted. · View details

[engrams-agent]

Migrated and green locally — ready for review

I took ownership of this branch in today's dependency sweep and pushed the
migration on top of Dependabot's commit (the updated-dependencies: trailer,
changelog and compatibility score are all intact). I also rebased the branch
onto current main, because its base was behind and the harness fix in #977
matters for local verification — see the note at the end.

What upstream changed

sha2 0.11 moves the RustCrypto stack from generic-array to hybrid-array.
The digest output type changes:

sha2 0.10:  Output<Sha256> = generic_array::GenericArray<u8, U32>   // impls LowerHex
sha2 0.11:  Output<Sha256> = hybrid_array::Array<u8, U32>           // does NOT impl LowerHex

Array has no LowerHex, so every format!("{:x}", digest) in the workspace
stops compiling. That is the entire breakage — 16 sites in 8 crates. Nothing
about the hashing itself changed.

What I migrated

Each {:x} became hex::encode, which emits the same lowercase,
two-digits-per-byte string:

- let squashfs_sha256 = format!("{:x}", Sha256::digest(&squashfs));
+ let squashfs_sha256 = hex::encode(Sha256::digest(&squashfs));

- let digest = format!("sha256:{:x}", sha2::Sha256::digest(&bytes));
+ let digest = format!("sha256:{}", hex::encode(sha2::Sha256::digest(&bytes)));

Sites: engram-core (cold-base content key), engram-oci (blob/manifest
digests, sha256_digest), engram-host-agent (bundle verify), engram-coordinator
(harness catalog, skill packs), plus fixtures in engram-rootfs-materializer,
engram-sandbox-firecracker and the two OCI test registries.

hex is promoted to a workspace dependency. It was already a direct
dependency of engram-egress-proxy and already in Cargo.lock at 0.4.3, so no
new code enters the build graph — only new edges to an existing node. I chose
this over a hand-rolled helper because engram-oci does not depend on
engram-core, so there is no single existing crate every call site can reach.

The content-addressing tests pass, unmodified

This is the part worth stating explicitly for a hashing dependency. Both
known-answer tests in crates/engram-chunk-store/src/manifest.rs pass with
their literals untouched:

PASS engram-chunk-store manifest::tests::chunk_hash_is_sha256_of_the_bytes
PASS engram-chunk-store manifest::tests::content_ref_never_moves
PASS engram-oci        tests::sha256_digest_is_stable
PASS engram-chunk-store bootstrap::tests::build_per_chunk_addresses_each_chunk_by_its_own_digest

So sha2 0.11 computes the same SHA-256 as 0.10 over the same framing, and
disk_manifest_content_ref values already in Postgres and in every published
bundle.json still match what this code computes. No chunk or manifest
reference moves. I did not touch either test.

ChunkHash::to_hex is also deliberately unchanged — it hand-rolls the same
encoding over a [u8; 32] and never depended on LowerHex, so the
content-addressing core needed no edit at all.

What a reviewer should look at closely

1. hex as a workspace dependency is the one judgement call here. If you
   would rather not widen the dependency surface on a bump PR, the alternative
   is a shared helper — but it needs a home both engram-core and
   engram-oci can reach, which does not exist today.
2. engram-oci/src/docker_image.rs:303 is inside the resumed-blob verify
   path (finalize_reset). The rewrite is mechanical, but it is the one site
   where a wrong digest string would silently retry a pull rather than fail
   loudly.
3. digest 0.10.7 is still in the lockfile transitively. That is expected and
   harmless: we declare no other RustCrypto crate directly and there is no
   Hmac<Sha256>, so nothing needs to move in lockstep.

Verification

just check equivalent, run locally on the rebased branch:

• cargo fmt --all -- --check — clean
• cargo clippy --workspace --all-targets -- -D warnings — clean, no new
  #[allow]
• cargo hakari verify — workspace-hack works correctly
• cargo nextest run --workspace --no-fail-fast — 2380 tests, 2363 passed

17 tests fail in this sandbox (engram-harness-codex ×15, engram-agentd ×1,
engram-sandbox-process ×1). I confirmed the failing set is byte-identical
on pristine main, so they are pre-existing and environmental — they spawn
real child processes, which the session VM does not support. Zero regressions
from this change. CI is the authority on those lanes.

One thing worth flagging: three engram-harness-claude tests failed before I
rebased and pass after. The cause was the older base, not this bump — #977
("confine per-session state to one injectable state dir") is what fixes them
when ENGRAM_APPEND_SYSTEM_PROMPT is set. Any other Dependabot branch based
before #977 will show the same three failures.

[engrams-agent]

Engrams review

Verdict: No findings.
Severity: Critical 0 · High 0 · Medium 0 · Low 0

View the full engrams review

[engrams-agent]

Campaign checkpoint — blocked on a coupling that was not visible before today

I own this branch across runs. Reporting what changed, because the conclusion
in my previous comment is now wrong and I want that on the record rather
than buried.

What I said last time, and why it no longer holds

That comment ended with:

digest 0.10.7 is still in the lockfile transitively. That is expected and
harmless: we declare no other RustCrypto crate directly and there is no
Hmac<Sha256>, so nothing needs to move in lockstep.

That was true when written. It is not true now. main has since gained a
direct hmac dependency — Cargo.toml:270 (hmac = "0.12") and
crates/engram-coordinator/Cargo.toml — landed with the connector OAuth work,
and it uses exactly the construct I said did not exist:

// crates/engram-coordinator/src/oauth_redirect.rs:314
let mut mac = Hmac::<Sha256>::new_from_slice(client_secret.as_bytes())

The coupling, proven both directions

sha2 and hmac sit on a shared digest / crypto-common generation:

	digest	crypto-common
sha2 0.10.9 / hmac 0.12.1	0.10.7	0.1.7
sha2 0.11.0 / hmac 0.13.0	0.11.3	0.2.2

Hmac::<Sha256> needs its Sha256 to implement the same digest crate's
traits. I rebased this branch onto current main and compiled it:

error[E0599]: the associated function or constant `new_from_slice` exists for
struct `CoreWrapper<HmacCore<Sha256>>`, but its trait bounds were not satisfied
   --> crates/engram-coordinator/src/oauth_redirect.rs:314:35
    |
314 |     let mut mac = Hmac::<Sha256>::new_from_slice(client_secret.as_bytes())
    |                                   ^^^^^^^^^^^^^^
    = note: `CoreWrapper<HmacCore<Sha256>>: hmac::digest::Update`
            which is required by `CoreWrapper<HmacCore<Sha256>>: hmac::Mac`

So this PR can no longer go green on its own, and neither can #1031
(hmac 0.13 alone), for the mirror-image reason. The pair is the smallest
buildable unit.

Then I bumped both together on a scratch branch. The trait-bound wall is gone
and what is left is a single mechanical error:

error[E0599]: no associated function named `new_from_slice` found for struct `Hmac<D>`
help: trait `KeyInit` which provides `new_from_slice` is implemented but not in scope
    |
 18 + use hmac::KeyInit;

hmac 0.13 stopped re-exporting KeyInit through Mac. One import. That is the
entire additional migration cost of moving the pair.

Why I am not just folding hmac into this branch

One dependency per branch. Folding the two bumps into one Dependabot branch
would also discard #1031's own updated-dependencies: trailer, changelog and
compatibility score. This repo already has the right pattern for a
version-locked family — the grpc group in dependabot.yml, whose comment says
it plainly:

Individual major PRs for these crates can NEVER go green — so "one crate at a
time" is not a reviewable unit here, it is an unbuildable one.

Done this run

#1046 adds a rustcrypto-digest group (sha2, hmac, digest, majors
included) and adds those three to cargo-minor-patch's exclude-patterns so
first-match ordering cannot split the pair via a lone sha2 patch. Once that
lands, Dependabot re-proposes the two as one PR, which is the first version
of this bump that can actually be green.

The digest evidence still stands

This is a hashing dependency, so restating it: the known-answer tests passed
with their literals untouched on the pre-coupling build, and I did not edit
either one:

PASS engram-chunk-store manifest::tests::chunk_hash_is_sha256_of_the_bytes
PASS engram-chunk-store manifest::tests::content_ref_never_moves
PASS engram-oci         tests::sha256_digest_is_stable

sha2 0.11 computes the same SHA-256 over the same framing, so no chunk or
manifest reference moves and stored disk_manifest_content_ref values still
match. engram-chunk-store does not depend on hmac, so the coupling above
does not affect that evidence — but I have not re-run the full workspace
gate on the coupled pair yet, and I am not claiming green until I have.

What the next run does first

1. Confirm dependabot: close three config gaps this sweep exposed #1046 merged and the rustcrypto-digest group is live.
2. Land the PKCE known-answer test below on main before the pair bumps.
3. Take the grouped sha2+hmac PR: rebase, add use hmac::KeyInit;, carry over
   the 16 format!("{:x}", digest) → hex::encode migrations already on this
   branch, run the full just check, verify the two digest tests plus the new
   PKCE test, then enqueue.
4. Close this PR and chore(deps)(deps): bump hmac from 0.12.1 to 0.13.0 #1031 as superseded by that grouped PR — do not close
   them before it exists.

The one real hazard, and the test that pins it

derive_pkce_verifier (oauth_redirect.rs:313) is recomputed, not
persisted — the docstring says so: "recomputable on any replica from the
client secret + flow id, so oauth_flows keeps its no-codes-at-rest
invariant." An in-flight consent flow only completes if every pod derives the
same bytes. If a digest-crate change moved that output, live flows would break
on a rolling deploy.

The existing test only checks determinism and secret-dependence:

let a = derive_pkce_verifier("secret-a", flow);
assert_eq!(a, derive_pkce_verifier("secret-a", flow));
assert_ne!(a, derive_pkce_verifier("secret-b", flow));

Every one of those still passes if the bytes move, as long as they move
consistently. So the regression would be silent. HMAC-SHA256 is HMAC-SHA256 and
I do not expect any change — but "I do not expect it" is not a test. Computed
from an independent implementation (Python hmac/hashlib), so it pins the
algorithm rather than whatever the current crate happens to emit:

#[test]
fn pkce_derivation_is_hmac_sha256_of_the_framing() {
    let flow = uuid::Uuid::parse_str("10600000-0000-4000-8000-000000000021").unwrap();
    let verifier = derive_pkce_verifier("secret-a", flow);
    assert_eq!(verifier, "R8IOB9xpKznAUFbKQKINVF1IOiolYNo2S-5YbgUDVDc");
    assert_eq!(
        pkce_challenge(&verifier),
        "IA9MPT0_Cos-8yoetow-s2AsvTR7CWIotS62jDRQSd0"
    );
}

I have not landed this yet — I could not get a clean run of it inside this
session's remaining build budget, and I will not assert a test passes that I
have not watched pass. It goes in on main first next run, so the pair bump has
to clear it.

[dependabot]

Superseded by #1059.