fix(hardening-ratchet): a Dockerfile with no FROM is a finding, not a pass - #2606
Merged
Merged
Conversation
… pass #2604 found 9 tracked Dockerfiles that #2285 truncated down to their USER tails -- no FROM, so `docker build` fails with "no build stage in current context" and `make overlay-up-agents` died on notebooklm-agent. This gate stayed GREEN through all of it. That is my gap, and it is the same shape as the one this tool was written to close. #2592 replaced a `grep 'USER'` that scored `USER root` as compliant, with a rule that judges the LAST USER directive. But a file whose only line is `USER pmoves` also passes that rule: the last USER is non-root, so the gate says compliant about a file that cannot build. It asserted a property nobody had asked about. NO_FROM is now checked FIRST and short-circuits, so a fragment is reported as what it is instead of being scored on a USER directive with no image to apply to. It is explicitly not baselineable -- the output says "Restore the file content. Do NOT baseline it." A truncated Dockerfile is damage, not a deliberate exception. Also renamed the summary line from "Root-running: N" to "Findings: N". NO_FROM is not a root-privilege problem, and a gate that mislabels what it counted is how it ends up trusted for something it never checked. Verified both directions: main after #2604 -> exit 0, "Findings: 12 (12 baselined, 0 new)" owner-presence re-truncated -> exit 1, "NO_FROM pmoves/services/owner-presence/Dockerfile" and, run against main BEFORE #2604, it flags exactly the 9 files #2604 restored -- 9 for 9, independently confirming that list was complete. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Merged
3 tasks
POWERFULMOVES
pushed a commit
that referenced
this pull request
Aug 19, 2026
…ages Two follow-ups to #2604's restores, found bringing the agents overlay up on SPARK: - notebooklm-agent (node:20-alpine): Alpine has no useradd; the `|| true` fallback silently skipped creation and left `USER pmoves` dangling — the daemon refused to start ("unable to find user pmoves"). Switched to `adduser -D -s /bin/sh` with no silent fallback; verified the rebuilt image carries pmoves (uid 1001) and runs non-root. - agentgym-rl-coordinator (distroless final stage): no shell, no useradd, RUN cannot execute at all. Use the stage's built-in `nonroot` user, which the pre-existing HF_HOME=/home/nonroot was designed around. Hardening ratchet (with #2606's NO_FROM check): 12/12 baselined, 0 new. Generated with Crush
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 19, 2026
…ages (#2609) Two follow-ups to #2604's restores, found bringing the agents overlay up on SPARK: - notebooklm-agent (node:20-alpine): Alpine has no useradd; the `|| true` fallback silently skipped creation and left `USER pmoves` dangling — the daemon refused to start ("unable to find user pmoves"). Switched to `adduser -D -s /bin/sh` with no silent fallback; verified the rebuilt image carries pmoves (uid 1001) and runs non-root. - agentgym-rl-coordinator (distroless final stage): no shell, no useradd, RUN cannot execute at all. Use the stage's built-in `nonroot` user, which the pre-existing HF_HOME=/home/nonroot was designed around. Hardening ratchet (with #2606's NO_FROM check): 12/12 baselined, 0 new. Generated with Crush Co-authored-by: Agent Zero <agent.zero@pmoves.ai>
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
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.
Follow-up to #2604, closing the gap that let it happen silently.
The gap
#2285's hardening pass truncated 9 tracked Dockerfiles down to their
USERtails — noFROM, sodocker buildfails with "no build stage in current context" andmake overlay-up-agentsdied onnotebooklm-agent.maincould not build those images.hardening-validationstayed green through all of it. That is my gate, and this is the same failure shape it was written to fix.#2592 replaced a
grep 'USER'that scoredUSER rootas compliant, with a rule that judges the lastUSERdirective. But a file whose only line isUSER pmovesalso passes that rule — the lastUSERis non-root, so the gate reports compliant about a file that cannot build. It was asserting a property nobody had asked about.The change
NO_FROMis checked first and short-circuits, so a fragment is reported as a fragment rather than scored on aUSERdirective with no image to apply to.Root-running: NtoFindings: N.NO_FROMis not a root-privilege problem, and a gate that mislabels what it counted is how it ends up trusted for something it never checked.Verification — both directions
Run against
mainbefore #2604, it flags exactly the 9 files that PR restored — 9 for 9, which independently confirms #2604's list was complete.No baseline change:
_known_gaps.yamlstays at 12.