fix(deps): drop lru 0.7.8 from reed-solomon-erasure (RUSTSEC-2026-0253)

[dirvine]

Follow-up to #28. That squash-merge (e974bb4) still left lru 0.7.8 on main via reed-solomon-erasure 6.0.0.

This PR is only the vendor / [patch.crates-io] commit cherry-picked onto current origin/main, plus a License Compliance exclude for the vendor tree. It does not replay #28.

Why a vendor patch

Latest published reed-solomon-erasure is still 6.0.0 and still depends on lru ^0.7.8. RUSTSEC-2026-0253 is patched only in lru >= 0.18.2. No upstream upgrade exists.

Changes

• Workspace [patch.crates-io] points at third_party/reed-solomon-erasure (upstream 6.0.0 + lru 0.18.2 + NonZeroUsize for LruCache::new).
• Cargo.lock has no lru version < 0.18.2.
• License Compliance SPDX scan skips */third_party/* so upstream vendor sources are not rewritten.
• Does not ignore RUSTSEC-2026-0253.
• Leaves the existing RUSTSEC-2026-0215 ignore (yrs/smallstr) already on main.

Verify

cargo deny check advisories

Local result: advisories ok. Lockfile contains only lru 0.18.2.

Refs:

• https://rustsec.org/advisories/RUSTSEC-2026-0253
• fix(deps): resolve RUSTSEC-2026-0213, 0204, 0257, 0253; ignore yrs smallstr #28

  

Greptile Summary

The PR vendors reed-solomon-erasure 6.0.0 and applies a workspace override to replace vulnerable lru 0.7.8 with 0.18.2.

• Adds a local patched copy of reed-solomon-erasure and documents the divergence from upstream.
• Updates the LRU cache constructor for the newer NonZeroUsize API.
• Regenerates Cargo.lock so workspace builds resolve only lru 0.18.2.
• The root-only patch does not protect downstream users of the published communitas-core crate.

Confidence Score: 3/5

This PR should not merge until the published communitas-core artifact also delivers the lru remediation to downstream consumers.

Workspace builds use the safe vendored dependency, but publishing communitas-core drops the root patch and restores the vulnerable crates.io dependency chain for downstream applications.

Files Needing Attention: Cargo.toml, communitas-core/Cargo.toml, and third_party/reed-solomon-erasure/build.rs

Security Review

Published communitas-core consumers still resolve the crates.io reed-solomon-erasure 6.0.0 package and its vulnerable lru 0.7.8 dependency because workspace-root Cargo patches are not propagated into published crates.

Important Files Changed

Filename	Overview
Cargo.toml	Adds the workspace exclusion and local crates.io override, but the override cannot accompany independently published workspace crates.
Cargo.lock	Correctly removes lru 0.7.8 and resolves local workspace builds to the patched reed-solomon-erasure with lru 0.18.2.
third_party/reed-solomon-erasure/Cargo.toml	Preserves the upstream package and feature metadata while updating the lru dependency to 0.18.2.
third_party/reed-solomon-erasure/src/core.rs	Correctly adapts LruCache construction to the NonZeroUsize API while retaining the nonzero capacity of 254.
third_party/reed-solomon-erasure/build.rs	Vendors the upstream build logic but introduces production unwrap calls contrary to repository rules.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Workspace build] --> B[Root patch.crates-io]
  B --> C[Vendored reed-solomon-erasure 6.0.0]
  C --> D[lru 0.18.2]
  E[Published communitas-core consumer] --> F[communitas-core manifest]
  F --> G[crates.io reed-solomon-erasure 6.0.0]
  G --> H[lru 0.7.8]

Loading

Prompt To Fix All With AI

### Issue 1
Cargo.toml:80-83
**Published crate bypasses security patch**

When a downstream application installs the published `communitas-core` crate, the workspace-root `[patch.crates-io]` entry is not included in that package, so Cargo resolves the crates.io `reed-solomon-erasure` 6.0.0 release and restores its vulnerable `lru` 0.7.8 dependency. **How this was verified:** The published crate manifest still declares `reed-solomon-erasure = "6.0.0"`, while the replacement exists only in the workspace root.

### Issue 2
third_party/reed-solomon-erasure/build.rs:119
**Vendored build script uses unwrap**

The newly vendored production build script uses `unwrap()` here and at the generated-output and target-architecture operations on lines 123 and 165. These panic-based failure paths violate the repository rule requiring production Rust code to handle or propagate errors, producing opaque build failures when file operations or required environment state fail.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(deps): patch reed-solomon-erasure of..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

Context used:

• Context used - CLAUDE.md (source)

[claude]

Review

Clean, well-scoped fix. This vendors reed-solomon-erasure 6.0.0 via [patch.crates-io] with lru bumped from 0.7.8 → 0.18.2, closing out RUSTSEC-2026-0253 (UAF in LruCache::pop()) since no upstream release exists that fixes it.

Verified:

• Cargo.lock no longer contains lru 0.7.8 (or its now-orphaned hashbrown 0.12.3/ahash 0.7.8 transitive deps) — only lru 0.18.2 remains.
• The vendored crate's declared version (6.0.0) matches what communitas-core/Cargo.toml requests (reed-solomon-erasure = "6.0.0"), so [patch.crates-io] applies cleanly rather than silently failing to match.
• The two intentional deltas from upstream are small and correctly scoped: Cargo.toml dep bump, and src/core.rs switching LruCache::new to take NonZeroUsize (required since lru 0.8+). The .expect("DATA_DECODE_MATRIX_CACHE_CAPACITY is non-zero") there is safe — the capacity is a compile-time constant (254), and this file lives in third_party/, which is excluded from the workspace member list, so it's outside the -D clippy::expect_used gate anyway.
• third_party/reed-solomon-erasure is added to the root Cargo.toml exclude list with a clear comment on why, and deny.toml's [sources] denial of unknown registries/git doesn't affect local path patches.
• COMMUNITAS_PATCH.md documents the rationale and gives a clear removal condition ("remove this vendor when upstream publishes a release that depends on lru >= 0.18.2"), and the original MIT LICENSE is retained — good for license compliance on a vendored copy.

Minor suggestions (non-blocking):

1. Consider adding a comment in deny.toml near the [bans]/[advisories] section (or in COMMUNITAS_PATCH.md) noting that this vendor exists specifically to satisfy the advisory check, so a future contributor doesn't accidentally revert to the crates.io version while triaging an unrelated cargo update.
2. Since the diff shows the vendored files as brand-new file additions, there's no diff-based guarantee the untouched files (src/lib.rs, src/matrix.rs, src/galois_8.rs, etc.) are byte-for-byte identical to the upstream 6.0.0 tarball beyond the two documented edits. Not a concern for this review (I have no reason to doubt it), but it may be worth a one-time CI check (e.g. diff against a pinned upstream tarball hash) if this vendor sticks around for a while, to catch accidental drift on future edits.
3. [bans] multiple-versions = "warn" in deny.toml means a future dependency bump that reintroduces a second lru/hashbrown version wouldn't hard-fail CI — worth keeping in mind, though out of scope for this PR.

No security, correctness, or test-coverage concerns beyond the above. The Cargo.lock diff is minimal and targeted (no unrelated version churn), which is exactly what you want in a dependency-patch PR.

[greptile-apps]

Published crate bypasses security patch

When a downstream application installs the published communitas-core crate, the workspace-root [patch.crates-io] entry is not included in that package, so Cargo resolves the crates.io reed-solomon-erasure 6.0.0 release and restores its vulnerable lru 0.7.8 dependency. How this was verified: The published crate manifest still declares reed-solomon-erasure = "6.0.0", while the replacement exists only in the workspace root.

Prompt To Fix With AI

This is a comment left during a code review.
Path: Cargo.toml
Line: 80-83

Comment:
**Published crate bypasses security patch**

When a downstream application installs the published `communitas-core` crate, the workspace-root `[patch.crates-io]` entry is not included in that package, so Cargo resolves the crates.io `reed-solomon-erasure` 6.0.0 release and restores its vulnerable `lru` 0.7.8 dependency. **How this was verified:** The published crate manifest still declares `reed-solomon-erasure = "6.0.0"`, while the replacement exists only in the workspace root.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Vendored build script uses unwrap

The newly vendored production build script uses unwrap() here and at the generated-output and target-architecture operations on lines 123 and 165. These panic-based failure paths violate the repository rule requiring production Rust code to handle or propagate errors, producing opaque build failures when file operations or required environment state fail.

Context Used: CLAUDE.md (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: third_party/reed-solomon-erasure/build.rs
Line: 119

Comment:
**Vendored build script uses unwrap**

The newly vendored production build script uses `unwrap()` here and at the generated-output and target-architecture operations on lines 123 and 165. These panic-based failure paths violate the repository rule requiring production Rust code to handle or propagate errors, producing opaque build failures when file operations or required environment state fail.

**Context Used:** CLAUDE.md ([source](https://github.com/saorsa-labs/communitas/blob/main/CLAUDE.md))

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!