Repository navigation
build: make the workspace lockfile vendorable again - #5473
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 25 minutes. View limit details
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Configure BLS dependency sources Cargo.toml, packages/rs-dpp/Cargo.toml |
The workspace adds dashcore-crypto and patches four Bitcoin crates to a pinned rust-bitcoin revision. rs-dpp replaces the optional dash-pkc dependency and enables BLS through dashcore-crypto. |
Use re-exported BLS types packages/rs-dpp/src/bls/bls_signatures.rs, packages/rs-dpp/tests/bls_compatibility.rs |
The BLS implementation and compatibility test use types from dashcore_crypto::dash_pkc::bls. |
Invitation WIF test
| Layer / File(s) | Summary |
|---|---|
Validate WIF Base58 checksum packages/rs-sdk/src/platform/dashpay/invitation.rs |
The WIF round-trip test uses decode_check before checking the network byte. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related issues
- build: shrink the vendoring
[patch.crates-io]on the next rust-dashcore bump #5648: This follow-up concerns the root Cargo patch entries added in this change and their reduction during a laterrust-dashcorerevision update.
Possibly related PRs
- dashpay/platform#5517: Updates workspace
rust-dashcoredependencies, which can change the dependency sources aligned here. - dashpay/platform#5639: Updates workspace
rust-dashcoredependencies and lockfile source resolution. - dashpay/platform#5471: Moves the invitation codec into
rs-sdkand includes related WIF handling.
Suggested reviewers: lklimek, shumkov
Merge Risk: 
Minimal · previous review 44b4c
-
The dependency alignment and WIF test update are consistent with their intended contracts, with no established merge-blocking risk.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passedFull details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 2 functions across 3 files. (2 skipped: 2 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 2
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🛠️ Fix failing CI checks: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
|
Waiting for bot review — coderabbitai not yet · thepastaclaw ✓. Wait for the missing reviews, or a writer can post |
|
✅ Final review complete — no blockers (commit c7b0e20) · triage: normal |
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Phase 1 + Phase 2
Verified the complete two-file diff at head 42a2204 against the supplied reviewer evidence and cached upstream sources; no actionable in-scope defects were found. The patches use the existing rust-bitcoin revision, and the lockfile removes six registry packages without adding packages or retaining duplicate name/version pairs. This was static verification only: the supplied CI snapshot shows Kotlin checks passing, Rust workspace and wallet tests skipped, and PR Hygiene pending; vendoring and Rust build/test results were not independently reproduced.
Review provenance
Source: reviewer 1: gemini-3.8-flash-high (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
lowbygpt-6.1-sol(effort low) — The diff is a small, contained build fix that unifies four dependency sources and removes duplicate lockfile entries without changing application logic. - Phase 1 reviewers:
gemini-3.8-flash-high— general (completed, effort high); agentphase1-reviewer - Phase 1 model:
gemini-3.8-flash-high— antigravity quota: weekly 71% left, 5h 100% left - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort medium); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort medium); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort medium); agentphase2-reviewer
|
@coderabbitai review No review for |
) * [c5534aa] sdk%build: take rust-bitcoin crates from `rust-dashcore`'s revision (pasta) * [9cf731c] sdk%build: take sample rust-bitcoin crates from the same revision (pasta) * [9eb1280] pkc%refac: group external test imports in `secret_bytes` (pasta) Description: ````` ## Summary Take the rust-bitcoin crates from the same git revision that `rust-dashcore`'s `bitcoin-crypto` uses (`7ba35c7c`), instead of from crates.io. - `base58ck`, `bitcoin_hashes`, `bitcoin-consensus-encoding`, `bitcoin-internals`, `bitcoin-primitives` and `bitcoin-units` become `{ version, git, rev }` workspace dependencies. Keeping `version` means `cargo publish` still resolves them from crates.io. - That revision drops `base58ck::decode`, so `pkgs/pkc/src/ecdsa/secret_bytes.rs` reads checksums through `decode_check`. - `Cargo.lock` is regenerated. ## Why `rust-dashcore` needs secp256k1 0.33, but the published `bitcoin-crypto` 0.3.0 still uses 0.32, so it takes `bitcoin-crypto` from a rust-bitcoin git revision. A git dependency also pulls its sibling crates from that revision, so `rust-dashcore` ends up with git copies of `base58ck` 0.5.0, `bitcoin_hashes` 1.2.0, `bitcoin-internals` 0.7.0 and `bitcoin-units` 0.5.0. `base-sdk` takes the same crates by version from crates.io. The two copies share a name and version but not code (`base58ck`'s `src/lib.rs` differs by 428 lines), so Cargo builds both side by side. `cargo vendor` cannot: it keys vendored directories by name and version and fails with ``` found duplicate version of package `base58ck v0.5.0` vendored from two sources: crates-io, and git rust-bitcoin rev 7ba35c7c1dd6 ``` Dash Core's depends and Guix builds vendor the Platform workspace offline, so this blocks any Platform commit that pulls in both. dashpay/platform#5473 works around it with a root `[patch.crates-io]`, which Cargo only honours at the top level of a build; this change removes the disagreement at its source. ## Follow-ups (not in this PR) 1. `rust-dashcore`: point its direct `base58ck` (and `bitcoin_hashes`) dependency at the same git revision and bump its `base-sdk` pin. 2. `platform`: bump the `rust-dashcore` pin and drop the `[patch.crates-io]` workaround from #5473. The git revision is temporary; once a `bitcoin-crypto` release on secp256k1 0.33 is published, all of these can return to crates.io versions. ## Testing - `cargo test --workspace --locked`: passes. - `cargo clippy --workspace --all-targets --locked -- -D warnings` and `cargo fmt --all --check`: clean. - `cargo deny check` (advisories, bans, licenses, sources): ok. - `cargo vendor --locked`: succeeds; each of the six crates appears once in `Cargo.lock`, all from the git source. - `maint/lint/lint_commit.py -c HEAD`: passes. Not run locally: `taplo` (TOML format), CodeQL and semgrep lints. 🤖 Generated with [Claude Code](https://claude.com/claude-code) `````
42a2204 to
01d2c8d
Compare
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
The dependency-source unification and lockfile changes match the stated vendoring goal, and the updated Base58 test uses the available checked decoder correctly. However, patching the pinned Dashcore dependency removes dpp::dashcore::base58::decode through DPP’s public re-export, so the PR’s “Breaking Changes: None” declaration is inaccurate. Rust workspace tests and JS builds were still in progress, with no failed code checks reported.
🟡 2 suggestion(s)
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — This is a cross-cutting dependency and build-resolution change with a small API call adjustment, but dependency and lockfile changes do not by themselves meet the critical-surface bar. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `Cargo.toml`:
- [SUGGESTION] Cargo.toml:85-88: Declare or preserve the removed public Base58 API
These patches select the rust-bitcoin revision whose Base58 API no longer provides `decode`. Because `packages/rs-dpp/src/lib.rs:16` publicly re-exports `dashcore`, downstream users can observe this through `dpp::dashcore::base58::decode`, which will no longer compile. Updating the internal invitation test covers Platform’s only current caller but does not preserve downstream compatibility. Either retain a compatibility API in the owning rust-dashcore layer, or mark this release as breaking and document migration to `decode_check`; the current `Breaking Changes: None` declaration is inaccurate.
- [SUGGESTION] Cargo.toml:79-88: Add a CI guard for duplicate Cargo sources
The PR’s primary goal is to keep `cargo vendor --locked` working, but the repository has no persistent check that detects a future same-name, same-version package resolving from multiple sources. A later dependency bump could silently reintroduce the split and break Dash Core’s offline bundle. Add a lightweight CI guard, such as running `cargo vendor --locked` into a temporary directory or checking the lockfile for duplicate `(name, version)` pairs with different sources.
|
Bots are done — your move: post |
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
44b4c42 to
1cb6deb
Compare
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
`cargo vendor --locked` cannot put one name and version from two sources into a single directory source. `v5.1-dev` has two such splits: - rust-dashcore takes `bitcoin-crypto` from rust-bitcoin rev 7ba35c7c, whose base58ck 0.5.0, bitcoin_hashes 1.2.0, bitcoin-internals 0.7.0 and bitcoin-units 0.5.0 also come from crates.io through base-sdk and dashcore-crypto (since #5307); - rust-dashcore aca02026 pins base-sdk d9e0d241 while dpp kept dash-pkc at 33fcc59e, so dash-num, dash-pkc and dash-types come from two git revs (since #5514). No `[patch]` can merge those. Move dpp's dash-pkc to d9e0d241. Between the two revs `pkc` only moves its errors to thiserror (same messages), gates serde apart from codec and adds an ADX check that `portable` (enabled through dashcore/bls) satisfies. BLS signing and verification are unchanged. Patch crates.io to the same rust-bitcoin rev for the four crates. The git base58ck has no unchecked `decode`, which `dashcore::base58` re-exports, so the WIF test in rs-sdk's invitation module uses `decode_check`, which yields the same payload. The lockfile only loses packages: the duplicate copies, plus bitcoin-internals 0.5.0 and hex-conservative 0.3.2. #5648 tracks shrinking the patch on the next rust-dashcore bump. Co-Authored-By: Claude Opus 5.5 <[email protected]>
dpp pinned dash-pkc to a base-sdk rev of its own, which had to be kept equal to rust-dashcore's by hand: a second rev duplicates dash-pkc, dash-num and dash-types in the lockfile and breaks `cargo vendor`. dashcore-crypto already re-exports dash_pkc, so take it from there at the same rust-dashcore rev as dashcore. A rust-dashcore bump now carries dpp's dash-pkc with it. The lockfile keeps the same packages; only dpp's edge moves from dash-pkc to dashcore-crypto. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1cb6deb to
c7b0e20
Compare
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
The dependency consolidation at this exact head correctly removes same-name, same-version source splits and routes DPP's BLS code through the pinned rust-dashcore re-export. One in-scope regression-prevention suggestion remains: the repository has no lightweight guard against future duplicate Cargo sources; the Rust workspace test check is still in progress in the supplied CI snapshot, while no related failure is reported.
🟡 1 suggestion(s)
1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 9: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 10: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — This is a cross-cutting Rust dependency and lockfile change that alters the compiled cryptographic dependency revisions and a base58 test call, but it does not itself modify cryptographic algorithms, consensus rules, signatures, key handling, or other critical behavior. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer,muse-spark-1.3-contributor— rust-quality (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort high); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `Cargo.toml`:
- [SUGGESTION] Cargo.toml:86-90: Add a CI guard for duplicate Cargo sources
(existing thread: https://github.com/dashpay/platform/pull/5473#discussion_r4406228931)
This PR fixes a vendoring failure that can be reintroduced by a later dependency update: two packages with the same name and version resolved from different sources cause `cargo vendor --locked` to fail. The existing Dash Core bundle check runs only when Dash Core moves its Platform pin, so it is a late and conditional signal rather than a repository-level regression check. Add a lightweight lockfile check for duplicate `(name, version)` pairs with distinct `source` values, or an appropriate focused vendoring validation, so dependency changes detect this invariant before the next downstream pin bump.
|
Bots are done — your move: post |
|
Approved |
Issue being fixed or feature implemented
Dash Core builds Platform offline from a vendored workspace (dashpay/dash#7623). Its bundle script runs
cargo vendor --locked, and that fails onv5.1-dev:Cargo can't put one name and version from two sources into a single directory source.
v5.1-devhas two such splits, which #5307 and #5514 introduced:bitcoin-cryptofrom rust-bitcoin rev 7ba35c7c, because the crates.io release needs secp256k1 0.32, not 0.33. That rev also carries base58ck 0.5.0, bitcoin_hashes 1.2.0, bitcoin-internals 0.7.0 and bitcoin-units 0.5.0. base-sdk and rust-dashcore'sdashcore-cryptotake the same versions from crates.io.aca02026, which pins base-sdkd9e0d241. dpp kept its owndash-pkcat33fcc59e, sodash-num,dash-pkcanddash-types0.1.0-beta appear from two git revisions.[patch]can't merge those.What was done?
dash-pkcfromdashcore-crypto's re-export (dashcore_crypto::dash_pkc) instead of pinning base-sdk itself.dashcore-cryptois a new workspace dependency at the same rust-dashcore rev asdashcore. This makes dpp used9e0d241, the base-sdk revision rust-dashcore already uses, and every rust-dashcore bump now moves it too.[patch.crates-io]that points the four rust-bitcoin crates at the same rev asbitcoin-crypto. Each of the four is needed: the vendor probe was rerun one line at a time, and each line uncovered the next duplicate.Cargo.lock. Nine packages are removed and nothing is added or changes version; dpp's own entry listsdashcore-cryptoinstead ofdash-pkc. The removed packages are:33fcc59ecopies ofdash-num,dash-pkcanddash-types;bitcoin-internals0.5.0 andhex-conservative0.3.2, which only the crates.iobitcoin-unitsused.What changes in compiled code:
dpp's BLS code now builds against
dash-pkcd9e0d241instead of33fcc59e. Between those revisions thepkcsources change only in these ways:thiserrorwith the same messages;len() % 16 != 0becomes!len().is_multiple_of(16);serdeno longer impliescodec;compile_error!fires forblson x86_64 without ADX unlessportableis on.BLS signing and verification are untouched. dpp's
bls-signaturesalways enablesdashcore/bls, which turns ondash-pkc/portable, so that check passes.blstwas already a single package built withportable, still at 0.3.17.The revision also raises base-sdk's MSRV to 1.89; the toolchain is 1.98. Because dpp's copy is now the same package as rust-dashcore's, it also gets
std,ecdsa,eddsaandserde. None of those features gate BLS code.dash-pkcanddashcore-cryptonow build against the gitbase58ckandbitcoin_hashes. The functions they use behave the same:encode_unbounded,decode_check,sha256,sha256dandripemd160are unchanged;encode_unboundedpanic on some 90-byte payloads.dashcore::base58re-exportsbase58ck, so it now has the git API. That API dropsdecode, the variant without the checksum. Platform's only call was a test inrs-sdk'sdashpay/invitation.rs. The test checks a WIF's network byte, and it now usesdecode_check, which returns the same payload with the checksum verified and stripped.[patch]only applies at the workspace root, so crates that depend on Platform by git are unaffected. dashpay/rust-dashcore#1224 removed thebase58cksplit upstream. Once Platform bumps past it, the patch shrinks tobitcoin-internalsalone; #5648 tracks that.How Has This Been Tested?
Cargo 1.98.1 (the pinned toolchain), on
v5.1-deva317e4d:cargo vendor --locked "$(mktemp -d)": fails onv5.1-dev, succeeds on this branch (822 crates).cargo check --locked --workspace --all-targetsandcargo clippy --locked --workspace --all-targets -- -D warnings: pass.cargo test --locked -p dpp --features bls-signatures --lib bls: 22 passed.cargo test --locked -p dpp --features bls-signatures --test bls_compatibility: 9 passed.cargo check --locked -p dpp --no-default-features: passes.cargo test --locked -p dash-sdk --lib should_round_trip_a_wif: passes.Breaking Changes
None.
Checklist:
structure.rs, regeneratedgrovedb-structure.json, and checked the structure viewer link posted on this pull requestFor repository code-owners and collaborators only
🤖 Generated with Claude Code
PR Hygiene ·
c7b0e20/self-reviewedCargo.lock,Cargo.toml) — QuantumExplorer or shumkovdpp(packages/rs-dpp/Cargo.toml,packages/rs-dpp/src/bls/bls_signatures.rs,packages/rs-dpp/tests/bls_compatibility.rs) — QuantumExplorer or shumkovrust-sdk(packages/rs-sdk/src/platform/dashpay/invitation.rs) — lklimek or shumkovWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.