Skip to content

security(config): hardcoded private-range address literals in 50 tracked files, 17 of them in executable non-test code #15516

Open

Description

@mrveiss

Problem

CLAUDE.md states the rule plainly — "Never hardcode. Config via SSOT, TTLs via env-var-backed module constants, no IPs or ports in code" — and nothing enforces it for private-range address literals.

Measured on Dev_new_gui: 50 tracked .py/.sh files contain a hardcoded RFC1918 URL literal. 17 of those are outside docs/ and tests, i.e. in executable non-test code.

Found while retargeting stale path references in #15193: the repo-root main.py prints an orchestration URL containing a hardcoded node address. That file is a deprecated redirect shim, so the address is user-facing output pointing at a specific host.

Why it matters beyond tidiness

  1. These leak into outward artifacts. The rule against internal addresses in issues, PRs and logs is undermined when the address is printed to stdout by the program itself. Anyone pasting a terminal transcript into an issue republishes it without noticing.
  2. They are wrong on any other deployment. A literal node address is correct on exactly one network. Every other checkout — a contributor's laptop, a fresh environment — gets output pointing somewhere that does not exist, with no error to say so.
  3. There is an SSOT for this. Service URLs resolve through the config layer; these literals bypass it, so changing a node means finding 50 files rather than one value.

Scope note — this needs splitting, not a flag day

The 33 under docs/ and tests are a different problem from the 17 in executable code, and probably a different decision:

  • executable code (17) — should resolve through SSOT; a literal is a defect
  • docs (many) — an example address may be legitimate, but should be a documentation-reserved range rather than a real internal node
  • tests — a literal is often correct and deliberate (a fixture asserting on a fixed value), so a blanket ban would be wrong

Acceptance criteria

  • Establish the exact population per bucket, with the classification rule stated. Report measured counts, not the 50/17 above — those come from one regex over .py and .sh only and do not cover .yml, .ts, .vue or .md.
  • For the executable-code bucket, route each literal through the existing config/SSOT path, or record per site why it cannot be.
  • Decide the docs policy explicitly: real internal addresses replaced with a documentation-reserved range, or an exemption recorded with its reason.
  • A guard fails on a new hardcoded private-range literal in executable non-test code, with a down-only ratchet over the existing population so it can shrink and never silently grow.
  • Verified by MUTATION: add a literal to an executable file, confirm the guard names the file and line; then add one to a test fixture and confirm it does not fire. A guard that flags both is wrong and must not ship.
  • The guard carries a population floor evaluated before its substantive assertion, so a collapsed sweep fails by name rather than reading as a clean tree.

Notes

No addresses are quoted here deliberately — the same rule that motivates the issue applies to the issue. Sites are identifiable by the regex above.

Related: #15044 (inert config), #13842 (a value declared in many places with no source of truth) — same family, different value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions