Audit scope: whole-repo, commit 7aa85a4 (of rainlanguage/rain.sol.codegen) — this is the shared-CI half of that audit finding.
Counterpart issue: rainlanguage/rain.sol.codegen#77
Dimension 6 (hazard surface) · severity medium
Where
rainix-copy-artifacts.yaml — the [ -d src/generated ] guard
rainix-sol-static.yaml — the frozen-snapshots-append-only action
rainix-autopublish.yaml — the soldeer content gate that excludes src/generated/ when hashing normalized package content
Problem
One concept — where generated code lives — is spelled out independently in
seven-plus places across rain.sol.codegen and rainix, and changing the
canonical one disables checks silently rather than loudly.
GENERATED_DIR in rain.sol.codegen (src/lib/LibFs.sol:11) is the constant.
Three separate rainix mechanisms restate the same path by hand:
rainix-copy-artifacts.yaml's [ -d src/generated ] guard,
rainix-sol-static.yaml's frozen-snapshots-append-only action, and
rainix-autopublish.yaml's soldeer content gate. None derives the path from the
constant, and nothing asserts they agree.
Scenario: GENERATED_DIR is changed (to src/gen, or to include a
subdirectory). The consumer's fs_permissions grant no longer matches, so the
write is refused — loud, and the change gets "fixed" by editing foundry.toml.
Three consequences then land silently, all in rainix:
rainix-copy-artifacts's [ -d src/generated ] guard is now false, so a repo
committing generated sources without script/Build.sol is no longer
hard-failed.
frozen-snapshots-append-only stops policing the frozen deploy-pin snapshots.
- The autopublish content gate stops excluding generated files, so every
regeneration counts as a content change and the package republishes on runs
that changed nothing.
Proposed fix
The three workflow-side literals should read one value — a repo-level input, or a
single RAINIX_GENERATED_DIR env in the reusables — rather than each hardcoding
src/generated.
The consumer-side half (a rain.sol.codegen test tying GENERATED_DIR to the
fs_permissions grant that makes the write work) is tracked at
rainlanguage/rain.sol.codegen#77
Audit scope: whole-repo, commit 7aa85a4 (of
rainlanguage/rain.sol.codegen) — this is the shared-CI half of that audit finding.Counterpart issue: rainlanguage/rain.sol.codegen#77
Dimension 6 (hazard surface) · severity medium
Where
rainix-copy-artifacts.yaml— the[ -d src/generated ]guardrainix-sol-static.yaml— thefrozen-snapshots-append-onlyactionrainix-autopublish.yaml— the soldeer content gate that excludessrc/generated/when hashing normalized package contentProblem
One concept — where generated code lives — is spelled out independently in
seven-plus places across
rain.sol.codegenandrainix, and changing thecanonical one disables checks silently rather than loudly.
GENERATED_DIRinrain.sol.codegen(src/lib/LibFs.sol:11) is the constant.Three separate rainix mechanisms restate the same path by hand:
rainix-copy-artifacts.yaml's[ -d src/generated ]guard,rainix-sol-static.yaml'sfrozen-snapshots-append-onlyaction, andrainix-autopublish.yaml's soldeer content gate. None derives the path from theconstant, and nothing asserts they agree.
Scenario:
GENERATED_DIRis changed (tosrc/gen, or to include asubdirectory). The consumer's
fs_permissionsgrant no longer matches, so thewrite is refused — loud, and the change gets "fixed" by editing
foundry.toml.Three consequences then land silently, all in rainix:
rainix-copy-artifacts's[ -d src/generated ]guard is now false, so a repocommitting generated sources without
script/Build.solis no longerhard-failed.
frozen-snapshots-append-onlystops policing the frozen deploy-pin snapshots.regeneration counts as a content change and the package republishes on runs
that changed nothing.
Proposed fix
The three workflow-side literals should read one value — a repo-level input, or a
single
RAINIX_GENERATED_DIRenv in the reusables — rather than each hardcodingsrc/generated.The consumer-side half (a
rain.sol.codegentest tyingGENERATED_DIRto thefs_permissionsgrant that makes the write work) is tracked atrainlanguage/rain.sol.codegen#77