Security: remove hardcoded Django SECRET_KEY from settings.py (projects-hub#56) - #2
Conversation
project/settings.py previously assigned SECRET_KEY a plaintext literal
value committed to source control. This replaces it with an
os.environ.get('DJANGO_SECRET_KEY', '') lookup, so no key value lives
in source control going forward.
Also adds a CI guard (scripts/check-no-plaintext-secret-key.sh, with a
fixture-based test in scripts/test-no-plaintext-secret-key.sh) that
scans project/settings.py for a hardcoded SECRET_KEY literal and fails
the check if one is reintroduced, wired into the existing
scripts/validate.sh / .github/workflows/ci.yml pipeline.
Rotation of the actual leaked key value, confirming whether any
deployed instance ever relied on it, and any other runtime/deployment
action are out of scope here and reserved for the security owner --
see Polyhydra-Games/projects-hub#56.
Co-Authored-By: Polyhydra Games <noreply@polyhydragames.com>
Claude-Session: https://claude.ai/code/session_01MMdUadpjqj5MfSNgvqS1eM
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4b6cf0f34e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| set -euo pipefail | ||
|
|
||
| ./scripts/test-no-plaintext-secret-key.sh | ||
| ./scripts/check-no-plaintext-secret-key.sh project/settings.py |
There was a problem hiding this comment.
At this commit, a repository-wide search still finds the same non-placeholder key literal in tracked project/settings.py.old, and tracked project/settings.pyc also embeds it, but this validation invokes the scanner only on project/settings.py. CI therefore passes while checkouts and source archives continue distributing the credential; remove the backup/compiled artifacts and make the check cover all tracked candidate files.
AGENTS.md reference: AGENTS.md:L37-L37
Useful? React with 👍 / 👎.
| # The key must be provided via the DJANGO_SECRET_KEY environment variable at | ||
| # runtime. No literal key value lives in source control -- see | ||
| # Polyhydra-Games/projects-hub#56 for the tracking issue and rotation status. | ||
| SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', '') |
There was a problem hiding this comment.
When DJANGO_SECRET_KEY is absent—as it is for a fresh clone following the README, make install, or rpmanager.sh, none of which provisions or documents this variable—the expression resolves to an empty string. Django 1.8 rejects an empty SECRET_KEY while initializing settings, so both the installation migration and documented launcher fail before the application can start; add a secure provisioning path before requiring the variable.
Useful? React with 👍 / 👎.
1 participant
Summary
project/settings.pyhad a hardcoded DjangoSECRET_KEYliteral committedto source control, tracked at
Polyhydra-Games/projects-hub#56.
This PR is the safe, decision-free slice of that issue, following the same
pattern used for
lancer1977/TwitchySharp#2(plaintext Discord webhook,merged as PR RetroPie#3):
SECRET_KEY = '...'value withSECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', ''), so no key valuelives in source control going forward. No fallback equal to the old
leaked value was added anywhere.
scripts/check-no-plaintext-secret-key.sh, a scanner that fails ifproject/settings.pyever again assignsSECRET_KEYa literalquoted value instead of an
os.environ/os.getenvlookup, plus afixture-based test (
scripts/test-no-plaintext-secret-key.sh) provingthe scanner catches a value-shaped literal and passes an
environment-variable reference -- without ever printing a real secret
value.
scripts/validate.sh(already run by.github/workflows/ci.ymlon push/PR), rather than adding a secondworkflow, since this repo already has that lightweight validation
pipeline (
ci: tier RetroPie validation).Note: this branch targets
retropie, which is this repo's actual currentdefault branch (confirmed via
gh repo view) and whose HEAD is the committhe tracking issue cites (
4e600f1da...) -- notmaster, which is a stale2016-era branch that predates this repo's CI setup.
Out of scope (reserved for the security owner)
Per projects-hub#56's own stated scope boundary, this PR does not:
SECRET_KEYvalue.instance relying on it is "safe" or "already rotated" -- there is no way
to know that from this repo alone.
This repo appears to be a mostly-dormant scaffold ("not maintained
anymore" per its README); whether it currently has runtime traffic
depending on this key is unconfirmed either way and is left to the
security owner to determine.
Test plan
bash scripts/validate.shrun locally on this branch -- all checkspass, including the new scanner confirming no hardcoded
SECRET_KEYliteral remains inproject/settings.py.ciworkflow) passes on this PR.🐉 Polyhydra Games
https://claude.ai/code/session_01MMdUadpjqj5MfSNgvqS1eM