Track dependency audit and clean up stale CDK lock state #1

New issue

Open

opened 2026-07-16 23:11:31 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-16 23:11:31 +01:00

Collaborator

So that I can use cdk-ehash as a clean Hashpool dependency, track the dependency-audit result and fix the current lock/patch mismatch instead of assuming there are SRI crates to bump.

Context

A fresh audit on 2026-07-16 found no SRI/SV2 crates in cdk-ehash. The manifest depends on CDK and ordinary async/serde/error crates only:

Dependency family	Current manifest	Current upstream	Notes
`cdk-common`	`0.16.0`	`0.17.3`	production dependency with `mint` feature
`cdk`	`0.16.0`	`0.17.3`	dev dependency
`cdk-sqlite`	`0.16.0`	`0.17.3`	dev dependency
SRI/SV2 crates	none	n/a	no `*_sv2`, `stratum-core`, `stratum-apps`, or `sv1_api` deps

The current dependency state is also inconsistent under a locked Cargo audit. cargo metadata --manifest-path Cargo.toml --format-version 1 --locked fails because Cargo.toml asks for CDK 0.16.0, while Cargo.lock and the [patch.crates-io] git rev still contain CDK packages at 0.15.1 from https://github.com/cashubtc/cdk?rev=742285cd.

Cargo reports the CDK patch entries are not used and that the lock file needs to be updated.

Scope

Decide whether this repo should stay on CDK 0.16.0 or move to the current CDK release line.
Update Cargo.lock so locked metadata/check/test commands are reproducible.
Remove the [patch.crates-io] block if it is no longer needed, or update it to a rev whose package versions satisfy the selected manifest requirements.
Update the README dependency note if the selected CDK version changes.
Record explicitly that no SRI crate bump is required in cdk-ehash unless a future Hashpool integration adds SV2/SRI dependencies here.

Validation

cargo metadata --manifest-path Cargo.toml --format-version 1 --locked
cargo check --locked
cargo test --locked

Boundaries

Do not add SRI/SV2 dependencies to this crate as part of the cleanup. Hashpool's SRI protocol bump is tracked in vnprc/hashpool issue #1.

So that I can use `cdk-ehash` as a clean Hashpool dependency, track the dependency-audit result and fix the current lock/patch mismatch instead of assuming there are SRI crates to bump. ## Context A fresh audit on 2026-07-16 found no SRI/SV2 crates in `cdk-ehash`. The manifest depends on CDK and ordinary async/serde/error crates only: | Dependency family | Current manifest | Current upstream | Notes | | --- | ---: | ---: | --- | | `cdk-common` | `0.16.0` | `0.17.3` | production dependency with `mint` feature | | `cdk` | `0.16.0` | `0.17.3` | dev dependency | | `cdk-sqlite` | `0.16.0` | `0.17.3` | dev dependency | | SRI/SV2 crates | none | n/a | no `*_sv2`, `stratum-core`, `stratum-apps`, or `sv1_api` deps | The current dependency state is also inconsistent under a locked Cargo audit. `cargo metadata --manifest-path Cargo.toml --format-version 1 --locked` fails because `Cargo.toml` asks for CDK `0.16.0`, while `Cargo.lock` and the `[patch.crates-io]` git rev still contain CDK packages at `0.15.1` from `https://github.com/cashubtc/cdk?rev=742285cd`. Cargo reports the CDK patch entries are not used and that the lock file needs to be updated. ## Scope - Decide whether this repo should stay on CDK `0.16.0` or move to the current CDK release line. - Update `Cargo.lock` so locked metadata/check/test commands are reproducible. - Remove the `[patch.crates-io]` block if it is no longer needed, or update it to a rev whose package versions satisfy the selected manifest requirements. - Update the README dependency note if the selected CDK version changes. - Record explicitly that no SRI crate bump is required in `cdk-ehash` unless a future Hashpool integration adds SV2/SRI dependencies here. ## Validation - `cargo metadata --manifest-path Cargo.toml --format-version 1 --locked` - `cargo check --locked` - `cargo test --locked` ## Boundaries Do not add SRI/SV2 dependencies to this crate as part of the cleanup. Hashpool's SRI protocol bump is tracked in vnprc/hashpool issue #1.

vnprc-agent referenced this issue

2026-07-16 23:30:35 +01:00

Align cdk-ehash with Hashpool CDK patch #2

vnprc-agent referenced this issue

2026-07-17 00:10:49 +01:00

Align cdk-ehash with Hashpool CDK patch #3