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/BACKLOG-redfix.md

@@ -105,6 +105,49 @@ hold). Concrete fix designs from M1 evidence:
 
 (Adversary-owned — do not edit.)
 
+### A-redfix-1 [adversary] — `/etc/cc-ci/.git/config` is 0644 and embeds the Gitea bot password in cleartext (severity LOW, but for a different reason than B-redfix-7 states)
+
+Independently confirmed the Builder's B-redfix-7. Out of redfix scope; **no VETO, does not reopen the phase**
+(pre-existing undeclared server state, not created by redfix, not covered by any DoD item). Filed so the
+severity *rationale* is right, because the wrong rationale would let the mitigation evaporate silently.
+
+**Repro (read-only, from any shell with `ssh cc-ci`):**
+
+    stat -c '%a %U:%G %n' /etc/cc-ci/.git/config      # -> 644 root:root
+    grep -c 'dobMzaDQT94lVA' /etc/cc-ci/.git/config    # -> 1   (cleartext bot password in origin URL)
+    stat -c '%a %n' / /etc /etc/cc-ci /etc/cc-ci/.git  # -> 755 on every parent: world-traversable
+
+**Why LOW — the correct reason.** B-redfix-7 argues "no non-root *login* users exist (no uid>=1000 with a
+real shell)". That is the wrong axis: the risk is any non-root *code execution*, login shell or not. The
+mode genuinely permits it —
+
+    setpriv --reuid=1000 --regid=1000 --clear-groups cat /etc/cc-ci/.git/config   # -> prints the password
+
+— so the file is readable by uid 1000. What actually holds the severity down is **mount-namespace
+isolation**, which neither of us had checked: *every* non-root process on the box is containerized and its
+`/etc` is not the host's. I enumerated it directly (compare `/proc/<pid>/ns/mnt` against `/proc/1/ns/mnt`):
+of all non-root processes, exactly **one** lives in the host mount namespace — `dbus-daemon`, uid 4
+(`messagebus`), not network-facing. Everything else (incl. the uid-1000 `java` = the warm-keycloak Quarkus
+container) is in its own namespace and **cannot** reach host `/etc/cc-ci`; verified:
+`ls /proc/<keycloak-pid>/root/etc/cc-ci/.git/config` -> *No such file or directory*.
+
+**Correction to my own probe.** My first pass read the uid-1000 `java` process off `ps`, saw `setpriv` as
+uid 1000 print the password, and was one step from concluding "the internet-facing Keycloak can steal the
+Gitea bot credential." It cannot. `setpriv` ran in the **host** namespace; the real uid-1000 process does
+not. Mode-permits != reachable-by-a-real-process. Recording the near-miss so it is not re-derived as fact.
+
+**Why it still matters.** The mitigation is incidental, not designed. It fails the moment anyone (a) runs a
+non-root daemon in the host namespace, or (b) bind-mounts `/etc` into any container. Contrast the 28 other
+`.git/config` files carrying the same cleartext credential under `/root`: those are protected by design —
+`/root` is `0700`, and the control probe confirms it
+(`setpriv --reuid=1000 … cat /root/.abra/recipes/drone/.git/config` -> *Permission denied*).
+`/etc/cc-ci` is the sole copy whose parents are world-traversable.
+
+**Operator action (agreed with Builder: not ours).** Rotate the `autonomic-bot` Gitea token (Class-A1
+external input, plan §4.4), then `chmod 600 /etc/cc-ci/.git/config` — or delete `/etc/cc-ci`, which is an
+orphaned real dir (not a `/nix/store` symlink) referenced by no systemd unit. `/root/.git-credentials` is
+already `0600`. **Closable only by me, after re-test.**
+
 ### [adversary] F-redfix-4 — keycloak enrollment is collision-free in DOMAIN but NOT in warm-state: the live-warm reconciler and the new data-warm canonical share one per-recipe snapshot slot — **CLOSED @2026-07-09T00:18Z (VETO CLEARED)**
 
 **CLOSED by Adversary re-test.** Fixed at `redfix-m2-harness`@`b5f2b10` (parent `07fc6d4`): `canonical_ns()`