Skip to content

fix(deps): update rust crate sha2 to 0.11.0#714

Open
svc-secops wants to merge 1 commit intomainfrom
renovate/sha2-0.x
Open

fix(deps): update rust crate sha2 to 0.11.0#714
svc-secops wants to merge 1 commit intomainfrom
renovate/sha2-0.x

Conversation

@svc-secops
Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
sha2 dependencies minor 0.10.9 -> 0.11.0

Release Notes

RustCrypto/hashes (sha2)

v0.11.0

Compare Source


Configuration

📅 Schedule: Branch creation - "every weekend" in timezone America/Los_Angeles, Automerge - "after 8am and before 4pm on tuesday" in timezone America/Los_Angeles.

🚦 Automerge: Enabled.

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

🔕 Ignore: Close this PR and you won't be reminded about this update again.


This PR has been generated by Renovate Bot.

@svc-secops svc-secops requested a review from a team as a code owner March 28, 2026 16:00
@svc-secops svc-secops enabled auto-merge (squash) March 28, 2026 16:00
@svc-secops
Copy link
Copy Markdown
Contributor Author

svc-secops commented Mar 28, 2026

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: Cargo.lock
Command failed: cargo update --config net.git-fetch-with-cli=true --manifest-path crates/apollo-mcp-rhai/Cargo.toml --package sha2@0.10.9 --precise 0.11.0
    Updating crates.io index
error: failed to select a version for the requirement `sha2 = "^0.10.7"`
candidate versions found which didn't match: 0.11.0
location searched: crates.io index
required by package `jsonwebtoken v10.3.0`
    ... which satisfies dependency `jsonwebtoken = "^10.3"` (locked to 10.3.0) of package `apollo-mcp-server v1.12.0 (/tmp/renovate/repos/github/apollographql/apollo-mcp-server/crates/apollo-mcp-server)`

@apollo-librarian
Copy link
Copy Markdown
Contributor

apollo-librarian bot commented Mar 28, 2026

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: 9790091fb15502892aac1fb8
Build Logs: View logs


✅ AI Style Review — No Changes Detected

No MDX files were changed in this pull request.

Review Log: View detailed log

This review is AI-generated. Please use common sense when accepting these suggestions, as they may not always be accurate or appropriate for your specific context.

rmcp.workspace = true
serde_json.workspace = true
sha2 = "0.10.9"
sha2 = "0.11.0"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 This PR introduces a dependency version conflict that breaks the workspace build: jsonwebtoken v10.3.0 requires sha2 = "^0.10.7" (i.e., >=0.10.7, <0.11.0), which is incompatible with the sha2 0.11.0 bump here. The Renovate bot's cargo update command already failed with this exact conflict, leaving Cargo.lock unmodified and the workspace in an inconsistent state. This PR cannot be merged until jsonwebtoken is upgraded to a version that supports sha2 0.11.0, or sha2 is kept at a 0.10.x release.

Extended reasoning...

What the bug is and how it manifests

The PR bumps sha2 from 0.10.9 to 0.11.0 in crates/apollo-mcp-rhai/Cargo.toml. However, another workspace dependency, jsonwebtoken v10.3.0 (required by apollo-mcp-server), declares sha2 = "^0.10.7". In Cargo's semver semantics for pre-1.0 crates, ^0.10.7 means >=0.10.7, <0.11.0 — it does not include 0.11.0. This creates an irreconcilable conflict: apollo-mcp-rhai demands sha2 0.11.0, while jsonwebtoken demands sha2 <0.11.0.

The specific code path that triggers it

Cargo's resolver must find a single version of sha2 satisfying both constraints simultaneously. Because the two version requirements are mutually exclusive — one requires exactly 0.11.0 and the other requires <0.11.0 — the resolver fails. This is precisely what the svc-secops bot reported: Renovate ran cargo update --package sha2@0.10.9 --precise 0.11.0, and cargo exited with error: failed to select a version for the requirement sha2 = "^0.10.7".

Why existing code doesn't prevent it

Renovate's automatic dependency-update process does not verify transitive dependency compatibility before opening a PR. The Cargo.lock file was never updated (it still pins sha2 to 0.10.9) because the update command failed. As a result, Cargo.toml and Cargo.lock are now inconsistent: any build using --locked (as is typical in CI) will fail immediately because the lock file doesn't satisfy the manifest.

Impact

Merging this PR as-is will break the workspace build for all consumers. CI pipelines using cargo build --locked or cargo test --locked will fail with the same resolver error. Any downstream release or deployment will be blocked until the conflict is resolved.

How to fix it

Two viable remedies exist: (1) Keep sha2 at a 0.10.x release (e.g., the latest 0.10.x patch) in apollo-mcp-rhai/Cargo.toml until jsonwebtoken is upgraded to a version that depends on sha2 ^0.11. (2) Upgrade jsonwebtoken to a release that declares sha2 = "^0.11" (if one exists), allowing both constraints to be satisfied simultaneously.

Step-by-step proof

  1. crates/apollo-mcp-rhai/Cargo.toml line 19: sha2 = "0.11.0" — pinned to exactly 0.11.0.
  2. crates/apollo-mcp-server/Cargo.toml (workspace): jsonwebtoken = "^10.3", locked to jsonwebtoken v10.3.0.
  3. jsonwebtoken v10.3.0's own Cargo.toml declares sha2 = "^0.10.7" — semver range [0.10.7, 0.11.0).
  4. Cargo resolver must unify: sha2 == 0.11.0sha2 ∈ [0.10.7, 0.11.0) = ∅ (empty set).
  5. Result: error: failed to select a version for the requirement sha2 = "^0.10.7", candidate versions found which didn't match: 0.11.0 — exactly as reported by svc-secops bot on 2026-03-28.

Copy link
Copy Markdown
Member

@DaleSeo DaleSeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting this on hold. jsonwebtoken v10.3.0 requires sha2 ^0.10.7 and doesn't support 0.11 yet. This causes a duplicate sha2 in Cargo.lock and the Renovate artifact check to fail. We'll revisit once jsonwebtoken releases a version compatible with sha2 0.11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants