Bump aws-nitro-enclaves-image-format to 0.7.0 to pick up sha2 0.10

[Matt (matt-evervault)]

Alternative to #254, following review feedback there.

Approach

#254 got us onto sha2 0.10 by dropping aws-nitro-enclaves-image-format and reimplementing EifHasher::tpm_extend_finalize_reset inline in get_cert_pcr. That means owning the PCR8 calculation ourselves, which is what we least want to hand-maintain.

aws-nitro-enclaves-image-format 0.6.0 (Feb 2026) moved to sha2 = "0.10", and 0.7.0 (Aug 2026) keeps it. Bumping the library gets us off sha2 0.9 with no changes to our hashing code at all.

Changes

• aws-nitro-enclaves-image-format: 0.2.0 → 0.7.0
• sha2: 0.9.9 → 0.10.9
• Cargo.lock regenerated

No source changes — crates/ev-enclave/src/cert/mod.rs is untouched.

PCR8 output is unchanged

I diffed upstream's src/defs/eif_hasher.rs between 0.2.0 and 0.7.0. The only differences:

• an added FixedOutputReset trait bound on EifHasher<T>, required because sha2 0.10 split Digest::finalize_reset out into that trait
• assert_eq!(x, true) → assert!(x) in upstream's own unit tests

initial_digest, the block accumulation in write, and tpm_extend_finalize_reset are byte-for-byte identical:

pub fn tpm_extend_finalize_reset(&mut self) -> IoResult<Vec<u8>> {
    let result = self.finalize_reset()?;
    let mut hasher = self.hasher.clone();

    hasher.write_all(&initial_digest(self.output_size))?;
    hasher.write_all(&result[..])?;
    Ok(hasher.finalize_reset().to_vec())
}

new_without_cache and tpm_extend_finalize_reset keep the same signatures, so get_cert_pcr compiles unchanged and produces identical PCR8 values.

⚠️ Blocked on attestation-doc-validation

aws-nitro-enclaves-image-format 0.6.0+ declares its aws-nitro-enclaves-cose dependency with features = ["key_kms"]. Cargo features are additive and unified across the dependency graph, so enabling it here enables it for every consumer of aws-nitro-enclaves-cose. That adds three variants to CoseError, and attestation-doc-validation matches on it exhaustively:

error[E0004]: non-exhaustive patterns: `CoseError::AwsSignError(_)`,
`CoseError::AwsVerifyError(_)` and `CoseError::AwsGetPublicKeyError(_)` not covered
  --> attestation-doc-validation-0.7.4/src/nsm/error.rs:38:15

I checked the published sources: both 0.7.4 (what we pin) and 0.10.1 (latest) have the exhaustive match, so no released version compiles with key_kms enabled.

The fix is one arm in attestation-doc-validation/src/nsm/error.rs:

             CoseError::SignatureError(inner) => NsmError::SignatureError(inner.to_string()),
+            other => NsmError::UnsupportedError(other.to_string()),
         }

I verified this is the only blocker: with a locally patched attestation-doc-validation 0.7.4 via [patch.crates-io], cargo build and cargo nextest run -p ev-cli -p ev-enclave both pass on this branch. That patch is not committed here.

So the sequence is:

1. land the catch-all arm in attestation-doc-validation and release it
2. bump attestation-doc-validation in this repo to the released version
3. merge this PR

Dependency-tree tradeoff

The key_kms feature pulls in the AWS SDK: aws-config, aws-sdk-kms, aws-sdk-sts/sso/ssooidc, aws-sigv4 and the aws-smithy-* stack.

Net effect on Cargo.lock is 512 → 535 packages (+23). Not a pure addition — the bump also drops stale duplicates that 0.2.0 was holding:

• removed: sha2 0.9.9, digest 0.9.0, block-buffer 0.9.0, clap 3.2.25, clap_lex 0.2.4, crc 1.8.1, build_const, os_str_bytes, strsim 0.10.0, termcolor, winapi-util
• num-derive 0.3.3 → 0.4.2

We lose the duplicate clap 3 and sha2/digest 0.9 trees and gain the KMS SDK. If pulling the KMS SDK into the CLI is the bigger concern, that is worth weighing against #254's approach — happy to go either way.

Version constraints checked

Three constraints in 0.7.0, all fine for us today:

• declares rust-version = "1.94.1". Every CI job uses toolchain: stable and the workspace pins no MSRV; current stable is 1.97.x.
• pins litemap = "=0.7.4" and zerofrom = "=0.1.5". We already resolve to exactly those, so nothing moves.
• caps aws-config <=1.1 and aws-sdk-kms <=1.20. We have no other aws-sdk-* dependencies, so nothing conflicts.

If 1.94.1 is too aggressive an MSRV, 0.6.0 is a drop-in fallback — it also uses sha2 0.10 and declares rust-version = "1.88". It enables key_kms too, so the blocker above applies either way.

Local verification

Run with [patch.crates-io] pointing attestation-doc-validation at a locally patched 0.7.4 (the catch-all arm above). The patch is not part of this branch.

• cargo build — passes
• cargo nextest run -p ev-cli -p ev-enclave --no-fail-fast — 81 tests, 78 passed, 3 failed

The 3 failures are test_choose_output_dir, test_get_eif_size and test_reproducible_enclave_builds_with_pinned_version. All three need a Docker daemon (test_get_eif_size fails with DockerError(DaemonNotRunning)) and there is no Docker on the machine I ran this on. I confirmed they are pre-existing by checking out unmodified main in the same worktree and running just those three: 0 passed, 3 failed, identical. CI provides Docker, so these should pass there.

aws_nitro_enclaves_image_format is imported in exactly one place in the workspace — crates/ev-enclave/src/cert/mod.rs:1 — so nothing else in the tree touches the bumped library.

[ev-vaultkeeper]

Vaultkeeper Commands

Mention @ev-vaultkeeper <command> in a PR review thread:

• review — Review this PR and leave a review.
• address-comments — Push commits that address the review feedback on this PR.
• fix-ci — Investigate the failing CI on this PR and push a fix.

You can also request evervault-dependencies as a reviewer to trigger a review.

[Matt (matt-evervault)]

The prerequisite fix is now up as a draft: evervault/attestation-doc-validation#202 — it adds the catch-all arm to the CoseError → NsmError conversion.

Once that lands and is released, this PR also needs attestation-doc-validation bumped from the currently pinned 0.7.4 to whatever version carries the fix (origin/main there is at 0.10.1, so it will be 0.10.2+).

That looked like it might be a painful three-minor-version jump, but the API surface we actually use is unchanged between 0.7.4 and 0.10.1 — error::AttestationError, attestation_doc::PCRs, PCRProvider, validate_attestation_doc_against_cert and validate_expected_pcrs are all identical, and the PCRs struct fields are the same. The notable break in that range is CertError::UntrustedCert → CertError::InvalidTrustChain(_), which we do not match on. So the bump should be mechanical, though it still needs a real compile to confirm.