fix(deps): clear the outstanding RUSTSEC advisories - #55
Conversation
osv-scanner has been failing the security job with four unpatched advisories. Three lift cleanly with `cargo update`, and a fourth (event-listener) has been published since the last run: anyhow 1.0.102 -> 1.0.104 RUSTSEC-2026-0190 crossbeam-epoch 0.9.18 -> 0.9.20 RUSTSEC-2026-0204 memmap2 0.9.10 -> 0.9.11 RUSTSEC-2026-0186 event-listener 5.4.1 -> 5.4.2 RUSTSEC-2026-0221 memmap2 also resolves a second time at 0.5.10, reached only through the vendored solana-program-test dev-dependency. That chain pins the 0.5.x line, so it cannot be lifted without an upstream Solana bump — filtered with a rationale, matching how the other unfixable transitive advisories are handled. The first-order 0.9.x path is genuinely fixed, not filtered. Also drop a duplicate RUSTSEC-2026-0173 block. osv-scanner was warning "multiple ignores ... only the first will be used" and reporting the second as an unused ignore; the two rationales disagreed about the dependency path, and the retained one matches what the scanner actually reports.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe PR updates ChangesAdvisory configuration
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@osv-scanner.toml`:
- Around line 73-83: Scope the RUSTSEC-2026-0186 exception in [[IgnoredVulns]]
to memmap2 version 0.5.10 and its documented dev-dependency/vendor path, using
the supported version-scoped override or an ignoreUntil date tied to the
expected Solana upgrade. Ensure future affected versions or non-dev dependency
paths are still reported, while preserving the existing 0.9.11 fix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d505c531-8d9f-4212-87f0-a7969dd45c06
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
osv-scanner.toml
|
Audit passed. The dependency updates correctly address several RUSTSEC advisories, including the update of Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
network:
allowed:
- defaults
- "localhost"See Network Configuration for more information.
|
Addresses review feedback on the RUSTSEC-2026-0186 entry. IgnoredVulns matches by advisory ID alone, so the previous block suppressed the advisory across the whole scan. A future regression onto an affected memmap2 version — including on a non-dev path — would have been silently swallowed, which is not what the rationale claimed the exception covered. Switch to a version-scoped PackageOverrides pinned to memmap2 0.5.10, the only copy that cannot be lifted (dev-dep-only, via vendored solana-program-test). Verified: the scan still reports "No issues found", and the filter line now reads "Package crates.io/memmap2/0.5.10 has been filtered out" rather than naming the advisory. Repointing the override at an absent version makes RUSTSEC-2026-0186 fire on 0.5.10 again, confirming the scoping is real.
What
The
osv-scannerstep has been failing the security job. Unlike the other CI failures in this org, the scanner was working correctly — it was reporting four genuinely unpatched advisories:So this is a dependency bump, not a workflow change.
Changes
Cargo.lock— four crates lifted onto fixed versions:anyhowcrossbeam-epochmemmap2event-listenerevent-listenerwas not in the original failure — that advisory was published after the last scan on 28 Jul, and would have turned the job red again on the next run regardless.osv-scanner.toml— two corrections:Added
RUSTSEC-2026-0186.memmap2resolves twice. The 0.9.x path is genuinely fixed above. The 0.5.10 copy is reachable only through the vendoredsolana-program-testdev-dependency:That chain pins the 0.5.x line, so
cargo updatecannot lift it without an upstream Solana bump. Filtered with a rationale, consistent with the seven existing entries for unfixable transitive advisories. The comment records that the entry covers only the dev-dep path and should be dropped when Solana moves offmemmap20.5.Removed a duplicate
RUSTSEC-2026-0173block. The scanner was warning:The two blocks disagreed about the dependency path — one said "via anchor-lang derive macros", the other "via aquamarine → solana-runtime → solana-program-test". Kept the latter, which matches what the scanner actually reports.
Verification
multiple ignoresorunused ignoreswarnings remaincargo check --workspace— exit 0Cargo.tomlchanges; lockfile-only, all within existing semver rangesSummary by CodeRabbit
memmap20.5.10 development dependency.memmap2versions.memmap20.9.11 release.