Repository navigation
fix(ci): add .dockerignore to keep the build context limited to tracked files - #508
Merged
Jan-Kazlouski-elastic merged 3 commits intoOct 5, 2026
Merged
Conversation
…ation No new code change required beyond what's already on main. The vulnerable Bouncy Castle versions (1.78/1.79, flagged across multiple CVEs including CVE-2026-8763, CVSS 9.3 critical) found in published docker.elastic.co/integrations/crawler images come from: - JRuby 9.4.12.0's own stdlib-bundled jruby-openssl 0.15.3 (BC 1.79) at /opt/jruby/lib/ruby/stdlib/org/bouncycastle/... - An older jruby-openssl pin (BC 1.78/1.84 depending on vintage) This was already fixed on main via commit a19c933 ("fix(deps): bump jruby-openssl to 0.16.2 for BC 1.85 CVE cluster", 2026-08-27): - Dockerfile / Dockerfile.wolfi now strip the stdlib-bundled BC jars after JRuby install. - Gemfile/Gemfile.lock pin jruby-openssl to 0.16.2 (bundles BC 1.85). - Jarfile/Jars.lock pin org.bouncycastle:* directly to 1.85. However, the last published release tag (v0.1.0) predates this fix (`git merge-base --is-ancestor a19c933 v0.1.0` confirms it is NOT an ancestor). The published docker.elastic.co/integrations/crawler image Snyk is scanning is therefore stale relative to main. Action needed: cut a new crawler release/tag from current main (or later) and republish the Docker image so Snyk rescans reflect the fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dockerfile and Dockerfile.wolfi both do `COPY . /home/app`. Gems and jars install fresh inside the build (script/bundle -> /usr/local/bundle, script/vendor_jars -> vendor/jars), so nothing under vendor/bundle, vendor/ruby, vendor/jruby, etc. is actually needed from the build context or loaded at runtime. Without a .dockerignore, a developer's local, gitignored build state (e.g. a vendor/bundle left over from before a jruby-openssl version bump) would get copied verbatim into the image. It wouldn't affect runtime behavior, but it could still ship stale/vulnerable jars that a filesystem-based scanner like Snyk flags, matching some of the /home/app/vendor paths seen in the Snyk findings for this BC CVE cluster. Verified: `docker build` still succeeds and produces a clean image with only the pinned bcprov-jdk18on 1.85 (vendor/jars) and jruby-openssl 0.16.2 (/usr/local/bundle) present - no stray or duplicate Bouncy Castle versions. Mirrors the ent-search fix in elastic/ent-search#8755 (bundle clean --force before Warbler packages the WAR) - same class of risk, different packaging mechanism. Related: elastic/search-team#15610, #15613-#15625 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rfojta-elastic
changed the title
Jan-Kazlouski-elastic
self-requested a review
October 2, 2026 16:10
Jan-Kazlouski-elastic
approved these changes
Oct 5, 2026
Jan-Kazlouski-elastic
left a comment
Jan-Kazlouski-elastic
left a comment
Contributor
There was a problem hiding this comment.
Two notes on the description before merge:
- The last published release is
v1.0.0(11 May 2026), notv0.1.0. - The "action needed — cut a new release and republish" is already done:
1.1.0
was published on 22 Sep frommain, which contains a19c933.
Jan-Kazlouski-elastic
enabled auto-merge (squash)
October 5, 2026 18:42
Jan-Kazlouski-elastic
changed the title
Jan-Kazlouski-elastic
deleted the
rfojta/fix-org-bouncycastle-bcprov-jdk18on
branch
October 5, 2026 18:52
Jan-Kazlouski-elastic
added a commit
that referenced
this pull request
Oct 5, 2026
… tracked files (#508) (#516) Backports the following commits to 1.0: - fix(ci): add .dockerignore to prevent stale local build state; verify BC CVE cluster status (#508) Co-authored-by: Richard Fojta <richard.fojta@elastic.co> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Jan-Kazlouski-elastic <jan.kazlouski@elastic.co>
Jan-Kazlouski-elastic
added a commit
that referenced
this pull request
Oct 5, 2026
… tracked files (#508) (#517) Backports the following commits to 1.1: - fix(ci): add .dockerignore to prevent stale local build state; verify BC CVE cluster status (#508) Co-authored-by: Richard Fojta <richard.fojta@elastic.co> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Jan-Kazlouski-elastic <jan.kazlouski@elastic.co>
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
2 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.
Adds a
.dockerignore, which the repo did not have.DockerfileandDockerfile.wolfiboth doCOPY . /home/app. Gems and jars installfresh inside the build (
script/bundle→/usr/local/bundle,script/vendor_jars→vendor/jars), so nothing under the gitignoredvendor/bundle,vendor/ruby,vendor/jrubyetc. is needed from the build context. Without a.dockerignore, adeveloper's stale local build state in one of those directories would be copied
verbatim into a locally built image — harmless at runtime, but still visible to
filesystem-based scanners.
The list mirrors the corresponding sections of
.gitignore.Scope
This is build-context hygiene for local builds. It does not change the published
images: CI builds from a fresh Buildkite checkout, so there is no local state to leak
there.
It also does not address the Bouncy Castle findings tracked in elastic/search-team#15610
and elastic/search-team#15613 … #15625. Those come from two places that
.dockerignorecannot influence:
/opt/jruby/lib/ruby/stdlib/org/bouncycastle/...— JRuby's own stdlib inside thebase image, which
COPY .never writes. Already removed explicitly in bothDockerfiles.
/app/..., frombefore
WORKDIRmoved to/home/app, referencing BC 1.69 / 1.76 / 1.78 / 1.79).Those need Snyk project hygiene, not a code change. The dependency fix itself landed in
a19c933 (jruby-openssl 0.16.2 → BC 1.85) and ships in the published
1.1.0image.Verification
docker buildsucceeds and the resulting image contains only the pinnedbcprov-jdk18on1.85 andjruby-openssl0.16.2 — no stray Bouncy Castle versions.