Uh oh!
There was an error while loading. Please reload this page.
chore: add cargo-deny + dependency-review + commitlint workflows - #22
Conversation
Mirrors the supply-chain hygiene already running on sentrix-labs/sentrix. sdk-rs publishes to crates.io as `sentrix-chain` — every release is a public artifact, so license + vuln gating on the dep tree matters. deny.toml: license allowlist + advisory yank-block + wildcard warning. cargo-deny.yml: workflow that runs `cargo deny check` on every PR + push. dependency-review.yml: pre-merge diff-only gate; license list mirrors deny.toml. commitlint.yml + .commitlintrc.json: Conventional Commits enforce. cargo-audit is intentionally NOT added — `cargo deny check` already scans the RustSec advisory DB through deny.toml [advisories].
📝 WalkthroughWalkthroughThis PR adds repository-level enforcement and checks: a Commitlint configuration and workflow to validate commit messages (conventional preset, header max 100, restricted type enum); a deny.toml cargo-deny configuration and a cargo-deny workflow that runs Sequence Diagram(s)sequenceDiagram
participant PR as Pull Request
participant GH_Actions as GitHub Actions
participant Runner as Actions runner
participant Checkout as actions/checkout
participant CargoDeny as EmbarkStudios/cargo-deny-action
PR->>GH_Actions: trigger cargo-deny workflow (PR/push/dispatch)
GH_Actions->>Runner: schedule job on ubuntu-22.04
Runner->>Checkout: checkout repository
Runner->>CargoDeny: run `cargo-deny check --all-features` with deny.toml
CargoDeny-->>Runner: analysis results
Runner-->>GH_Actions: job outcome
GH_Actions-->>PR: status/checks
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Both are unmaintained / deprecated advisories with no actual vulnerability — `paste` (transitive via alloy / sqlx / prost) and `rustls-pemfile` (transitive via reqwest -> rustls). Mirrors the ignore list in indexer-rs and the chain repo so policy is consistent across the org. Tested locally: `cargo deny --all-features check` → advisories ok.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@deny.toml`:
- Around line 40-45: Update the deny.toml ban policy entries: change the
multiple-versions rule and the wildcards rule from "warn" to "deny" when ready
(i.e., set multiple-versions = "deny" and wildcards = "deny") to prevent
duplicate dependencies and enforce explicit version pinning, while leaving
allow-wildcard-paths = true as-is; ensure you run the dependency check suite
after making these changes to catch any violations and address them before
committing.
- Line 35: Remove the unused "BUSL-1.1" entry from the license allowlist by
deleting the "BUSL-1.1" string from the allowlist array in deny.toml (the entry
shown as "BUSL-1.1",); ensure the allowlist remains valid TOML (commas and
quoting adjusted if necessary) after removal.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| "CC0-1.0", | ||
| "Zlib", | ||
| "0BSD", | ||
| "BUSL-1.1", |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash# Check if any dependencies use BUSL-1.1 license
cargo deny --all-features list 2>/dev/null | grep -i "busl\|business.source"||echo"No BUSL license found in dependency tree"Repository: Sentriscloud/sdk-rs
Length of output: 104
Remove unused BUSL-1.1 license from the allowlist.
No dependencies in the tree use BUSL-1.1. While the configuration allows unused licenses without error, this entry in the allowlist serves no purpose and can be safely removed to keep the configuration clean.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@deny.toml` at line 35, Remove the unused "BUSL-1.1" entry from the license
allowlist by deleting the "BUSL-1.1" string from the allowlist array in
deny.toml (the entry shown as "BUSL-1.1",); ensure the allowlist remains valid
TOML (commas and quoting adjusted if necessary) after removal.
There was a problem hiding this comment.
Skip — kept for forward-compat. sdk-rs is the SDK for Sentrix Chain whose workspace crates are all BUSL-1.1. If a future iteration adds a workspace path-dep on a chain crate (e.g. for shared types between server + client), the allowlist needs BUSL-1.1 already. Removing now and re-adding later = churn. Harmless idle entry.
There was a problem hiding this comment.
@satyakwok, that's a clear rationale — keeping BUSL-1.1 as a forward-compat entry makes sense given that the chain workspace crates are already BUSL-1.1 licensed, and unused-allowed-license = "allow" means the idle entry is entirely harmless. I'll note this for future reviews.
✏️ Learnings added
Learnt from: satyakwok
Repo: Sentriscloud/sdk-rs PR: 22
File: deny.toml:35-35
Timestamp: 2026-05-13T17:31:26.010Z
Learning: In `deny.toml` of the `sdk-rs` repository (Sentriscloud/sdk-rs), the `BUSL-1.1` entry in the `[licenses] allow` list is intentionally kept for forward-compatibility. `sdk-rs` is the SDK for Sentrix Chain, whose workspace crates are all BUSL-1.1 licensed. If a future iteration adds a path-dep on a chain crate (e.g. for shared types), the allowlist already covers it. The entry is harmless because `unused-allowed-license = "allow"` is set. Do not flag this as an unused/unnecessary entry.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| [bans] | ||
| # Multiple major versions tolerated for now; tighten later. | ||
| multiple-versions = "warn" | ||
| wildcards = "warn" | ||
| allow-wildcard-paths = true | ||
| highlight = "all" |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider tightening ban policies in future iterations.
The current configuration uses warn for multiple-versions and wildcards, which is reasonable for initial rollout. However, once baseline issues are resolved:
- Consider changing
multiple-versions = "deny"to prevent duplicate dependencies that increase binary size - Consider changing
wildcards = "deny"to enforce explicit version pinning for reproducible builds
The allow-wildcard-paths = true setting is appropriate as it only affects local path dependencies.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@deny.toml` around lines 40 - 45, Update the deny.toml ban policy entries:
change the multiple-versions rule and the wildcards rule from "warn" to "deny"
when ready (i.e., set multiple-versions = "deny" and wildcards = "deny") to
prevent duplicate dependencies and enforce explicit version pinning, while
leaving allow-wildcard-paths = true as-is; ensure you run the dependency check
suite after making these changes to catch any violations and address them before
committing.
There was a problem hiding this comment.
Skip for now — the comment itself frames this as "in future iterations after baseline issues are resolved". sdk-rs is at v0.1.0-alpha.0 with active migration churn (the sentrix-proto extraction lands in #23). Tightening multiple-versions/wildcards to deny right now would block legitimate transitive duplicates from alloy/leptos ecosystems mid-migration. Revisit at 1.0 stabilisation.
There was a problem hiding this comment.
@satyakwok — Makes sense. The rationale is solid: locking down multiple-versions/wildcards to deny mid-migration with alloy/leptos in the graph would produce noisy violations that aren't actionable yet. Keeping warn now and revisiting at 1.0 stabilisation is the right call.
Would you like me to open a GitHub issue tagged as a 1.0 milestone task to track the eventual tightening of these ban policies? That way it doesn't fall through the cracks when the migration settles.
Uh oh!
There was an error while loading. Please reload this page.
Why
sdk-rs publishes to crates.io as `sentrix-chain` — every release is a public artifact, so license + vuln gating on the dep tree matters. Mirrors the supply-chain hygiene already running on `sentrix-labs/sentrix`.
Per the repo hardening matrix (`research/02_repo_hardening_matrix.md`), this is MEDIUM priority — `gitleaks` was already in place; this PR closes the remaining 3 supply-chain gaps.
What
`cargo-audit` is intentionally NOT added — `cargo deny check` already scans the RustSec advisory DB through `deny.toml [advisories]`.
Test plan
Summary by CodeRabbit