From 3a3901cd4659019de8b307c5570da24daebc70ff Mon Sep 17 00:00:00 2001 From: Richard Fojta Date: Mon, 5 Oct 2026 20:52:54 +0200 Subject: [PATCH] fix(ci): add .dockerignore to prevent stale local build state; verify BC CVE cluster status (#508) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary **Verification:** the fix for this Bouncy Castle CVE cluster is already on `main` (commit a19c933, "fix(deps): bump jruby-openssl to 0.16.2 for BC 1.85 CVE cluster", 2026-08-27): - `Dockerfile`/`Dockerfile.wolfi` strip the JRuby-stdlib-bundled BC jars (1.79, from jruby-openssl 0.15.3 shipped inside JRuby 9.4.12.0 itself) after 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`. **The gap:** the last published release tag `v0.1.0` predates this fix (`git merge-base --is-ancestor a19c933 v0.1.0` → not an ancestor). The published `docker.elastic.co/integrations/crawler` image Snyk has been scanning was built before the fix landed — cutting a new release/tag from current `main` and republishing is still needed (not something this PR does). **Real fix included:** added a `.dockerignore` (none existed before). `Dockerfile`/`Dockerfile.wolfi` both do `COPY . /home/app`. Gems/jars install fresh inside the build (`script/bundle` -> `/usr/local/bundle`, `script/vendor_jars` -> `vendor/jars`), so nothing under the gitignored `vendor/bundle`, `vendor/ruby`, `vendor/jruby`, etc. is actually needed from the build context. Without a `.dockerignore`, a developer's stale local build state sitting in one of those gitignored directories would get copied verbatim into the image by `COPY . /home/app` — harmless at runtime, but still flaggable by filesystem-based scanners like Snyk (matching some of the `/home/app/vendor/...` paths in the original findings). Verified the Docker build still succeeds and produces a clean image with only the pinned `bcprov-jdk18on` 1.85 and `jruby-openssl` 0.16.2 present, no stray BC versions. Mirrors the `ent-search` fix in elastic/ent-search#8755 — same class of risk (stale local build state leaking into a shipped artifact), different packaging mechanism. ## related issues elastic/search-team#15610 elastic/search-team#15613 elastic/search-team#15614 elastic/search-team#15615 elastic/search-team#15616 elastic/search-team#15617 elastic/search-team#15618 elastic/search-team#15619 elastic/search-team#15620 elastic/search-team#15621 elastic/search-team#15622 elastic/search-team#15623 elastic/search-team#15624 elastic/search-team#15625 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5 Co-authored-by: Jan-Kazlouski-elastic --- .dockerignore | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 .dockerignore diff --git a/.dockerignore b/.dockerignore new file mode 100644 index 00000000..9cf3e6c4 --- /dev/null +++ b/.dockerignore @@ -0,0 +1,32 @@ +# Keep the Docker build context limited to what's actually tracked in git. +# +# Dockerfile/Dockerfile.wolfi both do `COPY . /home/app`, and gems/jars are +# installed fresh inside the build (script/bundle -> /usr/local/bundle, +# script/vendor_jars -> vendor/jars), not from these paths. Without this file, +# a developer's local, gitignored build state (e.g. an old vendor/bundle left +# over from before a dependency bump) would get copied verbatim into the +# image and could ship stale/vulnerable jars or gems that a filesystem-based +# vulnerability scan would flag, even though they're never loaded at runtime. +# +# Mirrors the "bundler state" section of .gitignore. +.git +.bundle +vendor/bundle/ +vendor/ruby/ +vendor/filebeat/ +vendor/metricbeat/ +vendor/jruby/ + +# Local caches / IDE / editor artifacts +.m2/ +.local/ +.cache/ +.idea/ +.vscode/ +.DS_Store + +# Build/test output, not build input +coverage +/logs +/crawled_docs +/.artifacts