Repository navigation
feat: support custom CA certificates from the data volume - #4841
Conversation
|
@codex review |
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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e705938d89
ℹ️ 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".
Any *.crt files placed in /app/data/ssl/ca-certificates are combined with the system CA bundle into a runtime-writable bundle at container start, and Python (requests), OpenSSL, libcurl and git are pointed at it via REQUESTS_CA_BUNDLE, SSL_CERT_FILE, CURL_CA_BUNDLE and GIT_SSL_CAINFO. Generating a fresh bundle (instead of installing into the system trust store) works with the image's unprivileged runtime user, where /usr/local/share/ca-certificates and /etc/ssl/certs are not writable, and it is rebuilt from scratch on every start so removed certificates never linger. No-op when the directory is absent or empty. Fixes WeblateOrg#1525
e705938 to
365062f
Compare
|
Thanks for the review. Reworked in 365062f:
Also reworded the comment that tripped the pre-commit spell check. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 365062f925
ℹ️ 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".
cat-ing the system bundle and user .crt files together glued PEM blocks whenever an input lacked a trailing newline (END CERTIFICATE---BEGIN CERTIFICATE---), producing a bundle that OpenSSL/Python reject. Write each input followed by an explicit newline instead. Extend the test with a no-trailing-newline case and verify the old and new behavior against openssl with real self-signed certificates (old: "error reading the file"; new: bundle parses).
for more information, see https://pre-commit.ci
|
Fixed in 3f00080. Good catch — I reproduced it with real self-signed certificates before changing anything: a The bundle is now built with an explicit newline after each input (system bundle and every |
|
I think this looks good to merge now, but let's do one more AI review round. Can you please create a documentation PR against https://github.com/WeblateOrg/weblate/? @codex review |
|
Documentation PR is up: WeblateOrg/weblate#22322. It adds a "Trusting custom CA certificates" section to the Docker install docs (placed right after "Using own SSL certificates"), covering the |
|
@codex review |
|
Codex Review: Something went wrong. Try again later by commenting “@codex review”. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a0e038a3f2
ℹ️ 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".
| export REQUESTS_CA_BUNDLE="$CUSTOM_CA_BUNDLE" | ||
| export SSL_CERT_FILE="$CUSTOM_CA_BUNDLE" | ||
| export CURL_CA_BUNDLE="$CUSTOM_CA_BUNDLE" | ||
| export GIT_SSL_CAINFO="$CUSTOM_CA_BUNDLE" |
There was a problem hiding this comment.
Export the bundle through PGSSLROOTCERT
When POSTGRES_SSL_MODE is verify-ca or verify-full, the database-version check is enabled, and PostgreSQL is signed only by a CA mounted here, this export list does not configure libpq. The libpq environment-variable documentation states that PGSSLROOTCERT behaves like the sslrootcert parameter, whose documented default is ~/.postgresql/root.crt; SSL_CERT_FILE is not its CA setting. The psql invocation in check_postgres_version therefore rejects the server before startup despite the mounted CA, so export this bundle as PGSSLROOTCERT as well.
Useful? React with 👍 / 👎.
libpq does not honor SSL_CERT_FILE; psql looks up the CA through sslrootcert (default ~/.postgresql/root.crt). With POSTGRES_SSL_MODE set to verify-ca or verify-full and PostgreSQL signed only by a mounted custom CA, check_postgres_version would reject the server before startup. Point PGSSLROOTCERT at the combined bundle too.
79cb8a4 to
10518dc
Compare
|
Fixed in 10518dc: |
|
Scheduled for merge, thanks for your contribution! |
…#22322) get_clean_env() scrubs the environment for repository operations, which dropped the custom CA configuration before it could reach Git. Pass the standard CA certificate variables through so that HTTPS Git remotes secured by a private CA work out of the box, and simplify the Docker custom CA documentation accordingly. Documents the container start script support for combining user-provided CA certificates in ssl/ca-certificates/ with the system CA bundle (WeblateOrg/docker#4841). Co-authored-by: Michal Čihař <michal@weblate.org>
What
Adds support for custom CA certificates without rebuilding the image: any
*.crtfiles placed in/app/data/ssl/ca-certificatesare combined with the system CA bundle at container start, and the runtime is pointed at the combined bundle.Fixes #1525
Design
/app/data/ssl, the same data-volume area already used for SAML certificates (saml.crt/saml.key). A dedicatedca-certificatessubdirectory keeps the SAML files from being swept into the bundle.USER 1000), so the system trust store is not writable at runtime. Instead of installing into it, the start script generates a fresh combined bundle (system + custom CAs) at/tmp/custom-ca-certificates.crton every start and exportsREQUESTS_CA_BUNDLE,SSL_CERT_FILE,CURL_CA_BUNDLEandGIT_SSL_CAINFOpointing at it, so Python (requests), OpenSSL, libcurl and git all honor the custom certificates.Testing
tests/test-custom-ca-certificates(wired intotests/run) extracts the function verbatim fromstartand covers: missing directory (no-op), two certificates (combined bundle content, exports, file mode) and empty directory (no-op). 7/7 passing locally; shellcheck and shfmt clean.Notes
docs/admin/install/docker.rst); happy to follow up with a docs PR there if this lands.