AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

ci: Reject unsafe execution of shell scripts

Public commit record

What the developer wrote

Authored by MarcoFalke

92/100 · Strong
ci: Reject unsafe execution of shell scripts

The shell scripts are inherently unsafe, because they will install new
software packages, modify global configuration settings, write to the
root / or $HOME, and possibly modify the git repo.

The only safe way to run them is through the CI system itself, that is
the ci_exec python function.

The ci_exec funtion ensures that the user has set up a sandbox
externally and set DANGER_RUN_CI_ON_HOST=1 at their own risk, or that a
sandbox was set up with the given container_id, in which case it is safe
to set DANGER_RUN_CI_ON_HOST=1 for that sandbox.
Also, it is safe to set DANGER_RUN_CI_ON_HOST=1 when building the
sandbox image in ci/test_imagefile.

Then, the two shell scripts can reject early if unsafe execution is
detected.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit adds safety guards to Bitcoin Core's continuous integration (CI) shell scripts. The scripts install software and change system settings, so they could damage a developer's computer or the source code repository if run directly by mistake. The change makes the scripts refuse to run unless a special safety flag, DANGER_RUN_CI_ON_HOST=1, is set, and it arranges for that flag to be set automatically only inside the intended container environment. It is a hardening improvement, not a fix for an active attack.

Recommended action

No urgent action needed. Reviewers and CI users should ensure they only run these scripts through the supported ci_exec path or after explicitly setting DANGER_RUN_CI_ON_HOST=1 in a sandbox. This is a defensive hardening change; consider it for backporting to active release branches that use the same CI scripts.

Security signals we found

01

Addition of guard condition requiring DANGER_RUN_CI_ON_HOST=1 before destructive CI scripts run

02

Automatic injection of DANGER_RUN_CI_ON_HOST=1 only inside Docker container execution path

03

Explicit commit message describing scripts as 'inherently unsafe' and the change as a safety measure

04

No changes to consensus, networking, wallet, or P2P code

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 4/15
Affected reach 5/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.