Skip to content

chore(security): drop the unused enforceSecrets() duplicate - #10775

Merged
diegosouzapw merged 1 commit into
diegosouzapw:release/v3.8.50from
maxmad64bis:fix/wire-enforce-secrets
Aug 20, 2026
Merged

diegosouzapw merged 1 commit into
diegosouzapw:release/v3.8.50from
maxmad64bis:fix/wire-enforce-secrets

Conversation

@maxmad64bis

@maxmad64bis maxmad64bis commented Aug 19, 2026 •

Copy link
Copy Markdown
Contributor

⚠️ base-red inherited: #9985

Summary

  • enforceSecrets() in src/shared/utils/secretsValidator.ts validates the secrets and exits on
    error, and its only caller is src/server-init.ts — a module nothing imports. It reads like a
    guard that never runs.
  • It is not one. enforceWebRuntimeEnv() (src/lib/env/runtimeEnv.ts) is called unconditionally
    from registerNodejs() and runs the same validateSecrets(); its errors are merged into the
    list that triggers process.exit(1). A missing or too-short API_KEY_SECRET already refuses to
    boot, and has since v3.6.6. enforceSecrets() is a strict subset of that check, so giving it a
    caller would refuse nothing the server does not already refuse.
  • The duplicate goes instead. validateSecrets() — the logic both went through — is untouched.

Related Issues

Validation

  • Change type: other (dead-code removal + regression test)
  • Focused tests and category gates from the golden path: tests/unit/secrets-boot-guard.test.ts
    (8/8) and the two integration files that asserted on the removed function (87 pass, 4 skipped)
  • npm run lint
  • Reconciled with the current active release base; focused checks rerun afterward
  • Production-code changes include a new or updated automated test in this PR
  • SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Tests Added Or Updated

  • tests/unit/secrets-boot-guard.test.ts (new, replaces tests/unit/enforce-secrets-boot-wiring.test.ts)
  • tests/integration/integration-wiring.test.ts
  • tests/integration/security-hardening.test.ts

The new file keeps the validateSecrets rule coverage and adds what nothing covered before: that
enforceWebRuntimeEnv() still runs after ensureSecrets() at boot, that secret errors stay in the
fatal list, and that no second enforce* entry point comes back.

Coverage Notes

  • src/shared/utils/secretsValidator.ts loses a function and its branches; the remaining
    validateSecrets() keeps its direct coverage. src/server-init.ts loses an import and a call.
    No production code is added.

Reviewer Notes

  • No behavior change: nothing that booted before is refused now, and nothing refused before boots.
  • src/server-init.ts is touched only to drop the import and the call. chore(startup): remove server-init.ts, a module nothing imports #10780 removes that module
    outright; whichever lands second needs a trivial rebase.
  • The branch name (fix/wire-enforce-secrets) predates the change of approach — this PR removes
    the function rather than wiring it.

@maxmad64bis
maxmad64bis marked this pull request as draft August 19, 2026 20:05
@maxmad64bis
maxmad64bis force-pushed the fix/wire-enforce-secrets branch from 549c950 to 22dbcf4 Compare August 19, 2026 21:40
@maxmad64bis maxmad64bis changed the title fix(security): run the API_KEY_SECRET strength check on real boot fix(security): drop the unused enforceSecrets() duplicate Aug 19, 2026
@maxmad64bis
maxmad64bis marked this pull request as ready for review August 19, 2026 21:57
secretsValidator.ts exported enforceSecrets(), which validates the secrets and
exits on error. Its only caller was src/server-init.ts, a module nothing imports.
It looks like a guard that never runs, but the same validateSecrets() call is
already fatal at boot through enforceWebRuntimeEnv() (src/lib/env/runtimeEnv.ts),
wired unconditionally in registerNodejs(): its errors are merged into the list
that triggers process.exit(1). enforceSecrets() is a strict subset of that, so
wiring it in would refuse nothing the server does not already refuse.

Remove it rather than give it a second caller, and pin the real guard: a
regression test asserts enforceWebRuntimeEnv() still runs after ensureSecrets()
at boot and that secret errors stay fatal, which nothing covered before.
@maxmad64bis
maxmad64bis force-pushed the fix/wire-enforce-secrets branch from 22dbcf4 to 87bbadc Compare August 19, 2026 22:00
@maxmad64bis maxmad64bis changed the title fix(security): drop the unused enforceSecrets() duplicate chore(security): drop the unused enforceSecrets() duplicate Aug 19, 2026
@diegosouzapw
diegosouzapw merged commit 66144d8 into diegosouzapw:release/v3.8.50 Aug 20, 2026
5 checks passed
@maxmad64bis
maxmad64bis deleted the fix/wire-enforce-secrets branch September 24, 2026 21:16
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
…zapw#10775)

Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants