chore(deps): update first-party cachekit - #7
Conversation
c7889d0 to
9a2b7ba
Compare
This comment has been minimized.
This comment has been minimized.
![kodus-27b[bot]](https://avatars.githubusercontent.com/u/223823690?s=60&v=4){kind=small}
9a2b7ba to
46e57a3
Compare
This comment has been minimized.
This comment has been minimized.
46e57a3 to
a040389
Compare
This comment has been minimized.
This comment has been minimized.
Kody findings verified (LAB-1373)Went through all four Kody comments on Finding 1 (High, Rule 85 — no audit/SCA evidence): satisfied
Findings 2–4 (Medium — dual cachekit-core versions break the verify path): false positivesThe lockfile fact is real:
Residual (non-blocking) hygiene note: the duplicate Note the repo's |
a040389 to
d7260a8
Compare
This comment has been minimized.
This comment has been minimized.
d7260a8 to
c9876a2
Compare
This comment has been minimized.
This comment has been minimized.
| # Interop key derivation + strict interop/v1 (de)serialization. No features: | ||
| # the interop module is unconditional, and native builds don't need backends. | ||
| cachekit-rs = { version = "0.5.0", default-features = false } | ||
| cachekit-rs = { version = "0.7.0", default-features = false } |
There was a problem hiding this comment.
WHAT: The dependency version for cachekit-rs was bumped from 0.5.0 to 0.7.0 without SCA/CVE evidence. WHY: New/updated dependencies must be validated for known vulnerabilities and supply-chain risk. HOW: Provide OSV/SCA audit output or advisory links in the PR description and ensure the lockfile is updated with pinned versions.
Also found in:
hotpath/Cargo.toml:23-23hotpath/Cargo.toml:40-40
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File hotpath/Cargo.toml:
Line 20:
WHAT: The dependency version for cachekit-rs was bumped from 0.5.0 to 0.7.0 without SCA/CVE evidence. WHY: New/updated dependencies must be validated for known vulnerabilities and supply-chain risk. HOW: Provide OSV/SCA audit output or advisory links in the PR description and ensure the lockfile is updated with pinned versions.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
c9876a2 to
97c3d6d
Compare
This comment has been minimized.
This comment has been minimized.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.5", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: Dependency version bump from 0.4 to 0.5 without CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk, and this also breaks the documented pin alignment with cachekit-rs 0.7.0's 0.4 pin (noted in the comment above), which could duplicate copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.5 version is compatible with cachekit-rs 0.7.0's pin, and update the lockfile accordingly.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: Dependency version bump from 0.4 to 0.5 without CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk, and this also breaks the documented pin alignment with cachekit-rs 0.7.0's 0.4 pin (noted in the comment above), which could duplicate copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.5 version is compatible with cachekit-rs 0.7.0's pin, and update the lockfile accordingly.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.5", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: Bumping cachekit-core to 0.5 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant stated in the comment above (lines 21-23) — cachekit-rs 0.7.0 still transitively depends on cachekit-core 0.4.0 (Cargo.lock line 167), while this crate now depends on 0.5.0 (Cargo.lock line 1187). WHY: Two independent copies of cachekit-core (0.4.0 and 0.5.0) now compile into the wasm32 build, duplicating the checksum/xxhash code and enlarging the Worker wasm binary — the exact bloat the comment says the 0.4 pin prevents. HOW: Either keep cachekit-core pinned at the version cachekit-rs 0.7.0 depends on (0.4) until cachekit-rs is upgraded to a release that depends on cachekit-core 0.5, or bump cachekit-rs in lockstep so a single cachekit-core version resolves; also update the now-stale comment on lines 21-23.
# 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: Bumping cachekit-core to 0.5 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant stated in the comment above (lines 21-23) — cachekit-rs 0.7.0 still transitively depends on cachekit-core 0.4.0 (Cargo.lock line 167), while this crate now depends on 0.5.0 (Cargo.lock line 1187). WHY: Two independent copies of cachekit-core (0.4.0 and 0.5.0) now compile into the wasm32 build, duplicating the checksum/xxhash code and enlarging the Worker wasm binary — the exact bloat the comment says the 0.4 pin prevents. HOW: Either keep cachekit-core pinned at the version cachekit-rs 0.7.0 depends on (0.4) until cachekit-rs is upgraded to a release that depends on cachekit-core 0.5, or bump cachekit-rs in lockstep so a single cachekit-core version resolves; also update the now-stale comment on lines 21-23.
Suggested Code:
# 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
97c3d6d to
b1d104a
Compare
This comment has been minimized.
This comment has been minimized.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: The dependency cachekit-core was bumped from 0.4 to 0.6 with no SCA/CVE evidence. WHY: New/updated dependency versions must be validated for known vulnerabilities and supply-chain risk, and this also breaks the documented version-pin invariant (comment above still says '0.4 matches cachekit-rs 0.7.0's pin'), risking multiple copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.6 version aligns with cachekit-rs 0.7.0's expected pin, update the explanatory comment, and ensure the lockfile is updated accordingly.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: The dependency cachekit-core was bumped from 0.4 to 0.6 with no SCA/CVE evidence. WHY: New/updated dependency versions must be validated for known vulnerabilities and supply-chain risk, and this also breaks the documented version-pin invariant (comment above still says '0.4 matches cachekit-rs 0.7.0's pin'), risking multiple copies in the wasm binary. HOW: Provide OSV/SCA audit output or advisory links in the PR description, confirm the 0.6 version aligns with cachekit-rs 0.7.0's expected pin, update the explanatory comment, and ensure the lockfile is updated accordingly.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: Bumping the direct cachekit-core dependency to 0.6 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant — Cargo.lock now resolves both cachekit-core 0.4.0 (transitive via cachekit-rs 0.7.0, line 167) and cachekit-core 0.6.0 (direct, line 1187), so two copies of the crate compile into the wasm32 binary. WHY: The in-file comment (lines 21-23) explicitly requires matching cachekit-rs's pin 'so only one copy lands in the wasm binary'; two copies of cachekit-core plus their xxhash-rust/serde_bytes graph inflate the hot-path Worker's wasm size, and the comment now states an incorrect version (still says '0.4 matches'). Additionally, verify_payload (compute.rs:78) documents its checksum as byte-identical to what a cachekit-rs StorageEnvelope embeds; computing it via a different cachekit-core major than cachekit-rs uses removes the guarantee that the two share one checksum implementation. HOW: Either keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release that also depends on cachekit-core 0.6 so a single copy is resolved; update the comment on lines 22-23 accordingly.
# 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: Bumping the direct `cachekit-core` dependency to 0.6 while `cachekit-rs` stays at 0.7.0 breaks the single-copy invariant — Cargo.lock now resolves both `cachekit-core 0.4.0` (transitive via cachekit-rs 0.7.0, line 167) and `cachekit-core 0.6.0` (direct, line 1187), so two copies of the crate compile into the wasm32 binary. WHY: The in-file comment (lines 21-23) explicitly requires matching cachekit-rs's pin 'so only one copy lands in the wasm binary'; two copies of cachekit-core plus their xxhash-rust/serde_bytes graph inflate the hot-path Worker's wasm size, and the comment now states an incorrect version (still says '0.4 matches'). Additionally, `verify_payload` (compute.rs:78) documents its checksum as byte-identical to what a cachekit-rs StorageEnvelope embeds; computing it via a different cachekit-core major than cachekit-rs uses removes the guarantee that the two share one checksum implementation. HOW: Either keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release that also depends on cachekit-core 0.6 so a single copy is resolved; update the comment on lines 22-23 accordingly.
Suggested Code:
# 0.4 matches cachekit-rs 0.7.0's transitive pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: Bumping the direct cachekit-core dependency to 0.6 while cachekit-rs stays at 0.7.0 breaks the single-copy invariant the adjacent comment guarantees — Cargo.lock now resolves both cachekit-core 0.6.0 (as skyline-hotpath's direct dep) and cachekit-core 0.4.0 (transitively via cachekit-rs 0.7.0). WHY: Two copies of cachekit-core land in the wasm binary (the outcome the comment on lines 22-23 says the pin prevents), bloating the binary and making the checksum/interop primitives potentially resolve to a different crate instance than the one backing StorageEnvelope, and the comment is now factually wrong. HOW: Either keep cachekit-core at the version cachekit-rs 0.7.0 pins (0.4), or bump cachekit-rs in tandem so both resolve to a single 0.6 copy, then update the comment.
# Keep in lockstep with cachekit-rs's cachekit-core pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: Bumping the direct `cachekit-core` dependency to 0.6 while `cachekit-rs` stays at 0.7.0 breaks the single-copy invariant the adjacent comment guarantees — Cargo.lock now resolves both `cachekit-core 0.6.0` (as skyline-hotpath's direct dep) and `cachekit-core 0.4.0` (transitively via cachekit-rs 0.7.0). WHY: Two copies of `cachekit-core` land in the wasm binary (the outcome the comment on lines 22-23 says the pin prevents), bloating the binary and making the checksum/interop primitives potentially resolve to a different crate instance than the one backing StorageEnvelope, and the comment is now factually wrong. HOW: Either keep `cachekit-core` at the version `cachekit-rs 0.7.0` pins (0.4), or bump `cachekit-rs` in tandem so both resolve to a single 0.6 copy, then update the comment.
Suggested Code:
# Keep in lockstep with cachekit-rs's cachekit-core pin so only one copy lands in the wasm binary.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
b1d104a to
f1aac55
Compare
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: This dependency manifest change bumps cachekit-core from 0.4 to 0.6 with no CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk. Additionally, the comment above claims 0.4 matches cachekit-rs 0.7.0's pin, but this changes it to 0.6, which may cause duplicate copies in the wasm binary (contradicting the intent). HOW: Provide OSV/SCA audit output or advisory links in the PR description, pin the exact version, ensure the lockfile is updated, and update the stale comment to reflect the 0.6 pin.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: This dependency manifest change bumps cachekit-core from 0.4 to 0.6 with no CVE/SCA evidence. WHY: New/updated dependency versions may introduce known vulnerabilities or supply-chain risk. Additionally, the comment above claims 0.4 matches cachekit-rs 0.7.0's pin, but this changes it to 0.6, which may cause duplicate copies in the wasm binary (contradicting the intent). HOW: Provide OSV/SCA audit output or advisory links in the PR description, pin the exact version, ensure the lockfile is updated, and update the stale comment to reflect the 0.6 pin.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| # checksums, so wire values are identical. 0.4 matches cachekit-rs 0.7.0's | ||
| # pin so only one copy lands in the wasm binary. | ||
| cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] } | ||
| cachekit-core = { version = "0.6", default-features = false, features = ["checksum"] } |
There was a problem hiding this comment.
WHAT: Bumping cachekit-core to "0.6" desyncs it from cachekit-rs 0.7.0's transitive pin of cachekit-core 0.4.0 (confirmed in Cargo.lock:167 vs Cargo.lock:1187), violating the file's own invariant on lines 21-23. WHY: compute.rs:78/85 compute the xxHash3-64 checksum with cachekit-core 0.6.0, but VerifyReport (compute.rs:62-64) contracts this to be byte-identical to the checksum a cachekit-rs StorageEnvelope embeds — which is produced by cachekit-core 0.4.0; a major-version jump can change the hash output, silently breaking integrity verification (matches_expected/xxh3_64 disagree with the stored envelope), and it links two copies of cachekit-core into the wasm binary (Cargo.lock has both 0.4.0 and 0.6.0). HOW: Keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release whose transitive cachekit-core is 0.6 so a single copy resolves; also update the stale "0.4 matches..." comment.
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }Prompt for LLM
File hotpath/Cargo.toml:
Line 24:
WHAT: Bumping cachekit-core to "0.6" desyncs it from cachekit-rs 0.7.0's transitive pin of cachekit-core 0.4.0 (confirmed in Cargo.lock:167 vs Cargo.lock:1187), violating the file's own invariant on lines 21-23. WHY: compute.rs:78/85 compute the xxHash3-64 checksum with cachekit-core 0.6.0, but VerifyReport (compute.rs:62-64) contracts this to be byte-identical to the checksum a cachekit-rs StorageEnvelope embeds — which is produced by cachekit-core 0.4.0; a major-version jump can change the hash output, silently breaking integrity verification (matches_expected/xxh3_64 disagree with the stored envelope), and it links two copies of cachekit-core into the wasm binary (Cargo.lock has both 0.4.0 and 0.6.0). HOW: Keep cachekit-core pinned to the version cachekit-rs 0.7.0 depends on (0.4), or upgrade cachekit-rs to a release whose transitive cachekit-core is 0.6 so a single copy resolves; also update the stale "0.4 matches..." comment.
Suggested Code:
cachekit-core = { version = "0.4", default-features = false, features = ["checksum"] }
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
1 participant
This PR contains the following updates:
0.1.3→0.1.5==0.15.0→==0.18.00.4→0.6Release Notes
cachekit-io/cachekit-ts (@cachekit-io/cachekit)
v0.1.5Features
Bug Fixes
v0.1.4Features
cachekit-io/cachekit-py (cachekit)
v0.18.0Compare Source
⚠ BREAKING CHANGES
Features
Bug Fixes
Performance Improvements
Code Refactoring
v0.17.1Compare Source
Bug Fixes
v0.17.0Compare Source
Features
Bug Fixes
Performance Improvements
v0.16.0Compare Source
⚠ BREAKING CHANGES
Bug Fixes
Code Refactoring
cachekit-io/cachekit-core (cachekit-core)
v0.6.0Compare Source
Features
v0.5.0Compare Source
⚠ BREAKING CHANGES
Features
Configuration
📅 Schedule: (in timezone Australia/Sydney)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate.