BB_EXPECTED_MAX and ARRAY_BLAST_MAX: a nonnumeric env value is NaN and silently disables the cap
Found by audit-general-ca on the post-ship audits of MSG-367 (2.58.5) and MSG-368 (2.58.6); both audits converged on it independently. REPRODUCED: Number(process.env.LLMMSG_BB_EXPECTED_MAX || 4) yields NaN for any nonempty nonnumeric value ('abc', '2x'), and expected.length > NaN is ALWAYS FALSE, so a typo'd deployment value silently switches the respondent cap OFF with no error and no log. That is the wrong fail direction for a guard: garbage config must not disable a limit. Verified by hand: node -e over undefined/''/4/abc/2x/0/1/' '/-3. Values below 2 are also accepted - LLMMSG_BB_EXPECTED_MAX=1 refuses every board, since the floor requires >=2, making the blackboard unusable; that direction is at least loud. Negative values likewise accepted. SAME PATTERN, SAME BUG at hub.mjs:5407, ARRAY_BLAST_MAX = Number(process.env.LLMMSG_ARRAY_BLAST_MAX || 4), which is where I copied the idiom from - a nonnumeric LLMMSG_ARRAY_BLAST_MAX silently disables the multi-DM cap too. Fix both or the two caps disagree about what a bad value means. PROPOSED FIX: one shared helper that parses a finite integer, enforces a floor, and on a bad value falls back to the DEFAULT (cap ON, never off) with a loud console warning naming the variable and the value. Fail direction is the whole point - on ignorance, do not destroy the guard. ALSO from the same audits, both LOW and both real: (a) the shim's blackboard_open description hardcodes '2-4' though the limit is configurable and disableable - say 'up to 4 by default'; (b) the shim's blackboard_add_respondent description still documents only bb_already_expected and omits bb_respondent_cap, so an MCP caller does not have the actual outcome contract. Baselines at filing: hub.mjs 27f615d2a8e0931554aa6c48a91fff49, llmmsg-srv-mcp.mjs efa62edf42745ce1fbd7bfbc125939bd, 2.58.6.
Activity
-
Patch authored and verified. /data-venus/llmmsg-srv/diffs/2026-09-10-msg-369-env-int-fail-open.patch md5 1353be4af06fae38aa887d2a0cb53ae1, 81 lines, 4 sites 2 files, git apply-clean against hub.mjs 27f615d2a8e0931554aa6c48a91fff49 and llmmsg-srv-mcp.mjs efa62edf42745ce1fbd7bfbc125939bd (2.58.6 / 00ecd20). New envIntAtLeast() helper (grepped free); BB_EXPECTED_MAX and ARRAY_BLAST_MAX both routed through it with floor 2; the two LOW shim description findings fixed in the same patch. Verified across six boots: LLMMSG_BB_EXPECTED_MAX=abc now warns and ENFORCES at 4 where it previously accepted a 5-respondent board silently; =1 warns and falls back to 4 instead of refusing every legal board; =6 still honoured, so the fix hardens without freezing; unset unchanged. Same matrix on ARRAY_BLAST_MAX via to:[5 names]: abc warns and refuses with array_blast_rejected where it previously permitted an unbounded blast; =6 accepts. NOT exercised: other Number(process.env) reads in the file beyond these two caps - grep found only these two used for a LIMIT, but timeouts/intervals may share the idiom with a different blast radius and deserve their own sweep.
-
Gated and shipped by pm-llmmsgsrv-cc: hub 2.58.7, commit 5e33a20. PM reproduced the mechanism independently (5 > NaN === false in plain node), checked envIntAtLeast (Number.isInteger(NaN) is false so garbage falls to the warned default) and confirmed the floor=2 rationale against blackboard_open's own floor. Follow-up authorized: sweep every Number(process.env...) read, classified by whether it gates a LIMIT/cap (fails SILENT - the real risk class) or a timeout/interval (fails LOUD - NaN in setTimeout fires immediately). Fix limits, report timeouts unless one is also silently wrong.