chore(deps): Bump sha2 from 0.10.9 to 0.11.0 in /Native/pcai_core - #84
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [sha2](https://github.com/RustCrypto/hashes) from 0.10.9 to 0.11.0. - [Commits](RustCrypto/hashes@sha2-v0.10.9...sha2-v0.11.0) --- updated-dependencies: - dependency-name: sha2 dependency-version: 0.11.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Owner
|
Closing — this does not build, and it would not be a net improvement even if it did. It breaks the build
RustCrypto 0.11 moves digest output from Verified locally against this branch's lockfile with And it would add a second copy of sha2Two transitive dependencies still require the 0.10 line, so this does not replace
So the cost is rewriting three call sites and compiling two SHA-2 implementations instead of one. The benefit is zero: 0.10.9 carries no advisory and Worth revisiting once the RustCrypto 0.11 line has propagated to the rest of the tree, at which point the migration consolidates rather than duplicates. #87 adds a |
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/cargo/Native/pcai_core/sha2-0.11.0
branch
September 8, 2026 15:04
David-Martel
added a commit
that referenced
this pull request
Sep 8, 2026
Review on #87 caught that `update-types: ["version-update:semver-major"]` does not match the bump it was written to block. Dependabot classifies an update by which SemVer *component* changed, and 0.10.9 -> 0.11.0 changes the minor component -- the major component stays 0. The consequence is worse than the ignore simply not firing. cargo-pcai-core groups minor and patch updates, so a bump classified as minor is eligible for the group: the next run could fold a known-broken sha2 0.11 into the grouped PR and block an otherwise good batch of updates behind it. `versions: [">=0.11.0"]` cannot be misclassified. It also covers the eventual 1.0 without another edit. Note the empirical picture is not clean either way. In the 2026-09 batch, genuine semver-minor bumps were grouped -- uuid 1.23.1 -> 1.26.0 and rayon 1.11.0 -> 1.12.0 both landed inside #83 -- while sha2 0.10.9 -> 0.11.0 alone was raised as its own PR (#84), which is what a major classification would produce. So Dependabot's Cargo handling may well already treat a 0.x minor as breaking. The range makes that question moot rather than betting on it. Verified: .github/dependabot.yml parses with all 8 update blocks intact and the cargo-pcai-core group unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mu7jB5ysKe4DN5ovjVtX1t
David-Martel
added a commit
that referenced
this pull request
Sep 8, 2026
* chore(deps): hold sha2 on the 0.10 line Dependabot raised sha2 0.10.9 -> 0.11.0 as #84. It does not build. RustCrypto 0.11 moves digest output from generic-array::GenericArray to hybrid-array::Array, and Array does not implement LowerHex, so every `format!("{:x}", hasher.finalize())` stops compiling: error[E0277]: the trait `LowerHex` is not implemented for `Array<u8, UInt<UInt<UInt<UInt<UInt<...>>>>>>` error: could not compile `pcai_core_lib` (lib) due to 3 previous errors sha2 is a direct dependency with three hex-formatting call sites: pcai_core_lib/src/hash.rs, pcai_core_lib/src/search/duplicates.rs, and pcai_perf_cli/src/main.rs. The bump would also not consolidate anything. cudaforge and openai-harmony still require the 0.10 line, so taking 0.11 directly means compiling two SHA-2 implementations rather than replacing one: cudaforge -> sha2 0.10.9 openai-harmony -> sha2 0.10.9 pcai_core_lib -> sha2 0.11.0 pcai-perf -> sha2 0.11.0 0.10.9 carries no advisory and cargo audit is clean on it, so the cost is three rewritten call sites and a duplicated hash implementation for no gain. Scoped to semver-major only, so minor and patch updates to sha2 keep arriving through the normal cargo-pcai-core group. This is the same reasoning as the candle pin in the /Deploy block: a stack that has to move as one coordinated piece, not one crate at a time. Verified: cargo check -p pcai_core_lib -p pcai-perf --all-targets against the #84 lockfile fails with the three errors above; the dependabot config parses with all 8 update blocks intact. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mu7jB5ysKe4DN5ovjVtX1t * fix(deps): express the sha2 hold as a version range, not an update-type Review on #87 caught that `update-types: ["version-update:semver-major"]` does not match the bump it was written to block. Dependabot classifies an update by which SemVer *component* changed, and 0.10.9 -> 0.11.0 changes the minor component -- the major component stays 0. The consequence is worse than the ignore simply not firing. cargo-pcai-core groups minor and patch updates, so a bump classified as minor is eligible for the group: the next run could fold a known-broken sha2 0.11 into the grouped PR and block an otherwise good batch of updates behind it. `versions: [">=0.11.0"]` cannot be misclassified. It also covers the eventual 1.0 without another edit. Note the empirical picture is not clean either way. In the 2026-09 batch, genuine semver-minor bumps were grouped -- uuid 1.23.1 -> 1.26.0 and rayon 1.11.0 -> 1.12.0 both landed inside #83 -- while sha2 0.10.9 -> 0.11.0 alone was raised as its own PR (#84), which is what a major classification would produce. So Dependabot's Cargo handling may well already treat a 0.x minor as breaking. The range makes that question moot rather than betting on it. Verified: .github/dependabot.yml parses with all 8 update blocks intact and the cargo-pcai-core group unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mu7jB5ysKe4DN5ovjVtX1t --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
David-Martel
added a commit
that referenced
this pull request
Sep 9, 2026
* docs(todo): reconcile four items against what actually happened TODO.md still described a state that three merges and a workflow deletion have since changed. Marking resolved items resolved, and correcting one that had become misleading rather than merely stale. Dependabot backlog -- drained to zero, was "6 open PRs, 1 high-severity alert". The alert is fixed and cargo audit on Native/pcai_core is exit 0 (776 dependencies, 0 vulnerabilities, 5 advisory warnings). Grouping landed in #71, so minor+patch now arrive as one PR per ecosystem. #85 took the 17-update grouped bump, #86 the four .NET test-package majors, #87 held sha2 below 0.11. #84 was refused on evidence, not deferred: RustCrypto 0.11 moves digest output to hybrid-array::Array, which lacks LowerHex, and two transitive deps still require the 0.10 line -- so it breaks three call sites and duplicates sha2. #88/#89/#90 were deferred rather than judged, because they target Deploy. Portable CI (Linux) -- moot, the workflow was deleted. The item asked for a measured timeout, which now cannot be measured and should not be: this repo targets Windows by design, and a Linux job running the PowerShell suite was a misconfiguration rather than coverage. Its one piece of real coverage, workspace-wide cargo checks, moved to rust-guidelines.yml on windows-latest. Left as a struck-through entry rather than deleted so the reasoning survives. CargoTools cargo shim -- second instance recorded. The same preflight that breaks `Build.ps1 -Component functiongemma-router-data` also breaks `cargo test --manifest-path <path> -p <crate>`, dying with a rustfmt usage dump that looks like the crate under test but is entirely the shim. `Get-Command cargo` resolves to ~\bin\cargo.ps1, not rustup's. Workaround for scoped builds is rustup's binary directly. Both instances are one bug in the shim's preflight argument construction, which is worth knowing before someone debugs the second as if it were unrelated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mu7jB5ysKe4DN5ovjVtX1t * docs(todo): reconcile the advisory-warning count with the crate list Review caught that "5 advisory warnings (core2, fxhash, number_prefix, paste)" names four crates for five warnings, which is internally inconsistent and exactly the kind of number nobody can later verify. The count is right and the list was incomplete rather than wrong: core2 is reported twice, once unmaintained and once yanked, so four crates produce five warnings. Spelled out, along with why the exit code is still 0 -- cargo audit fails on vulnerabilities, not warnings. Crate: core2 Warning: unmaintained Crate: fxhash Warning: unmaintained Crate: number_prefix Warning: unmaintained Crate: paste Warning: unmaintained Crate: core2 Warning: yanked warning: 5 allowed warnings found Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mu7jB5ysKe4DN5ovjVtX1t --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps sha2 from 0.10.9 to 0.11.0.
Commits
ffe0939Release sha2 0.11.0 (#806)8991b65Use the standard order of the[package]section fields (#807)3d2bc57sha2: refactor backends (#802)faa55fbsha3: bumpkeccakto v0.2 (#803)d3e6489sha3 v0.11.0-rc.9 (#801)bbf6f51sha2: tweak backend docs (#800)155dbbfsha3: add default value for theDSgeneric parameter onTurboShake128/256...ed514f2Use published version ofkeccakv0.2 (#799)702bcd8Migrate to closure-basedkeccak(#796)827c043sha3 v0.11.0-rc.8 (#794)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)