review(redfix): re-confirmation #17 — consumed ADVERSARY-INBOX (Builder wake #18); accepted their correction after re-deriving it (/etc/cc-ci HEAD is main@d11f8f56; redfix-m2-harness is a stale local branch there; b5f2b10 ABSENT — conclusion unchanged, NOT-MERGED holds); confirmed B-redfix-7 as A-redfix-1 with repro but corrected its rationale (LOW rests on mount-namespace isolation, not on absence of login users — mode DOES permit uid1000); caught my own near-miss before it became evidence (setpriv ran in host ns; the real uid-1000 java IS warm-keycloak but is containerized and cannot read host /etc); no VETO, DONE stands

machine-docs/REVIEW-redfix.md

@@ -888,3 +888,37 @@ numeric; the wrong number cannot make it false. Builder's choice to defer rather
 (which M2's PASS pins) is the right call — I do not want the branch moved to fix a comment.
 
 **Verdict: no finding. M1 + M2 PASS stand. DONE stands. No VETO.**
+
+## re-confirmation #17 @2026-07-09T02:00Z — consumed ADVERSARY-INBOX (Builder wake #18); one fact of mine corrected, one near-miss of mine caught; no verdict change
+
+**Builder's correction to re-confirmation #16 is RIGHT; I re-derived it rather than accepting it.**
+I wrote that `/etc/cc-ci` "holds `redfix-m2-harness` at `b96b8a4c`". Cold re-check:
+`symbolic-ref HEAD` -> `refs/heads/main`; `rev-parse HEAD` -> `d11f8f56` (2026-06-17). `redfix-m2-harness`
+@`b96b8a4c` exists there only as a **stale local branch**, not as HEAD. `cat-file -e b5f2b10` -> **ABSENT**
+(that half of my claim holds). **My conclusion is unchanged and remains correct**: stale local checkout, not
+branch drift; the remote is authoritative at `b5f2b10`; NOT-MERGED still holds. #16's REVIEW text is
+superseded on this one fact by this entry. The Builder is right that re-confirmations cite one another and a
+wrong fact in a clean sweep gets inherited — that is exactly why they re-derived instead of inheriting, and
+so did I.
+
+**B-redfix-7 (cleartext Gitea bot password in a 0644 file): CONFIRMED, severity LOW, wrong rationale.**
+Filed independently as **A-redfix-1** with repro. The Builder's stated mitigation ("no non-root *login*
+users") is the wrong axis — the mode really does permit uid 1000 to read the credential. What actually
+contains the blast radius is **mount-namespace isolation**: exactly one non-root process (`dbus-daemon`,
+uid 4) runs in the host mount namespace; every other, including the uid-1000 Quarkus `java` that *is* the
+internet-facing warm-keycloak, is containerized and cannot see host `/etc`. Same LOW verdict, load-bearing
+for a different reason — and that reason silently dies if a non-root host-ns daemon appears or `/etc` is
+ever bind-mounted into a container.
+
+**Near-miss recorded against myself.** I ran `setpriv --reuid=1000 … cat` (which succeeded), cross-referenced
+the uid-1000 `java` in `ps`, and was one inference from writing "internet-facing Keycloak can exfiltrate the
+Gitea bot credential." False. `setpriv` ran in the **host** namespace; the real process does not
+(`ls /proc/<pid>/root/etc/cc-ci/.git/config` -> No such file or directory). Mode-permits != reachable. This
+is the second time in two wakes that a probe of mine produced a plausible answer for an invalid reason (cf.
+the false NOT-MERGED from a bad-path `git -C`). Both were caught by re-running the probe against the thing it
+purported to measure, not by rechecking the conclusion — which was right both times.
+
+**Out of scope, no VETO.** A-redfix-1 is pre-existing infra state, touches no DoD item, and the credential is
+a Class-A1 external input (plan §4.4) — operator's to rotate, not mine, not the Builder's.
+
+**Verdict: no change. M1 + M2 PASS stand. DONE stands. No VETO.** Inbox consumed + deleted.