File-sourced configuration paths have never been audited for silent defaults #290

New Issue

clawbot · 2026-08-24T04:25:42+02:00

clawbot commented

2026-08-24 04:25:42 +02:00

Raised by the review of #289.

The config-matrix audit that produced #283 covered all 13 ENVIRONMENT VARIABLES across absent / set-and-valid / set-but-invalid, and found two iron-rule violations, both now fixed. It did not cover configuration that arrives via the FILESYSTEM.

Unaudited paths, at least: the DATA_DIR lock file, the SQLite open paths across all three tiers, and the vendored-asset manifest. The question for each is the same one the env audit asked — when the input is present but unusable, does the process abort naming the path, or does it quietly proceed on a default?

.env was one instance of this class and it was silently discarded in full, so the class has already produced one real defect. That is the reason to look rather than assume.

Definition of done

Enumerate every path where configuration or required state is read from the filesystem rather than the environment. State the list up front so the scope is visible.
For each: what happens when the file is absent, present and valid, present and malformed, present but unreadable (permissions), present but a directory, and zero-length. Empty and zero-length are distinct from absent and are where this class hides — that is exactly how .env and the METRICS_* pair behaved differently.
Each path either aborts naming the path, or is DOCUMENTED as intentionally tolerant with the reason. Tolerance is a legitimate answer for genuinely optional inputs; being tolerant by accident is not.
Anything found that fails silently gets fixed under the same rule as #283.

Not milestoned. The env-variable half of this class is closed, and nothing here is known to be broken — this is looking where nobody has looked yet, in a class that has already yielded one defect.

Raised by the review of https://git.eeqj.de/sneak/webhooker/pulls/289. The config-matrix audit that produced https://git.eeqj.de/sneak/webhooker/issues/283 covered all 13 ENVIRONMENT VARIABLES across absent / set-and-valid / set-but-invalid, and found two iron-rule violations, both now fixed. It did not cover configuration that arrives via the FILESYSTEM. Unaudited paths, at least: the `DATA_DIR` lock file, the SQLite open paths across all three tiers, and the vendored-asset manifest. The question for each is the same one the env audit asked — when the input is present but unusable, does the process abort naming the path, or does it quietly proceed on a default? `.env` was one instance of this class and it was silently discarded in full, so the class has already produced one real defect. That is the reason to look rather than assume. ## Definition of done - Enumerate every path where configuration or required state is read from the filesystem rather than the environment. State the list up front so the scope is visible. - For each: what happens when the file is absent, present and valid, present and malformed, present but unreadable (permissions), present but a directory, and zero-length. Empty and zero-length are distinct from absent and are where this class hides — that is exactly how `.env` and the `METRICS_*` pair behaved differently. - Each path either aborts naming the path, or is DOCUMENTED as intentionally tolerant with the reason. Tolerance is a legitimate answer for genuinely optional inputs; being tolerant by accident is not. - Anything found that fails silently gets fixed under the same rule as https://git.eeqj.de/sneak/webhooker/issues/283. Not milestoned. The env-variable half of this class is closed, and nothing here is known to be broken — this is looking where nobody has looked yet, in a class that has already yielded one defect.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/webhooker#290