Repository navigation
chore(deps): update all non-major dependencies #156
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,11 +17,11 @@ license = "MIT" | |
| crate-type = ["cdylib"] | ||
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.129" | ||
|
There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129, with no visible supply-chain or CVE evidence. Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Talk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain check. WHY: Dependency manifest changes must be checked for known CVEs and risky transitive jumps. wasm-bindgen generates the JS/WASM glue for every exported function, so a bad release affects the whole boundary. HOW: Run cargo audit or an OSV query for wasm-bindgen 0.2.129 and attach the output to the PR description. Also confirm Cargo.lock is updated and the matching wasm-bindgen-cli version is pinned in CI. Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129 with no supply-chain evidence. WHY: Dependency manifest changes need a vulnerability and supply-chain check, plus a matching Cargo.lock update. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain evidence. WHY: Dependency changes need a CVE and supply-chain check, plus a matching lockfile update. wasm-bindgen also generates JS glue across the WASM boundary, so changes in that glue are security-relevant. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible audit or supply-chain evidence. WHY: Dependency changes must be checked for known CVEs and supply-chain risk before merging. HOW: Run cargo audit (or an OSV/SCA scan) and attach the output to the PR description. Make sure Cargo.lock is updated to match. Also update the nearby comment that still references wasm-bindgen 0.2.121. Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129 in a dependency manifest. WHY: Rule 86 requires supply-chain and CVE validation for changed dependencies, plus a matching lockfile update. wasm-bindgen generates the JS/WASM ABI glue, so a version jump affects the security boundary. HOW: Attach Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible supply-chain check. WHY: Dependency changes must be checked for known CVEs and risky releases. wasm-bindgen generates the JS/WASM boundary code. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency moves from 0.2.121 to 0.2.129. WHY: Dependency manifest changes need supply-chain validation: CVE/advisory checks, lockfile consistency, and ABI pairing. wasm-bindgen generates the JS glue that crosses the WASM boundary handling key material. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129, and this file shows no supply-chain validation. WHY: Dependency manifest changes must be checked for known CVEs, and the lockfile must be updated with them. wasm-bindgen generates the JS/WASM ABI glue, so a bad release affects every consumer. HOW: Attach Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from =0.2.121 to =0.2.129 with no supply-chain validation shown. WHY: Dependency manifest changes must be checked for known CVEs and risky version jumps. This crate sits at the JS/WASM boundary that handles encryption key material. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The wasm-bindgen dependency was bumped from 0.2.121 to 0.2.129. WHY: Dependency manifest changes need vulnerability and supply-chain checks, and no audit evidence is provided here. The comment on line 23 still names wasm-bindgen 0.2.121, so the pairing note is now stale. HOW: Run cargo audit or an OSV query for the new versions and attach the results to the PR. Make sure Cargo.lock is updated, and change the comment to reference 0.2.129. Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain check. WHY: Dependency changes need evidence they bring in no known CVEs or unexpected transitive changes. Cargo.lock must also be updated so builds stay reproducible. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no supply-chain or CVE evidence. WHY: wasm-bindgen generates the JS/WASM glue for a crate that handles encryption master keys, so an unvetted upgrade affects a security-sensitive boundary. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The wasm-bindgen dependency was bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain check. WHY: Dependency upgrades can bring in known CVEs or risky transitive changes, and wasm-bindgen sits on the JS/WASM ABI boundary. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain check. WHY: Dependency manifest changes must be validated for known CVEs and risky transitive changes. wasm-bindgen generates the JS/WASM ABI glue, so its supply-chain integrity matters. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Talk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. |
||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.106" | ||
|
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/build-wasm.yml:31, ci.yml:227, and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121, and WASM_BINDGEN_SHA256 is still the checksum of the 0.2.121 tarball. When scripts/build.sh:11-15 compares the Cargo.lock pin against the installed CLI, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the wasm build in CI and in the release-please publish job. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 in
# .github/workflows/{build-wasm,ci,release-please}.yml to 0.2.129Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in the wasm-bindgen pin in packages/cachekit-core-wasm/Cargo.toml: the crate is bumped to =0.2.129, but every CI workflow still installs wasm-bindgen CLI 0.2.121 (.github/workflows/ci.yml:227, build-wasm.yml:31, release-please.yml:254). scripts/build.sh:11-15 compares Cargo.lock (0.2.129) against wasm-bindgen = "=0.2.129"
# ... Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# plus, in ci.yml / build-wasm.yml / release-please.yml:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:227, release-please.yml:254 and build-wasm.yml:31 still set WASM_BINDGEN_VERSION: 0.2.121, and ci.yml:231 pins WASM_BINDGEN_SHA256 to the 0.2.121 tarball. scripts/build.sh:11-17 compares the CLI version with the Cargo.lock version and runs wasm-bindgen = "=0.2.129"
# ...
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# In the same PR: .github/workflows/{ci,release-please,build-wasm}.yml
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is bumped to =0.2.129, but every CI workflow still installs the wasm-bindgen CLI 0.2.121 prebuilt with the 0.2.121 SHA256 (ci.yml:227, build-wasm.yml:31, release-please.yml:254). When scripts/build.sh:11-15 reads the pinned version from Cargo.lock (now 0.2.129), it exits with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129 (Cargo.lock also resolves 0.2.129), but wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (and WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in Cargo.toml line 20: the wasm-bindgen pin moves to =0.2.129, and Cargo.lock now resolves 0.2.129, but wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# Also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: js-sys is bumped from 0.3.98 to 0.3.106 in a dependency manifest. WHY: Dependency changes require vulnerability and supply-chain validation plus an updated lockfile. HOW: Run Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 with the 0.2.121 tarball SHA-256. scripts/build.sh:11-17 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is now pinned to =0.2.129, but ci.yml (line 227), release-please.yml (line 254), and build-wasm.yml (line 31) still install the wasm-bindgen CLI at 0.2.121 with the 0.2.121 SHA256. scripts/build.sh compares the Cargo.lock version (0.2.129) against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,release-please,build-wasm}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: The exact-pinned js-sys dependency was bumped from 0.3.98 to 0.3.106, and no audit evidence is visible. WHY: Dependency changes need a supply-chain check. Also, js-sys must stay ABI-paired with the wasm-bindgen release, and the comment above it still references wasm-bindgen 0.2.121. HOW: Attach Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is bumped to =0.2.129, but .github/workflows/ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install the wasm-bindgen CLI 0.2.121 with the old WASM_BINDGEN_SHA256. Because scripts/build.sh lines 11-17 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (0.2.129) + WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129, but ci.yml:227, build-wasm.yml:31, and release-please.yml:254 still download the 0.2.121 wasm-bindgen CLI with the 0.2.121 SHA256. scripts/build.sh reads 0.2.129 from Cargo.lock and aborts with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen pin moves to =0.2.129 (Cargo.lock now resolves 0.2.129), but the CI workflows still install the 0.2.121 wasm-bindgen CLI via WASM_BINDGEN_VERSION and its SHA-256 in .github/workflows/ci.yml:227/231, release-please.yml:254/256, and build-wasm.yml:31/35. scripts/build.sh:11-15 exits when the CLI version differs from the Cargo.lock pin, so the Workers lane, the build-wasm workflow, and the release wasm build all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment at line 23 to name 0.2.129. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,release-please,build-wasm}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# AND in .github/workflows/{ci,build-wasm,release-please}.yml:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:227, release-please.yml:254 and build-wasm.yml:31 still install the 0.2.121 wasm-bindgen CLI with that tarball's SHA-256 (ci.yml:231). When scripts/build.sh:11-15 compares the CLI version against the Cargo.lock version, it exits with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (and WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, release-please.yml and build-wasm.yml.Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate pin moves to =0.2.129 (Cargo.lock also resolves 0.2.129), but .github/workflows/build-wasm.yml:31, ci.yml:227 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121, and build-wasm.yml:35 still pins the SHA-256 of the 0.2.121 tarball. scripts/build.sh:11-16 compares the Cargo.lock version with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# ALSO update WASM_BINDGEN_VERSION: 0.2.129 (+ WASM_BINDGEN_SHA256) in
# .github/workflows/build-wasm.yml, ci.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (Cargo.lock 0.2.129), but .github/workflows/ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 with the 0.2.121 SHA256. When scripts/build.sh compares the CLI version to the Cargo.lock pin, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the wasm build fails in CI, build-wasm and release, and the Workers test run produces no artifact. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl release asset, and update the js-sys pairing comment to 0.2.129. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# ALSO update WASM_BINDGEN_VERSION: 0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is now pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install the wasm-bindgen CLI at 0.2.121 with that version's SHA-256. scripts/build.sh:11-15 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: Cargo.toml and Cargo.lock pin wasm-bindgen 0.2.129, but CI still installs wasm-bindgen CLI 0.2.121 through WASM_BINDGEN_VERSION in .github/workflows/build-wasm.yml:31, ci.yml:278, and release-please.yml:254. When any CI or release job runs wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/build-wasm.yml, ci.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml:20: the wasm-bindgen crate is pinned to =0.2.129, but WASM_BINDGEN_VERSION is still 0.2.121 and WASM_BINDGEN_SHA256 is still the 0.2.121 tarball checksum in build-wasm.yml:31, ci.yml:278 and release-please.yml:254. scripts/build.sh:11-17 compares the installed 0.2.121 CLI against the 0.2.129 version in Cargo.lock and exits 1, so wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/build-wasm.yml, ci.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Build break in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (Cargo.lock also resolves 0.2.129), but ci.yml:278-282, build-wasm.yml:31-35, and release-please.yml:254-256 still install wasm-bindgen CLI 0.2.121. When scripts/build.sh:11-15 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pin moves to wasm-bindgen =0.2.129, but the CI, build-wasm, and release-please workflows still install wasm-bindgen CLI 0.2.121 (WASM_BINDGEN_VERSION: 0.2.121, with that tarball's SHA256). scripts/build.sh:11-15 reads 0.2.129 from Cargo.lock, finds CLI 0.2.121, and exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so every wasm build in CI and every release fails. Fix: set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the 0.2.129 musl tarball checksum in ci.yml:278, release-please.yml:254, and build-wasm.yml:31, and update the stale '0.2.121' comment on line 23. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but CI still installs wasm-bindgen CLI 0.2.121 in .github/workflows/build-wasm.yml:31, ci.yml:278, and release-please.yml:254. On every CI and release wasm build, scripts/build.sh:11-17 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 in
# .github/workflows/{build-wasm,ci,release-please}.yml to 0.2.129Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. There was a problem hiding this comment.
WHAT: js-sys is bumped from 0.3.98 to 0.3.106. WHY: Updated dependencies must be checked for vulnerabilities and must be released as a pair with wasm-bindgen. HOW: Provide Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is bumped to =0.2.129 and Cargo.lock matches, but wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# ALSO update WASM_BINDGEN_VERSION: 0.2.129 in .github/workflows/ci.yml,
# build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but build-wasm.yml:31, ci.yml:278, and release-please.yml:254 still install wasm-bindgen CLI 0.2.121, and build-wasm.yml:35 pins the SHA-256 of the 0.2.121 tarball. When any CI wasm build or the cachekit-core-wasm tag release runs, scripts/build.sh:11-15 compares the CLI version against Cargo.lock and exits with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". Fix: set WASM_BINDGEN_VERSION to 0.2.129 in all three workflows, update WASM_BINDGEN_SHA256 (and any other workflow checksums) to the hash of the 0.2.129 x86_64-unknown-linux-musl tarball, and correct the stale 0.2.121 comment on line 23. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129, but every CI workflow still installs the wasm-bindgen CLI 0.2.121 (WASM_BINDGEN_VERSION: 0.2.121 and its SHA256 in .github/workflows/ci.yml:278/282, build-wasm.yml:31/35, and release-please.yml:254/256). On every CI run, scripts/build.sh:11-15 reads 0.2.129 from Cargo.lock, compares it with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml:20: the crate pins wasm-bindgen to =0.2.129, but wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# ALSO update WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is bumped to =0.2.129, and Cargo.lock now resolves 0.2.129, but the CI workflows still install the 0.2.121 wasm-bindgen CLI (WASM_BINDGEN_VERSION: 0.2.121 at .github/workflows/ci.yml:278, release-please.yml:254, and build-wasm.yml:31), and the checksum at ci.yml:282 still matches the 0.2.121 tarball. When scripts/build.sh:11-15 compares the CLI version against the Cargo.lock pin, it exits with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129", which breaks the Workers lane, the wasm build workflow, and the release wasm build. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update the SHA-256 for the 0.2.129 x86_64-unknown-linux-musl tarball, then update the line-23 comment. wasm-bindgen = "=0.2.129"
# AND in .github/workflows/{ci.yml,build-wasm.yml,release-please.yml}:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129, but WASM_BINDGEN_VERSION still installs CLI 0.2.121 in .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254. scripts/build.sh reads 0.2.129 from Cargo.lock, compares it with wasm-bindgen = "=0.2.129"
# and in .github/workflows/{ci.yml,build-wasm.yml,release-please.yml}:
# WASM_BINDGEN_VERSION: 0.2.129Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129 (Cargo.lock resolves 0.2.129), but wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen to =0.2.129 (Cargo.lock resolves 0.2.129), but ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 and verify it against a 0.2.121 SHA-256. scripts/build.sh:11-15 compares the Cargo.lock version with wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with the matching 0.2.121 WASM_BINDGEN_SHA256. scripts/build.sh:11-16 compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (matching Cargo.lock), but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 with the old WASM_BINDGEN_SHA256. Because scripts/build.sh:11-16 exits 1 when the CLI version differs from the Cargo.lock version, the 'Workers lane' CI job, the tag-triggered wasm release build, and the release-please wasm build all fail with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the wasm artifact cannot be built or published. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl release tarball, and update the line 23 comment to 0.2.129. wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 (+ WASM_BINDGEN_SHA256) in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (matching Cargo.lock), but WASM_BINDGEN_VERSION is still 0.2.121 in .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254. scripts/build.sh (lines 11-17) compares the Cargo.lock version against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION to 0.2.129 in .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml line 20: the wasm-bindgen crate pin and Cargo.lock (line 861) are now 0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 and verify WASM_BINDGEN_SHA256 against the 0.2.121 tarball. When the Workers lane, build-wasm or the release job runs, scripts/build.sh:11-15 compares the Cargo.lock version (0.2.129) with the installed CLI (0.2.121), prints wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# AND in .github/workflows/{ci.yml,build-wasm.yml,release-please.yml}:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in Cargo.toml: the wasm-bindgen crate is now pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with its SHA256. scripts/build.sh:11-17 compares the Cargo.lock version with the wasm-bindgen = "=0.2.129"
# ... Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# AND update WASM_BINDGEN_VERSION to 0.2.129 (plus the matching WASM_BINDGEN_SHA256 of the 0.2.129 x86_64-unknown-linux-musl tarball) in .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129 (Cargo.lock also resolves 0.2.129), but CI still installs CLI 0.2.121 via wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (0.2.129) and WASM_BINDGEN_SHA256 in
# .github/workflows/build-wasm.yml, ci.yml and release-please.ymlPrompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Comment on lines
+20
to
+24
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is now exact-pinned to 0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install the wasm-bindgen CLI 0.2.121 and verify it against the 0.2.121 SHA256. When scripts/build.sh:11-17 compares the Cargo.lock version (0.2.129) against wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# AND in .github/workflows/{ci,build-wasm,release-please}.yml:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. |
||
| cachekit-core = { version = "0.6.0", features = ["encryption"] } | ||
| # Wipes the owned previous-master-key staging buffers on drop (the NAPI crate | ||
| # borrows and never copies; this crate must copy out of JS memory). Already in | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -96,13 +96,13 @@ | |
| "ioredis": "^5.11.1" | ||
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.23.0", | ||
|
There was a problem hiding this comment.
WHAT: @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.23.0, a multi-minor bump on a pre-1.0 package. Also found in:
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk Prompt for LLMTalk to Kody by mentioning @kody Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction. |
||
| "@testcontainers/redis": "^11.13.0", | ||
| "@types/ioredis": "^5.0.0", | ||
| "@types/memjs": "^1.3.3", | ||
| "@types/node": "^25.5.0", | ||
| "@vitest/coverage-v8": "^4.1.2", | ||
| "esbuild": "0.28.2", | ||
| "eslint": "^10.1.0", | ||
| "memjs": "^1.3.2", | ||
| "prom-client": "^15.1.3", | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no audit or SCA evidence. WHY: Dependency manifest changes must be checked for known CVEs and supply-chain risk. A jump of several patch releases on an exact-pinned toolchain crate also needs its lockfile updated. HOW: Run
cargo auditor query OSV for wasm-bindgen 0.2.129 and attach the output to the PR. Commit the updated Cargo.lock, and update the adjacent comment that still references 0.2.121.Also found in:
packages/cachekit/package.json:95-95packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:101-101Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.