Skip to content

fix(deps): clear all open Dependabot advisories - #436

Merged
marc0olo merged 1 commit into
mainfrom
fix/security-advisories
Aug 27, 2026
Merged

fix(deps): clear all open Dependabot advisories#436
marc0olo merged 1 commit into
mainfrom
fix/security-advisories

Conversation

@marc0olo

Copy link
Copy Markdown
Member

Clears all 12 open Dependabot advisories in one change. Supersedes #397, #380 and #409.

Changes

Package Was Now Alerts cleared
openssl 0.10.73 0.10.81 8 — 5 high, 2 medium, 1 low
openssl-sys 0.9.109 0.9.117 (transitive)
rustls-webpki 0.103.10 0.103.15 3 — 1 high, 2 low
rand 0.8.5 0.8.8 1 — low

Each alert was checked against its own patched version; all 12 verify as cleared. openssl and rustls-webpki land newer than the superseded PRs proposed (0.10.80 / 0.103.13).

Three files, and the lockfile moves exactly four package versions — no transitive churn.

Why not rand 0.10.2, as #409 proposed

rand is the only one of the three that reaches shipped code — it is a runtime dependency of the published ic-vetkeys crate (plus ic-vetkeys-test-utils, ic-vetkeys-manager-canister, ic-vetkeys-canisters-tests).

But the advisory (GHSA-cq8v-f236-94qc, low) is:

vulnerable range:  >= 0.7.0, < 0.8.6
first patched:     0.8.6

0.8.6 is a patch release. #409 proposed 0.10.2 — two breaking majors past the fix — which would force a rand 0.8 → 0.10 API migration across four crates including the published crypto crate, plus a lockstep rand_chacha 0.3 → 0.10 move. That is a large, risky change to absorb for a low-severity advisory that a patch bump resolves. This PR moves the manifest floor to 0.8.6 and the lock resolves 0.8.8.

(The rand 0.10.2 already in Cargo.lock is unrelated — it arrives via quinn-proto, transitively under the dev-only reqwest, and is untouched here.)

Severity in context

openssl and rustls-webpki account for 11 of the 12 alerts, including all 6 highs — but their real exposure is CI-only. Both reach the tree solely via reqwest, which sits under [dev-dependencies] next to pocket-ic, and the canisters compile to wasm32-unknown-unknown where neither can exist. Neither appears in the published crate's dependency list:

rand           req=^0.8.5    kind=normal
rand_chacha    req=^0.3.1    kind=normal
pocket-ic      req=^15.0.0   kind=dev

GitHub reports scope=runtime for all of them, but that is inferred from Cargo.lock, which carries no dev/runtime split for transitive packages. The manifests are the authority here.

No release required

Published ic-vetkeys@0.9.0 declares rand = "^0.8.5" — i.e. >=0.8.5, <0.9.0. 0.8.8 already satisfies that, so anyone building against 0.9.0 today resolves the fixed version automatically; nobody is pinned to the vulnerable 0.8.5 except via a stale local lockfile, which cargo update -p rand fixes without any action from us.

Cargo.lock is not consumed by dependents of a library crate, and dev-dependencies never propagate — so the openssl / rustls-webpki half has zero consumer impact by construction.

The manifest floor bump to 0.8.6 only takes effect when we next publish, and is belt-and-braces for the stale-lockfile case. It can ride the next release rather than triggering one. Nothing here affects @icp-sdk/vetkeys (npm) or the Motoko package.

Verification

Ran the backend CI commands verbatim:

  • cargo build --release --target wasm32-unknown-unknown for all four canister crates — pass
  • cargo test14 passed, 0 failed, including the pocket-ic integration tests (key_sharing_should_work, should_preserve_state_across_upgrade, should_get_accessible_shared_key_ids, …) that exercise the crypto paths using rand
  • cargo test --doc — pass (the 4 ignored doc-tests carry pre-existing ignore annotations, unchanged here)
  • cargo clippy -- -Dwarnings — pass
  • cargo fmt --check — pass

rand 0.8.5 → 0.8.8 is a patch bump inside 0.8, so no API change was expected; the green build and integration tests confirm it rather than assume it.

Superseded

Also closed as obsolete while triaging: #337, #316, #315 (targeted examples/, removed in #377) and #406 (vite 7.3.5, already superseded by ^7.3.6 from #434).

🤖 Generated with Claude Code

Supersedes #397, #380 and #409 with a single change.

  openssl        0.10.73  -> 0.10.81   (8 alerts: 5 high, 2 medium, 1 low)
  openssl-sys    0.9.109  -> 0.9.117
  rustls-webpki  0.103.10 -> 0.103.15  (3 alerts: 1 high, 2 low)
  rand           0.8.5    -> 0.8.8     (1 alert: low)

All 12 open alerts verified cleared against each advisory's patched
version. openssl and rustls-webpki land newer than the dependabot PRs
proposed (0.10.80 / 0.103.13).

`rand` is the only one of the three that reaches shipped code: it is a
runtime dependency of the published `ic-vetkeys` crate. #409 proposed
0.10.2 for it, but GHSA-cq8v-f236-94qc is patched in 0.8.6 -- a patch
release. Taking 0.8.x avoids a breaking 0.8 -> 0.10 API migration across
four crates, and a lockstep `rand_chacha` bump, for a low-severity
advisory. The manifest floor moves to 0.8.6; the lock resolves 0.8.8.

openssl and rustls-webpki arrive only via `reqwest`, a dev-dependency
alongside `pocket-ic`, and the canisters build for wasm32-unknown-unknown
where they cannot exist. They do not appear in the published crate's
dependency list at all, so that exposure is CI-only.

No release is required. Published `ic-vetkeys@0.9.0` declares
`rand = "^0.8.5"`, which 0.8.8 already satisfies, so consumers resolve the
fixed version on a fresh build without any action from us. The floor bump
can ride the next release.

Verified: cargo build (wasm32, all four canister crates), cargo test
(14 passed incl. the pocket-ic integration tests), cargo test --doc,
cargo clippy -- -Dwarnings, cargo fmt --check. All pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@marc0olo
marc0olo merged commit a077c41 into main Aug 27, 2026
16 checks passed
@marc0olo
marc0olo deleted the fix/security-advisories branch August 27, 2026 09:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants