ci: unconfine seccomp for i686 no IPC
What the developer wrote
Authored by Lőrinc
ci: unconfine seccomp for i686 no IPC
Docker 29.4.2 blocks `socketcall(2)` in the default seccomp profile:
https://docs.docker.com/engine/release-notes/29/#2942
https://github.com/moby/profiles/releases/tag/seccomp%2Fv0.2.2
https://github.com/moby/moby/pull/52501
That affects the `i686, no IPC` job because it runs 32-bit Linux test binaries inside Docker.
Add Docker's documented `--security-opt seccomp=unconfined` workaround to this job's `CI_CONTAINER_CAP` - the hook `ci/test/02_run_container.py` already appends to `docker run`.
This restores socket availability for the 32-bit test binaries throughout the job:
https://docs.docker.com/engine/security/seccomp/#run-without-the-default-seccomp-profile
What changed, and why it matters
This change loosens a security sandbox only for one 32-bit Linux continuous-integration test job. Docker's newer default profile was blocking an old 32-bit system call used for sockets, causing the CI job to fail. The patch tells Docker not to apply its default seccomp filter to that container so the tests can run. It does not change Bitcoin Core code that end users run, and it does not appear to be a fix for a vulnerability in Bitcoin itself.
No user action required. Reviewers may confirm the CI job still needs this broad workaround or consider a narrower custom seccomp profile that only allows socketcall(2), but the change is acceptable as a documented upstream workaround for a test-only container.
Security signals we found
CI sandbox relaxation (seccomp=unconfined) for a single 32-bit test job
Change is confined to CI environment variables, not runtime node code
No mention of vulnerability, CVE, bug bounty, or security advisory in commit
Workaround for upstream Docker seccomp policy change affecting socketcall(2)
Evidence from the diff
The commit adds CI_CONTAINER_CAP="--security-opt seccomp=unconfined" to ci/test/00_setup_env_i686_no_ipc.sh. Docker 29.4.2’s updated seccomp profile blocks socketcall(2) for 32-bit x86 containers (moby/moby#52501). The i686, no IPC CI job runs 32-bit Linux test binaries inside Docker and was therefore affected. The existing ci/test/02_run_container.py appends CI_CONTAINER_CAP to the docker run command, so this setting disables the default seccomp profile for that specific CI container. The change is a CI infrastructure workaround, not a product security patch.
Changed components
ci/test/00_setup_env_i686_no_ipc.shi686, no IPC CI job container configurationInspect captured patch +1 / −0
diff --git a/ci/test/00_setup_env_i686_no_ipc.sh b/ci/test/00_setup_env_i686_no_ipc.sh
index dca0486f..3d19232f 100755
--- a/ci/test/00_setup_env_i686_no_ipc.sh
+++ b/ci/test/00_setup_env_i686_no_ipc.sh
@@ -10,6 +10,7 @@ export HOST=i686-pc-linux-gnu
export CONTAINER_NAME=ci_i686_no_multiprocess
export CI_IMAGE_NAME_TAG="mirror.gcr.io/debian:trixie"
export CI_IMAGE_PLATFORM="linux/amd64"
+export CI_CONTAINER_CAP="--security-opt seccomp=unconfined"
export PACKAGES="llvm clang g++-multilib"
export DEP_OPTS="DEBUG=1 NO_IPC=1"
export GOAL="install"
Why this scored 20/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.