fix: secure Django secret generation - #4706
Conversation
Prevent the signing key from inheriting permissive umasks or being replaced by competing replicas. Let the migration owner create and repair it while dependent services wait.
![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: 7d6d7c6d27
ℹ️ 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".
| fi | ||
|
|
||
| # Repair secrets created by older container versions or copied into the volume. | ||
| chmod 600 "$secret_file" |
There was a problem hiding this comment.
When an existing nonempty secret is readable but owned by root or by a previous arbitrary runtime UID, the data directory can still be writable while this chmod is forbidden. Under set -e, upgrading the container then aborts startup even though the previous entrypoint could use the secret; this also contradicts the stated goal of repairing secrets copied into the volume. Preserve the value by rewriting it through an owned temporary file and atomic rename rather than requiring ownership of the existing inode.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
It should be owned by correct user, there is runtime check for that in Weblate AFAIK.
1 participant
Prevent the signing key from inheriting permissive umasks or being replaced by competing replicas. Let the migration owner create and repair it while dependent services wait.