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

Closed
opened 2026-08-24 04:25:42 +02:00 by clawbot · 2 comments
Collaborator

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.
Author
Collaborator

Plan. First list, in the PR, every path where the service reads configuration or required state from the filesystem rather than the environment, checked against next (at least: the DATA_DIR lock file, the main, event and archive SQLite databases, the .env file, the embedded static assets). For each, check what happens when the file is absent, valid, malformed, unreadable, a directory, and zero-length, and record it in the PR as a short table. Each case either stops the process with a message naming the path, or is documented (in the README, next to that path's existing text) as tolerated on purpose, with the reason. A case that carries on silently on a default is fixed and gets a test. Pre-1.0: nothing is added for databases from older builds.

Model: opus-5-5

Plan. First list, in the PR, every path where the service reads configuration or required state from the filesystem rather than the environment, checked against `next` (at least: the `DATA_DIR` lock file, the main, event and archive SQLite databases, the `.env` file, the embedded static assets). For each, check what happens when the file is absent, valid, malformed, unreadable, a directory, and zero-length, and record it in the PR as a short table. Each case either stops the process with a message naming the path, or is documented (in the README, next to that path's existing text) as tolerated on purpose, with the reason. A case that carries on silently on a default is fixed and gets a test. Pre-1.0: nothing is added for databases from older builds. Model: opus-5-5
Author
Collaborator

#460 checks every file webhooker reads configuration or required state from; the table is in its body. Three cases carried on silently and now log the existing created a new, empty database warning with the file's path: a zero-length webhooker.db, and a missing or zero-length per-webhook database, which was quietly replaced by an empty one. The README now says, beside .env and the main, per-webhook and archive databases, how an empty file is treated. The main database's open errors stop the process without naming the file; that is #459.

  • Judgement call: a lost per-webhook database is still replaced, now with a warning, rather than refused, so one missing file never stops a webhook receiving.
  • "Unreadable" was tried as a directory in the file's place, not by permissions.

Model: opus-5-5

https://git.eeqj.de/sneak/webhooker/pulls/460 checks every file webhooker reads configuration or required state from; the table is in its body. Three cases carried on silently and now log the existing `created a new, empty database` warning with the file's path: a zero-length `webhooker.db`, and a missing or zero-length per-webhook database, which was quietly replaced by an empty one. The README now says, beside `.env` and the main, per-webhook and archive databases, how an empty file is treated. The main database's open errors stop the process without naming the file; that is https://git.eeqj.de/sneak/webhooker/issues/459. - Judgement call: a lost per-webhook database is still replaced, now with a warning, rather than refused, so one missing file never stops a webhook receiving. - "Unreadable" was tried as a directory in the file's place, not by permissions. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/webhooker#290