One cache budget is enforced twice over two subtrees, so the cache holds about twice the configured cap

[MichaelTaylor3d]

Task

cache_cap_bytes() is enforced independently by two eviction paths over two different subtrees, so the configured cap bounds each half rather than the whole.

The defect

• crates/dig-node-core/src/lib.rs:1106 -- plan_eviction reads cache_cap_bytes() at lib.rs:2154, over <cache>/responses.
• crates/dig-node-core/src/lib.rs:2340 -- evict_modules_locked reads the same cache_cap_bytes() at lib.rs:2342, over <cache>/modules.

Neither knows about the other, so a node configured for N bytes can hold close to 2N.

The reporting compounds it: dispatch.rs:526 reports used_bytes = total() against one cap_bytes, so displayed usage can exceed the cap it is shown against -- and dig-app's storage warning derives from that number (dig-app-core/src/cache.rs:211). A user watching the figure sees an impossible state and has no way to tell which half is over.

The sharper half: the response cache is attacker-orderable

plan_eviction ranks on mtime, and serve_cached_response calls touch() on every hit (lib.rs:2116). The serving path is inbound peer traffic -- so a peer's ordinary requests order this node's eviction, keeping its content resident and pushing another peer's out.

evict_modules_locked already refuses to do this: it passes last_access: 0 and names this exact attack at lib.rs:2347-2358. So the node contains both the defect and its own written-down diagnosis, in one file, on two paths.

Survivor

dig_store_cache::EvictionPolicy with dig_sex::TieredPolicy, which the modules path already uses.

Scope

Route <cache>/responses through the same seam, and split one budget across both subtrees rather than applying it twice. Whatever the split, used_bytes and cap_bytes must describe the same thing.

Related: DIG-Network/dig-store-cache#3, where LruPolicy has the same attacker-orderable recency defect at its source.

Evidence

Tests that fail without the fix: the sum across both subtrees stays under the configured cap; and repeated serving of one capsule does not change which entry is evicted next.

Parent

Rival-centralization epic: https://github.com/DIG-Network/dig_ecosystem/issues/3140

[MichaelTaylor3d]

Fixed on lane loop/batch-cache, draft PR #455, commit 4d5d3cf.

Shape: one cap, split into named shares, rather than one number read twice.

cache_budget() divides cache_cap_bytes() into a responses share (an eighth) and a modules share (the rest). evict_if_needed spends the first; evict_modules_locked spends the second.

Why a reserved share and not "modules take whatever responses leave". Sizing each sweep against the other's live usage also converges to the right total, but it starves whichever subtree loses the race — and the response cache, made of small regenerable windows, always loses to ~135 MiB capsules. A cache that evicts every response the instant it is written is a bound that starves the work it protects.

used_bytes (usage.total()) and cap_bytes now describe the same thing, so the dig-app storage warning at dig-app-core/src/cache.rs:211 can no longer show an impossible state.

Test: one_budget_bounds_both_cache_subtrees_together. It fills both subtrees past 2x the cap, runs both sweeps, and asserts bytes actually on disk (bytes_on_disk, a real recursive walk) against the configured cap — not that a function was called, and not against a policy's victim list. It carries two guards that make it evidence rather than a coincidence: the fixture asserts it starts above 2x the cap, and a control asserts the cache is not empty afterwards, since an over-evicting cache would satisfy the bound trivially.

Revert-proof (committed first, reverted by file copy): restoring cache_cap_bytes() in both sweeps → FAILED. The 64-test cache suite is green with the fix in.

Not done here — the attacker-orderable half. The response cache still ranks on mtime and serve_cached_response still touch()es on every hit, so inbound peer traffic can still order this node's eviction. Routing <cache>/responses through dig_store_cache::EvictionPolicy / dig_sex::TieredPolicy (which already passes last_access: 0 and names this attack in-file) is the survivor the ticket names, and it is a larger change than the budget split. Flagging it as remaining rather than claiming it — the ticket should stay open for it, or get a sibling.