chore(deps): update rust-dev-deps

[cachekit-renovate-bot]

This PR contains the following updates:

Package	Type	Update	Change
aes-gcm	dev-dependencies	minor	0.10 → 0.11
blake2	dev-dependencies	minor	0.10 → 0.11
criterion (source)	dev-dependencies	minor	0.5 → 0.8
serde_json	dev-dependencies	patch	1.0.149 → 1.0.151
sha2	dev-dependencies	minor	0.10 → 0.11

---

Release Notes

RustCrypto/AEADs (aes-gcm)

v0.11.1

Compare Source

v0.11.0

Compare Source

RustCrypto/hashes (blake2)

v0.11.0

Compare Source

criterion-rs/criterion.rs (criterion)

v0.8.2

Compare Source

Fixed

• don't build alloca on unsupported targets

Other

• (deps) bump crate-ci/typos from 1.40.0 to 1.43.0
• Fix panic with uniform iteration durations in benchmarks
• Update Readme
• Exclude development scripts from published package

v0.8.1

Compare Source

Fixed

• Homepage link

Other

• (deps) bump crate-ci/typos from 1.23.5 to 1.40.0
• (deps) bump jontze/action-mdbook from 3 to 4
• (deps) bump actions/checkout from 4 to 6

v0.8.0

Compare Source

BREAKING

• Drop async-std support

Changed

• Bump MSRV to 1.86, stable to 1.91.1

Added

• Add ability to plot throughput on summary page.
• Add support for reporting throughput in elements and bytes - Throughput::ElementsAndBytes allows the text summary to report throughput in both units simultaneously.
• Add alloca-based memory layout randomisation to mitigate memory effects on measurements.
• Add doc comment to benchmark runner in criterion_group macro (removes linter warnings)

Fixed

• Fix plotting NaN bug

Other

• Remove Master API Docs links temporarily while we restore the docs publishing.

v0.7.0

Compare Source

• Bump version of criterion-plot to align dependencies.

v0.6.0

Compare Source

Changed

• MSRV bumped to 1.80
• The real_blackbox feature no longer has any impact. Criterion always uses std::hint::black_box() now.
  Users of criterion::black_box() should switch to std::hint::black_box().
• clap dependency unpinned.

Fixed

• gnuplot version is now correctly detected when using certain Windows binaries/configurations that used to fail

Added

• Async benchmarking with Tokio may be done via a tokio::runtime::Handle, not only a tokio::runtime::Runtime

serde-rs/json (serde_json)

v1.0.151

Compare Source

• Add RawValue::from_string_unchecked (#​1331, thanks @​WonderLawrence)

v1.0.150

Compare Source

• Reject non-string enum object keys (#​1324, thanks @​puneetdixit200)

---

Configuration

📅 Schedule: (in timezone Australia/Sydney)

• Branch creation
  • "before 6am"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: cachekit-io/cachekit-core/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 32941d6c-ef1b-4e55-99f5-cdf258142c03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

Kody Code Review — 2 suggested fixes.
Paste the prompt below to your agent and all review fixed at once!

🛠️ Open Agent Prompt

A code review identified the following issues in this pull request.
Each section describes what was found and includes a reference implementation where available.

Files involved:
- Cargo.toml:68
- Cargo.toml:73

---

### [1/2] Cargo.toml:68
Issue identified during code review:
Unverified breaking bump in Cargo.toml: `blake2` moves from 0.10 to 0.11, a semver-breaking change, without CVE/supply-chain evidence or an updated Cargo.lock. When only pre-release 0.11 versions are published, as was long the case across the RustCrypto stack, the bare `"0.11"` requirement fails to resolve and the build breaks. Fix: confirm a stable 0.11 release exists, attach cargo-audit or OSV output to the PR, and commit the updated Cargo.lock.

**Also found in:**
- `Cargo.toml:73-73`
- `Cargo.toml:72-72`
- `Cargo.toml:74-74`

---

### [2/2] Cargo.toml:73
Issue identified during code review:
Version conflict in Cargo.toml [dev-dependencies]: `sha2` and `aes-gcm` are bumped to 0.11, but [dependencies] still declares `sha2 = "0.10"` (line 44) and `aes-gcm = "0.10"` (line 52), and Cargo unifies a same-named dependency and dev-dependency into one extern crate, so ^0.10 and ^0.11 conflict. Running `cargo test --features encryption` either fails dependency resolution or gives rustc two candidates for `sha2`/`aes_gcm`. If 0.11 wins, `Hkdf::<Sha256>` in src/encryption/key_derivation.rs:109 breaks because hkdf 0.12 is built on digest 0.10, and tests/wasm32_compat_tests.rs:72-113 breaks on the 0.10 GenericArray `Nonce::from_slice` API. Fix: pin the dev-dependency versions to match production (0.10), or bump sha2/aes-gcm/aes/hkdf/hmac/generic-array together in [dependencies] and migrate the code.
Reference implementation (from code review):

// Cargo.toml:73
sha2 = "0.10"
aes-gcm = { version = "0.10", features = ["zeroize"] }

---

Review each issue in context, use the reference implementations as guidance, and apply fixes that are consistent with the surrounding codebase.

[kodus-27b]

Unverified breaking bump in Cargo.toml: blake2 moves from 0.10 to 0.11, a semver-breaking change, without CVE/supply-chain evidence or an updated Cargo.lock. When only pre-release 0.11 versions are published, as was long the case across the RustCrypto stack, the bare "0.11" requirement fails to resolve and the build breaks. Fix: confirm a stable 0.11 release exists, attach cargo-audit or OSV output to the PR, and commit the updated Cargo.lock.

Also found in:

• Cargo.toml:73-73
• Cargo.toml:72-72
• Cargo.toml:74-74

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

Prompt for LLM

File Cargo.toml:

Line 68:

Unverified breaking bump in Cargo.toml: `blake2` moves from 0.10 to 0.11, a semver-breaking change, without CVE/supply-chain evidence or an updated Cargo.lock. When only pre-release 0.11 versions are published, as was long the case across the RustCrypto stack, the bare `"0.11"` requirement fails to resolve and the build breaks. Fix: confirm a stable 0.11 release exists, attach cargo-audit or OSV output to the PR, and commit the updated Cargo.lock.

**Also found in:**
- `Cargo.toml:73-73`
- `Cargo.toml:72-72`
- `Cargo.toml:74-74`

_{Talk to Kody by mentioning @kody}

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

​

​

[kodus-27b]

Version conflict in Cargo.toml [dev-dependencies]: sha2 and aes-gcm are bumped to 0.11, but [dependencies] still declares sha2 = "0.10" (line 44) and aes-gcm = "0.10" (line 52), and Cargo unifies a same-named dependency and dev-dependency into one extern crate, so ^0.10 and ^0.11 conflict. Running cargo test --features encryption either fails dependency resolution or gives rustc two candidates for sha2/aes_gcm. If 0.11 wins, Hkdf::<Sha256> in src/encryption/key_derivation.rs:109 breaks because hkdf 0.12 is built on digest 0.10, and tests/wasm32_compat_tests.rs:72-113 breaks on the 0.10 GenericArray Nonce::from_slice API. Fix: pin the dev-dependency versions to match production (0.10), or bump sha2/aes-gcm/aes/hkdf/hmac/generic-array together in [dependencies] and migrate the code.

sha2 = "0.10"
aes-gcm = { version = "0.10", features = ["zeroize"] }

Prompt for LLM

File Cargo.toml:

Line 72 to 73:

Version conflict in Cargo.toml [dev-dependencies]: `sha2` and `aes-gcm` are bumped to 0.11, but [dependencies] still declares `sha2 = "0.10"` (line 44) and `aes-gcm = "0.10"` (line 52), and Cargo unifies a same-named dependency and dev-dependency into one extern crate, so ^0.10 and ^0.11 conflict. Running `cargo test --features encryption` either fails dependency resolution or gives rustc two candidates for `sha2`/`aes_gcm`. If 0.11 wins, `Hkdf::<Sha256>` in src/encryption/key_derivation.rs:109 breaks because hkdf 0.12 is built on digest 0.10, and tests/wasm32_compat_tests.rs:72-113 breaks on the 0.10 GenericArray `Nonce::from_slice` API. Fix: pin the dev-dependency versions to match production (0.10), or bump sha2/aes-gcm/aes/hkdf/hmac/generic-array together in [dependencies] and migrate the code.

Suggested Code:

sha2 = "0.10"
aes-gcm = { version = "0.10", features = ["zeroize"] }

_{Talk to Kody by mentioning @kody}

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

​

​

[kodus-27b]

Code Review Could Not Complete ⚠️

The review failed before suggestions could be generated.

Reason: Rate limit reached on the provider (openai_compatible). Try again in a few minutes.

After fixing the issue, comment @kody review on this PR to re-run the review.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​