Repository navigation
fix(docker): upgrade the trust store in its own layer and fail the build if the emSign root survives - #16452
Merged
devGregA merged 2 commits intoOct 21, 2026
Conversation
Release builds restore layers from the GitHub Actions cache, so the apt-get upgrade / apk upgrade layer can be reused from an older build and an OS trust-store fix never reaches the image. A separate upgrade step after those layers picks up the eMudhra fix (Debian 20250419+deb13u1, Alpine ca-certificates-bundle 20261020-r0). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…usted The trust-store refresh layer can itself come from the build cache on a later release. Add a CA_REFRESH build arg that the layer echoes, so bumping it forces a rebuild, and a check after the pip install that fails the build if emSign ECC Root CA - G3 is in the system bundle or certifi. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
Full |
blakeaowens
approved these changes
Oct 21, 2026
Maffooch
approved these changes
Oct 21, 2026
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
3 participants
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.
What
Follow-up to #16449, whose squash merge only picked up the certifi pin. These two commits were pushed after the PR entered the merge queue.
Dockerfile.django-debianandDockerfile.django-alpineget a separateca-certificatesupgrade layer after the existing package layers, keyed onARG CA_REFRESH=2026-10-20./etc/ssl/certs/ca-certificates.crtor in certifi's bundle.Why
Eight eMudhra intermediate CAs had recoverable private keys (Mozilla bug 2083449).
The release workflow builds with
cache-from: type=gha. The existingapt-get upgrade/apk upgradelayers have the same text and the same digest-pinned base as the last release, so buildx can reuse them and the fixedca-certificatesnever installs. With only #16449 ondev, a rebuild fixesrequests(certifi), but Python's defaultsslcontext,requestspointed at the system bundle, and curl all still trust the test host.CA_REFRESHmakes the next forced refresh a one-line change.Checked
defectdojo/defectdojo-django:latest, flagging both stores, and 0 after upgrading certifi to 2026.10.19 andca-certificatesto 20250419+deb13u1.python:3.14.8-alpine3.23, the guard exits 1 before and 0 afterapk upgrade ca-certificates-bundle ca-certificates(20260909-r0 to 20261020-r0).docker build --target release -f Dockerfile.django-debian: see the comment below once it finishes.🤖 Generated with Claude Code