[WomB0ComB0]

Summary

security / scan / osv-scanner has been red on main since 2026-09-29. The monorepo sync in #79 undid two earlier fixes: it re-added vendor/solana-program-test/Cargo.lock, which #33 had deleted, and it moved memmap2 back to 0.9.10, which #55 had fixed. Since then, two new advisories have landed against the root lock. This PR deletes the nested lockfile again and moves memmap2, quinn-proto and rustls to their patched versions. It changes only lockfiles.

Before (osv-scanner v2.3.5, scan source --recursive ./, the same command the reusable job runs):

Total 33 packages affected by 62 known vulnerabilities (0 Critical, 12 High, 11 Medium, 10 Low, 29 Unknown)
  52 rows -> vendor/solana-program-test/Cargo.lock
  10 rows -> Cargo.lock   (memmap2 0.9.10, quinn-proto 0.11.15 x5, rustls 0.23.45 x4)

After:

Scanned .../Cargo.lock file and found 805 packages
Filtered 5 ignored package/s from the scan.
Filtered 11 vulnerabilities from output
No issues found

Why the nested lockfile is unused

solana-program-test comes in through [patch.crates-io] as a path dependency, and the vendored crate is not a workspace member. Cargo resolves it through the root Cargo.lock and never reads vendor/solana-program-test/Cargo.lock:

• cargo metadata --locked lists the workspace root as the repo root, the members as resq-delivery, resq-airspace and resq-gating, and solana-program-test 3.1.10 with source = null and manifest_path = vendor/solana-program-test/Cargo.toml.
• cargo tree --locked -i solana-program-test prints solana-program-test v3.1.10 (.../vendor/solana-program-test) under [dev-dependencies] of the three programs.
• The resolved graph disagrees with the nested lock. For example, cargo resolves openssl 0.10.80, tar 0.4.46 and time 0.3.47, while the nested lock pins openssl 0.10.74, tar 0.4.44 and time 0.3.9.
• After deleting the nested lock, cargo metadata --locked still succeeds and the root Cargo.lock is byte-for-byte unchanged (same sha256).

osv-scanner treats the nested lock as a separate project, and the root osv-scanner.toml filters do not reach it: RUSTSEC-2025-0141, im 15.1.0 and memmap2 0.5.10 are filtered in the root and still reported against the vendor lock. The root osv-scanner.toml already documents the lockfile as removed, to match vendor/solana-invoke and vendor/solana-keypair, which ship none. So this PR deletes the lockfile again rather than adding a second config.

Root lock bumps

package	before	after	advisories
memmap2	0.9.10	0.9.11	RUSTSEC-2026-0186
quinn-proto	0.11.15	0.11.18	RUSTSEC-2026-0338, -0339, -0340, -0341, -0342
rustls	0.23.45	0.23.46	RUSTSEC-2026-0346, -0347, -0348, -0349

These are semver-compatible cargo update -p <crate> --precise <ver> bumps. quinn-proto 0.11.18 also adds chacha20 0.10.2 and rand_pcg 0.10.2. Package count goes from 803 to 805. memmap2 0.5.10 stays: the existing version-scoped override covers it, and its comment ("0.9.x path already updated to the fixed 0.9.11") is accurate again.

All three are dev-only. cargo tree --locked -e normal,build --target all -i <crate> prints nothing for each, so none of them reach the on-chain programs. They come in only through the vendored solana-program-test dev-dependency.

Type of change

• fix — bug fix
• build — build system or external dependency

Test plan

Local, Rust 1.99.0 stable, with the same flags as the reusable rust-ci.yml:

• cargo fmt --all --check: clean
• cargo clippy --locked --all-targets --all-features -- -D warnings: clean
• cargo test --locked --all-features --workspace: 59 passed, 0 failed. This includes the solana-program-test integration suites for airspace (17 + 1), delivery (9) and gating (4).
• cargo-build-sbf (Solana 3.1.10 platform tools, matching the pinned solana-program-test 3.1.10): all three programs build and the root lock is unchanged afterwards.
• osv-scanner scan source --recursive ./ with v2.3.5: No issues found
• resq pre-commit: copyright, large files, debug statements, secrets and audit all pass

anchor build with the installed anchor-cli 1.1.2 fails with Error: String is the wrong size, and it fails the same way on unchanged main. The CLI rejects the placeholder program IDs in Anchor.toml before it compiles anything, so the failure is unrelated to this change.

Breaking changes

None.

Checklist

• Commits follow Conventional Commits (commit-msg hook will reject otherwise)
• Branch name matches the allowed pattern (pre-push hook will reject otherwise)
• resq pre-commit / resq format --check clean locally
• New code has tests (or a deliberate note on why not): lockfile only, covered by the existing suites above
• Docs updated (AGENTS.md / README / inline) for user-visible changes: none needed, osv-scanner.toml already describes this state
• Security-sensitive changes acknowledged (secrets, auth, input validation): dependency advisories only

Follow-up

The next sync from the monorepo will bring both regressions back unless the monorepo copy of this crate also drops vendor/solana-program-test/Cargo.lock and takes these lock bumps.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters: 2

• Cargo.lock is excluded by !**/*.lock
• vendor/solana-program-test/Cargo.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 358a503b-1dd3-4a4b-8ee6-2112705ea198

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• 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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}