Guard ALLOW_PLAINTEXT_SECRETS against non-local boot - #265
Merged
Conversation
Assert the hub refuses to boot with ALLOW_PLAINTEXT_SECRETS set unless BASE_URL is a loopback address, and still boots fine locally or with a real CREDENTIAL_ENCRYPTION_KEY.
A real deployment that inherits .env.example's dev-friendly ALLOW_PLAINTEXT_SECRETS=1 would silently store secrets (including real provider keys) unencrypted at rest. Rather than trust an operator to have overridden the file, the hub now refuses to boot when the flag is set and BASE_URL isn't localhost/127.0.0.1/::1 — so the flag can only ever take effect against a developer's own machine.
Note that the shipped ALLOW_PLAINTEXT_SECRETS=1 is now safe to copy verbatim into any deployment's .env: it can only take effect when BASE_URL is a loopback address.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Investigated dropping demo-specific scaffolding (CL-6536) so there is one setup path for everyone. A full search of apps/, packages/, workflows/, and scripts/ found no genuine demo-only scaffolding to remove — the setup path is already singular (
bun run dev,workbench setup, andworkbench seedall resolve to the same default identity and workflow set a real signup gets). Things that merely look demo-ish by name (catalog "demo-card" fields,packages/longevity-sim's load-test personas) are real product surface or legitimate engineering tooling and were left untouched.packages/folded-runswas excluded per an existing pending decision.The one concrete, already-identified risk item:
.env.exampleshipsALLOW_PLAINTEXT_SECRETS=1uncommented for local-dev friction. A security review flagged that a real deployment inheriting this unmodified could store secrets — including real provider keys — unencrypted at rest.ALLOW_PLAINTEXT_SECRETSis set andBASE_URLis not a loopback address (localhost/127.0.0.1/::1), so the flag can only ever take effect on a developer's own machine — safe by construction rather than trusting an operator to have stripped it.bun run devis unaffected (BASE_URLdefaults tohttp://localhost).ALLOW_UNVERIFIED_EMAILSis deliberately left as-is: no mailer is wired up anywhere in the stack yet, so it's currently the only way self-serve signup can complete in any deployment, not just a demo — gating it the same way would break real deployments' signup, a separate larger gap tracked in CL-6536.Test plan
bun testinapps/hub— 160 pass, 26 skip (DB-gated, no local Postgres), 0 failBASE_URL, and that it still boots againstlocalhost/127.0.0.1or with a realCREDENTIAL_ENCRYPTION_KEYbun run check:structuralpassestsc --noEmitinapps/hubpassesCL-6536