Dead fs_permissions grant: foundry.toml grants read on foundry.toml and nothing reads it

[thedavidmeister]

Audit scope: whole-repo, commit 7aa85a4

Dimension 4 (code quality) · severity low

Where

• foundry.toml:30-34, specifically line 31:

fs_permissions = [
  { access = "read", path = "foundry.toml" },
  { access = "read-write", path = "src/generated" },
  { access = "read-write", path = "meta" },
]

Problem

The repo grants read access to foundry.toml and nothing reads it. Nothing
under test/, src/ or script/ calls vm.readFile("foundry.toml"), so the
grant is dead configuration — a standing permission with no consumer, which
reads as if some test depends on it when none does.

Evidence measured

• foundry.toml:31 grants { access = "read", path = "foundry.toml" }.
• Zero readers of that path anywhere in the tree.

Proposed fix

Either remove the grant, or use it. Two other findings in this same audit —
#77 (GENERATED_DIR vs
the fs_permissions grant) and
#79 (MAX_LINE_LENGTH
vs a pinned [fmt]) — both propose tests that read foundry.toml through
exactly this grant, which is the better resolution: the grant stops being dead
because it becomes the mechanism that makes two restated facts assertable.

Resolve this one with those two rather than before them; deleting the grant
first would have to be reverted to land either test.

[thedavidmeister]

Checked live at 2026-08-16T18:33Z against main @ 935c725.

Measured state

• grep -rn 'foundry.toml' --include='*.sol' over main returns exactly one
  hit — a NatSpec mention at src/lib/LibCodeGen.sol:237. No
  vm.readFile("foundry.toml") anywhere in src/, test/ or script/. The
  grant at foundry.toml:31 is still unconsumed.
• All 18 open PRs (Move every .t.sol into the test/src/lib mirror tree #56, Correct LibHexString's library notice to match its Vm parameter #96–Cover the generated directory being created, by making the directory injectable #112) diffed: zero occurrences of
  readFile("foundry.toml") in any of them.
• src/generated is a bare string literal replicated across two repos' code, config and CI #77 and The wrap arithmetic encodes forge fmt's defaults, nothing pins them, and CI absorbs the mismatch #79 are both still OPEN with no branch and no PR.
  git ls-remote --heads carries 2026-08-16-issue-57 … -issue-74; there is
  nothing for 77 or 79.

Ruling: keep the grant

Neither route this issue offers is takeable on its own right now.

• Deleting it is wrong. src/generated is a bare string literal replicated across two repos' code, config and CI #77's fix (testGeneratedDirIsGranted) and The wrap arithmetic encodes forge fmt's defaults, nothing pins them, and CI absorbs the mismatch #79's
  fix (testMaxLineLengthMatchesFormatterConfig) each read foundry.toml
  through this exact grant. Deleting it saves one line and costs a revert in
  two separate open findings — which is what this issue's own body already
  says.
• Using it belongs to src/generated is a bare string literal replicated across two repos' code, config and CI #77 and The wrap arithmetic encodes forge fmt's defaults, nothing pins them, and CI absorbs the mismatch #79. A third foundry.toml-reading test
  added here would be superseded by both of them the moment either lands, and
  a redundant assertion is itself a finding in this audit (testFilePrefixNamesNoScript and testBytesToHexHasNoPrefix assert only what a sibling in the same file already implies #72).

So foundry.toml:31 stays exactly as it is. This issue carries no independent
code change. It is blocked by
#77 and
#79, and resolves as
dead-no-longer once either lands.

Anyone picking this issue up later: do not delete the grant to close it.

[thedavidmeister]

Closing: the premise is dead. The grant is consumed now, and the proposed fix
would be a three-test regression.

The ruling on this issue (2026-08-16T18:34Z) called it: keep the grant, it
resolves as dead-no-longer once either #77 or #79 lands, and do not delete it to
close the issue. Both landed eight minutes later — #79 as PR #115 (3d87b4c,
18:41:02Z) and #77 as PR #116 (e9aed38, 18:43:38Z), both ancestors of main.

Measured on live main (390f781)

Three tests read foundry.toml through this grant:

• test/src/lib/LibCodeGen.maxLineLength.t.sol:23 —
  testMaxLineLengthMatchesFormatterConfig, asserting MAX_LINE_LENGTH against
  [fmt] line_length
• test/src/lib/LibCodeGen.maxLineLength.t.sol:32 —
  testNewlineDueToMaxLengthMatchesFormatterConfig, against [fmt] tab_width
• test/src/lib/LibFs.t.sol:193 — testGeneratedDirIsTheGrantedPath, asserting
  GENERATED_DIR matches an fs_permissions path

Shown by inversion rather than by grep. Applying this issue's own proposed fix —
deleting the grant line — takes those three from passing to failing:

[FAIL: vm.readFile: the path foundry.toml is not allowed to be accessed for read operations] testGeneratedDirIsTheGrantedPath()
[FAIL: vm.readFile: the path foundry.toml is not allowed to be accessed for read operations] testMaxLineLengthMatchesFormatterConfig()
[FAIL: vm.readFile: the path foundry.toml is not allowed to be accessed for read operations] testNewlineDueToMaxLengthMatchesFormatterConfig()

The grant is also doubly self-referential now: testGeneratedDirIsTheGrantedPath
parses .profile.default.fs_permissions, so the line is both the mechanism that
permits the read and part of the array being asserted. Removing it would break
the test that asserts it exists.

No code changed and no PR was opened, because there is nothing here to land.