chore(deps): update rust crate hkdf to 0.13 #37

kodus-27b · 2026-10-26T13:10:05Z

WHAT: The hkdf dev-dependency moves from 0.12 to 0.13 (a semver-breaking bump for 0.x crates) with no visible audit or SCA evidence. WHY: This is a dependency manifest change. It needs a CVE/advisory check (cargo audit / OSV) and an updated Cargo.lock. hkdf 0.13 also moves to the digest 0.11 / hmac 0.13 ecosystem, but sha2 stays at 0.10 (digest 0.10). That is an unexpected transitive jump, and Hkdf<Sha256> may no longer compile or may pull in duplicate digest versions. HOW: Run cargo audit (or query OSV) and attach the output to the PR. Commit the updated Cargo.lock. Either bump sha2 (and related RustCrypto crates such as aes-gcm) to versions compatible with hkdf 0.13, or keep hkdf at 0.12.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 45: WHAT: The hkdf dev-dependency moves from 0.12 to 0.13 (a semver-breaking bump for 0.x crates) with no visible audit or SCA evidence. WHY: This is a dependency manifest change. It needs a CVE/advisory check (cargo audit / OSV) and an updated Cargo.lock. hkdf 0.13 also moves to the digest 0.11 / hmac 0.13 ecosystem, but sha2 stays at 0.10 (digest 0.10). That is an unexpected transitive jump, and `Hkdf<Sha256>` may no longer compile or may pull in duplicate digest versions. HOW: Run `cargo audit` (or query OSV) and attach the output to the PR. Commit the updated Cargo.lock. Either bump sha2 (and related RustCrypto crates such as aes-gcm) to versions compatible with hkdf 0.13, or keep hkdf at 0.12.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-27T00:03:00Z

WHAT: The hkdf dev-dependency is bumped from 0.12 to 0.13 in Cargo.toml.
WHY: Dependency manifest changes need supply-chain validation: known CVEs, an updated Cargo.lock, and transitive changes. hkdf 0.13 moves to the newer hmac/digest 0.11 line, while sha2 = "0.10" still uses digest 0.10. Mixing them can cause type incompatibilities or duplicate crate versions.
HOW: Run cargo audit (or an OSV query) for hkdf 0.13 and its transitive deps, and put the result in the PR description. Commit the updated Cargo.lock. Check that sha2 (and aes-gcm, if relevant) are compatible with the new digest version, bumping them together if needed.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: WHAT: The `hkdf` dev-dependency is bumped from 0.12 to 0.13 in Cargo.toml. WHY: Dependency manifest changes need supply-chain validation: known CVEs, an updated Cargo.lock, and transitive changes. hkdf 0.13 moves to the newer `hmac`/`digest` 0.11 line, while `sha2 = "0.10"` still uses `digest` 0.10. Mixing them can cause type incompatibilities or duplicate crate versions. HOW: Run `cargo audit` (or an OSV query) for hkdf 0.13 and its transitive deps, and put the result in the PR description. Commit the updated Cargo.lock. Check that `sha2` (and `aes-gcm`, if relevant) are compatible with the new digest version, bumping them together if needed.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-27T05:10:32Z

Dependency mismatch in Cargo.toml: the hkdf dev-dependency moves from 0.12 to 0.13, a breaking 0.x semver bump onto a newer digest major than the still-pinned sha2 = "0.10". Building with both pulls two incompatible digest stacks into the graph, and code that pairs hkdf with sha2 fails to compile. Fix: bump sha2 to the version sharing hkdf 0.13's digest major (or keep hkdf at 0.12), commit the updated Cargo.lock, and attach cargo audit (or OSV) output for hkdf 0.13 to the PR description.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: Dependency mismatch in Cargo.toml: the `hkdf` dev-dependency moves from 0.12 to 0.13, a breaking 0.x semver bump onto a newer `digest` major than the still-pinned `sha2 = "0.10"`. Building with both pulls two incompatible digest stacks into the graph, and code that pairs hkdf with sha2 fails to compile. Fix: bump `sha2` to the version sharing hkdf 0.13's `digest` major (or keep hkdf at 0.12), commit the updated Cargo.lock, and attach `cargo audit` (or OSV) output for hkdf 0.13 to the PR description.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-29T14:28:00Z

WHAT: The dev-dependency hkdf is bumped from 0.12 to 0.13 with no visible vulnerability or supply-chain evidence. WHY: Dependency manifest changes must be checked for known CVEs, and the lockfile must be updated to match. Also, hkdf 0.13 targets the newer digest 0.11 ecosystem, while sha2 remains at 0.10. This mismatch can cause trait incompatibilities when the two are used together. HOW: Run cargo audit (or an OSV query) for hkdf 0.13 and attach the output to the PR. Commit the updated Cargo.lock. Make sure sha2 and related crates are bumped to versions that use the same digest version as hkdf 0.13.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: WHAT: The dev-dependency `hkdf` is bumped from 0.12 to 0.13 with no visible vulnerability or supply-chain evidence. WHY: Dependency manifest changes must be checked for known CVEs, and the lockfile must be updated to match. Also, hkdf 0.13 targets the newer `digest` 0.11 ecosystem, while `sha2` remains at 0.10. This mismatch can cause trait incompatibilities when the two are used together. HOW: Run `cargo audit` (or an OSV query) for hkdf 0.13 and attach the output to the PR. Commit the updated Cargo.lock. Make sure `sha2` and related crates are bumped to versions that use the same `digest` version as hkdf 0.13.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-30T01:07:51Z

WHAT: The hkdf dev-dependency moves from 0.12 to 0.13 with no supply-chain evidence attached. WHY: Dependency manifest changes must be checked for known CVEs and risky version jumps. hkdf 0.13 depends on the digest 0.11 / hmac 0.13 ecosystem, but sha2 is still pinned to 0.10. That mismatch can cause trait incompatibilities or pull duplicate crypto crates into the dependency tree. HOW: Run cargo audit (or an OSV query) for hkdf 0.13 and its transitive dependencies, and attach the output to the PR description. Bump sha2 (and related digest crates) to compatible versions, and commit the updated Cargo.lock.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: WHAT: The `hkdf` dev-dependency moves from 0.12 to 0.13 with no supply-chain evidence attached. WHY: Dependency manifest changes must be checked for known CVEs and risky version jumps. hkdf 0.13 depends on the digest 0.11 / hmac 0.13 ecosystem, but `sha2` is still pinned to 0.10. That mismatch can cause trait incompatibilities or pull duplicate crypto crates into the dependency tree. HOW: Run `cargo audit` (or an OSV query) for hkdf 0.13 and its transitive dependencies, and attach the output to the PR description. Bump `sha2` (and related digest crates) to compatible versions, and commit the updated Cargo.lock.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-30T14:20:12Z

WHAT: This PR bumps the hkdf dev-dependency from 0.12 to 0.13, but the diff includes no supply-chain evidence for the new version.
WHY: Dependency changes need vulnerability and supply-chain review. A minor-version jump in a pre-1.0 crypto crate is semver-breaking. hkdf 0.13 is built on the newer digest 0.11 line, while this manifest still pins sha2 = "0.10" (digest 0.10). That mix can cause trait mismatches (e.g., Hkdf::<Sha256>) or duplicate transitive crypto crates.
HOW:

Run cargo audit (or an OSV/SCA scan) for hkdf 0.13 and attach the output or advisory links to the PR description.

Make sure Cargo.lock is updated and committed.

Align the related crypto crates (e.g., bump sha2 to a digest-0.11-compatible version) or keep hkdf at 0.12 until they can be upgraded together.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: WHAT: This PR bumps the `hkdf` dev-dependency from 0.12 to 0.13, but the diff includes no supply-chain evidence for the new version. WHY: Dependency changes need vulnerability and supply-chain review. A minor-version jump in a pre-1.0 crypto crate is semver-breaking. hkdf 0.13 is built on the newer `digest` 0.11 line, while this manifest still pins `sha2 = "0.10"` (digest 0.10). That mix can cause trait mismatches (e.g., `Hkdf::<Sha256>`) or duplicate transitive crypto crates. HOW: - Run `cargo audit` (or an OSV/SCA scan) for hkdf 0.13 and attach the output or advisory links to the PR description. - Make sure Cargo.lock is updated and committed. - Align the related crypto crates (e.g., bump `sha2` to a digest-0.11-compatible version) or keep hkdf at 0.12 until they can be upgraded together.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-11-01T01:21:11Z

WHAT: The hkdf dev-dependency moves from 0.12 to 0.13, a semver-breaking minor bump for a 0.x crate. The diff shows no audit or SCA evidence, and no lockfile change.
WHY: hkdf 0.13 builds on the newer digest/hmac generation (0.11/0.13). The manifest still pins sha2 = "0.10", which implements the older digest 0.10 traits. Code like Hkdf<Sha256> will likely fail to compile, or pull in two digest versions. This kind of version jump should be checked for compatibility and known advisories.
HOW: Run cargo audit or an OSV lookup for hkdf 0.13 and attach the output to the PR. Either bump sha2 (and any other RustCrypto crates that share digest) to matching versions, or keep hkdf at 0.12. Commit the updated Cargo.lock.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File Cargo.toml: Line 46: WHAT: The `hkdf` dev-dependency moves from 0.12 to 0.13, a semver-breaking minor bump for a 0.x crate. The diff shows no audit or SCA evidence, and no lockfile change. WHY: hkdf 0.13 builds on the newer `digest`/`hmac` generation (0.11/0.13). The manifest still pins `sha2 = "0.10"`, which implements the older `digest` 0.10 traits. Code like `Hkdf<Sha256>` will likely fail to compile, or pull in two `digest` versions. This kind of version jump should be checked for compatibility and known advisories. HOW: Run `cargo audit` or an OSV lookup for hkdf 0.13 and attach the output to the PR. Either bump `sha2` (and any other RustCrypto crates that share `digest`) to matching versions, or keep `hkdf` at 0.12. Commit the updated Cargo.lock.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-26T13:10:09Z

Version mismatch in Cargo.toml [dev-dependencies]: hkdf 0.13 depends on hmac 0.13 / digest 0.11 (per Cargo.lock), while sha2 stays at 0.10, whose Sha256 implements only digest 0.10 traits. Running cargo test fails to compile the test module because Hkdf::<Sha256>::new(Some(&salt), master_key) in src/store.rs:327 does not satisfy hkdf 0.13's trait bounds. Fix: bump sha2 to 0.11 (digest 0.11) in the same change and verify that the expand call site still matches its signature.

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 45 to 47: Version mismatch in Cargo.toml [dev-dependencies]: hkdf 0.13 depends on hmac 0.13 / digest 0.11 (per Cargo.lock), while sha2 stays at 0.10, whose Sha256 implements only digest 0.10 traits. Running `cargo test` fails to compile the test module because `Hkdf::<Sha256>::new(Some(&salt), master_key)` in src/store.rs:327 does not satisfy hkdf 0.13's trait bounds. Fix: bump sha2 to 0.11 (digest 0.11) in the same change and verify that the `expand` call site still matches its signature. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-27T00:02:56Z

Build break in Cargo.toml dev-dependencies: hkdf 0.13 depends on hmac 0.13 / digest 0.11 (see Cargo.lock), but sha2 stays pinned to 0.10, which implements digest 0.10's traits, so Hkdf::<Sha256> in src/store.rs:327 no longer satisfies Hkdf's H trait bounds. Running cargo test fails to compile the frozen test module in src/store.rs (use hkdf::Hkdf; use sha2::Sha256;), which breaks the MSRV/CI test jobs. Fix: bump sha2 to "0.11" alongside hkdf 0.13 so both use digest 0.11.

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Build break in Cargo.toml dev-dependencies: hkdf 0.13 depends on hmac 0.13 / digest 0.11 (see Cargo.lock), but sha2 stays pinned to 0.10, which implements digest 0.10's traits, so `Hkdf::<Sha256>` in src/store.rs:327 no longer satisfies Hkdf's `H` trait bounds. Running `cargo test` fails to compile the `frozen` test module in src/store.rs (`use hkdf::Hkdf; use sha2::Sha256;`), which breaks the MSRV/CI test jobs. Fix: bump sha2 to "0.11" alongside hkdf 0.13 so both use digest 0.11. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-27T05:10:35Z

Build break in the Cargo.toml dev-dependencies: hkdf = "0.13" depends on hmac 0.13 / digest 0.11, while sha2 = "0.10" implements digest 0.10 traits, so Hkdf::<Sha256> in src/store.rs:327 fails the trait bounds hkdf 0.13 requires. Running cargo test fails to compile the frozen test module, because Cargo.lock resolves sha2 0.10.9 → digest 0.10.7 alongside hkdf 0.13.0 → hmac 0.13.0 → digest 0.11.3. Fix: bump sha2 to 0.11 together with hkdf, and check whether aes-gcm needs its crypto-common 0.2-based release (it does not interact with hkdf directly).

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Build break in the Cargo.toml dev-dependencies: `hkdf = "0.13"` depends on hmac 0.13 / digest 0.11, while `sha2 = "0.10"` implements digest 0.10 traits, so `Hkdf::<Sha256>` in src/store.rs:327 fails the trait bounds hkdf 0.13 requires. Running `cargo test` fails to compile the `frozen` test module, because Cargo.lock resolves sha2 0.10.9 → digest 0.10.7 alongside hkdf 0.13.0 → hmac 0.13.0 → digest 0.11.3. Fix: bump `sha2` to 0.11 together with hkdf, and check whether aes-gcm needs its crypto-common 0.2-based release (it does not interact with hkdf directly). Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-29T14:28:04Z

Version mismatch in Cargo.toml dev-dependencies: hkdf 0.13 depends on digest 0.11 through hmac 0.13, but sha2 stays at 0.10 on digest 0.10, as Cargo.lock shows (hkdf 0.13.0 → hmac 0.13.0 → digest 0.11.3; sha2 0.10.9 → digest 0.10.7). When cargo test compiles the test-only frozen module, Hkdf::<Sha256>::new(...) at src/store.rs:327 fails its trait bounds because sha2 0.10's Sha256 implements only the digest 0.10 traits, which breaks the test suite and CI. Fix: bump sha2 to 0.11 in the same change.

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Version mismatch in Cargo.toml dev-dependencies: `hkdf` 0.13 depends on `digest` 0.11 through `hmac` 0.13, but `sha2` stays at 0.10 on `digest` 0.10, as Cargo.lock shows (`hkdf` 0.13.0 → `hmac` 0.13.0 → `digest` 0.11.3; `sha2` 0.10.9 → `digest` 0.10.7). When `cargo test` compiles the test-only `frozen` module, `Hkdf::<Sha256>::new(...)` at src/store.rs:327 fails its trait bounds because `sha2` 0.10's `Sha256` implements only the `digest` 0.10 traits, which breaks the test suite and CI. Fix: bump `sha2` to 0.11 in the same change. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-30T01:07:48Z

Build break in Cargo.toml dev-dependencies: hkdf is bumped to 0.13 while sha2 stays at 0.10, and the two crates depend on incompatible digest versions (Cargo.lock resolves hkdf 0.13.0 → hmac 0.13.0 → digest 0.11.3, but sha2 0.10.9 → digest 0.10.7). When cargo test compiles Hkdf::<Sha256>::new(...) in src/store.rs:327 (with use sha2::Sha256 at line 314), the trait bound fails, so the frozen-format known-answer test does not build. Fix: bump sha2 to 0.11 in the same change so both crates use digest 0.11.

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Build break in Cargo.toml dev-dependencies: hkdf is bumped to 0.13 while sha2 stays at 0.10, and the two crates depend on incompatible digest versions (Cargo.lock resolves hkdf 0.13.0 → hmac 0.13.0 → digest 0.11.3, but sha2 0.10.9 → digest 0.10.7). When `cargo test` compiles `Hkdf::<Sha256>::new(...)` in src/store.rs:327 (with `use sha2::Sha256` at line 314), the trait bound fails, so the frozen-format known-answer test does not build. Fix: bump sha2 to 0.11 in the same change so both crates use digest 0.11. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-10-30T14:20:15Z

Build break in the Cargo.toml dev-dependencies: hkdf 0.13 is built on hmac 0.13 and digest 0.11 (Cargo.lock:537-560), but sha2 stays pinned to 0.10, which is built on digest 0.10.7 (Cargo.lock:1250-1258). When the tests compile, Hkdf::<Sha256>::new(...) in src/store.rs:327 passes sha2 0.10's Sha256, which lacks the digest 0.11 traits hkdf 0.13 requires, so cargo test fails with a trait-bound error. Fix: bump sha2 to 0.11 alongside hkdf so both use digest 0.11, matching the RustCrypto line aes-gcm 0.11 already uses.

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Build break in the Cargo.toml dev-dependencies: hkdf 0.13 is built on hmac 0.13 and digest 0.11 (Cargo.lock:537-560), but sha2 stays pinned to 0.10, which is built on digest 0.10.7 (Cargo.lock:1250-1258). When the tests compile, `Hkdf::<Sha256>::new(...)` in src/store.rs:327 passes sha2 0.10's `Sha256`, which lacks the digest 0.11 traits hkdf 0.13 requires, so `cargo test` fails with a trait-bound error. Fix: bump sha2 to 0.11 alongside hkdf so both use digest 0.11, matching the RustCrypto line aes-gcm 0.11 already uses. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

kodus-27b · 2026-11-01T01:21:15Z

Dependency version mismatch in Cargo.toml dev-dependencies: the bump to hkdf 0.13 (which uses hmac 0.13 and digest 0.11 per Cargo.lock) keeps sha2 at 0.10 (sha2 0.10.9 uses digest 0.10.7). That leaves Hkdf::<Sha256> in src/store.rs:328 with a hash type from the wrong digest major version. The Sha256 from sha2 0.10 does not implement the digest 0.11 traits that hkdf 0.13 requires, so cargo test fails to compile the frozen test module. Fix: bump sha2 together with hkdf, e.g. sha2 = "0.11".

hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

Prompt for LLM

File Cargo.toml: Line 46 to 48: Dependency version mismatch in Cargo.toml dev-dependencies: the bump to hkdf 0.13 (which uses hmac 0.13 and digest 0.11 per Cargo.lock) keeps sha2 at 0.10 (sha2 0.10.9 uses digest 0.10.7). That leaves `Hkdf::<Sha256>` in src/store.rs:328 with a hash type from the wrong digest major version. The `Sha256` from sha2 0.10 does not implement the digest 0.11 traits that hkdf 0.13 requires, so `cargo test` fails to compile the `frozen` test module. Fix: bump sha2 together with hkdf, e.g. `sha2 = "0.11"`. Suggested Code: hkdf = "0.13" rustix = { version = "1", features = ["pty"] } sha2 = "0.11"

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

-Original file line number
+Diff line change
@@ Expand Up @@
     [dev-dependencies]
     aes-gcm = "0.11"
     async-trait = "0.1"
-    hkdf = "0.12"
+    hkdf = "0.13"
     rustix = { version = "1", features = ["pty"] }
     sha2 = "0.10"
     tempfile = "3"

Navigation Menu

Repository navigation

chore(deps): update rust crate hkdf to 0.13 #37

Diff view

Diff view

There are no files selected for viewing

Uh oh!

kodus-27b Bot Oct 26, 2026

Uh oh!

kodus-27b Bot Oct 27, 2026

Uh oh!

kodus-27b Bot Oct 27, 2026

Uh oh!

kodus-27b Bot Oct 29, 2026

Uh oh!

kodus-27b Bot Oct 30, 2026

Uh oh!

kodus-27b Bot Oct 30, 2026

Uh oh!

kodus-27b Bot Nov 1, 2026

Uh oh!

kodus-27b Bot Oct 26, 2026

Uh oh!

kodus-27b Bot Oct 27, 2026

Uh oh!

kodus-27b Bot Oct 27, 2026

Uh oh!

kodus-27b Bot Oct 29, 2026

Uh oh!

kodus-27b Bot Oct 30, 2026

Uh oh!

kodus-27b Bot Oct 30, 2026

Uh oh!

kodus-27b Bot Nov 1, 2026

Uh oh!

Uh oh!

chore(deps): update rust crate hkdf to 0.13 #37

Are you sure you want to change the base?

chore(deps): update rust crate hkdf to 0.13 #37

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

kodus-27b Bot Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Nov 1, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 26, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 29, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

kodus-27b Bot Nov 1, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!