fix(container): apt-get upgrade in runtime stage for Debian CVE patches#47
Open
matthew-on-git wants to merge 1 commit into
Open
fix(container): apt-get upgrade in runtime stage for Debian CVE patches#47matthew-on-git wants to merge 1 commit into
matthew-on-git wants to merge 1 commit into
Conversation
Trivy's blocking OS-package scan failed v1.11.2 with three HIGH vulnerabilities — libcap2 CVE-2026-4878 (privilege-escalation TOCTOU race) and libsystemd0/libudev1 CVE-2026-29111 (arbitrary code execution / DoS). All three were "fixed" in Debian bookworm but the versions installed by the base image's COPY were one patch behind. Without an explicit `apt-get upgrade` step, the runtime image's already-installed system libraries stay at whatever version the debian:bookworm-slim manifest shipped — which lags Debian's security archive by hours-to-days. Adding `apt-get upgrade -y --no-install-recommends` to the same layer as the install step pulls the latest patched versions of all base packages on every build. The scheduled weekly build catches this drift via fresh layer caches, but per-PR builds (like the v1.11.1/v1.11.2 tag pushes) need the explicit upgrade. NOT validated locally — the kotlin install step hit a flaky curl exit 56 during my rebuild. The Dockerfile change is conceptually trivial; CI will confirm. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Summary
Trivy's blocking OS-package scan failed on v1.11.2 (run 26108273647) with three HIGH vulnerabilities:
libcap2cap_set_file()libsystemd0libudev1All three have Debian-archive fixes available. The runtime stage's existing
apt-get installdoesn't refresh already-installed packages from thedebian:bookworm-slimbase, so newly-released CVE patches don't land until either (a) the base manifest gets updated, or (b) we explicitlyapt-get upgrade.Adding
apt-get upgrade -y --no-install-recommendsto the same layer asapt-get installis the canonical fix. Same layer keeps image size down.Caveat: not validated locally
The local rebuild flaked on
install-kotlin.shwithcurl: (56) Failure when receiving datamid-build. Network blip, not related to the Dockerfile change. CI is the canonical validation environment for this kind of change — letting CI green-light it.Heads-up: tag history
While debugging this I noticed
v1.11.1andv1.11.2tags exist but neither has a correspondingchore(release): prepare ...commit, and neither triggered theBuild and Publish Containerworkflow (the v1.11.1 tag actually points at the v1.11.0 release commit). They look like stale/accidental retags. After this PR merges, I'd suggest cutting viamake release VERSION=1.11.3so the CHANGELOG and tag are consistent again.🤖 Generated with Claude Code