Frank
8af40c402b
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and `merge --ff-only` refuses while tracked paths are dirty. Discard is not available here (workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed. - `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new prose — the commit exists so the trunk merge can proceed. - `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat owns (AGENTS.md § Live-sync tiers). `ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the inert all-zero AWS example id — and they appear inside the two skill pages that teach that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal dies with this landing. No `--no-verify` was used: the gate ran and its verdict is recorded here. Refs #61
2.0 KiB
2.0 KiB
name, description
| name | description |
|---|---|
| gitea-credential-store-url-format | Auth to the Dankclaw Gitea API without the empty-header trap: ~/.config/secrets/gitea is a git-credential-store URL file, so awk '/^password=/' returns empty; resolve the token via git credential fill, and Gitea writes need Authorization: token (reads pass anonymously on a public repo). |
Gitea auth on Dankclaw: the URL-format credential store
~/.config/secrets/gitea is git config credential.helper = store --file ~/.config/secrets/gitea, i.e. a git-credential-store URL file:
http://dank:<40hex-token>@192.168.0.143:3000
It does NOT contain username=/password= lines. So:
# WRONG — silently returns empty string
p=$(awk -F= '/^password=/{print substr($0,10)}' ~/.config/secrets/gitea)
An empty $p makes every curl send Authorization: token (blank) → Gitea replies {"message":"token is required"} on writes, while reads still return 200 (the repo is public-readable, so a green GET /labels or /issues proves nothing about auth). Symptom: PR-create returns token is required even though a GET just "worked".
Resolve the real token via git
p=$(printf 'protocol=http\nhost=192.168.0.143:3000\n\n' \
| git credential fill 2>/dev/null \
| awk -F= '/^password=/{print substr($0,10)}') # 40-hex token
Write auth = token scheme, via a 600-perm -K file
cfg=$(mktemp); chmod 600 "$cfg"
printf 'header = "Authorization: token %s"\n' "$p" > "$cfg"
curl -s -K "$cfg" http://192.168.0.143:3000/api/v1/user # confirms identity
curl -s -K "$cfg" -X POST -H 'Content-Type: application/json' --data @body.json "$API/pulls"
- Never pass the token with
-H— it lands in/proc/<pid>/cmdline, world-readable. - Confirm identity with
GET /userbefore trusting a write path; atoken is requiredthere means the token never authenticated. - Merges are a separate shape (form-encoded
do=merge, auth-only cfg, NOContent-Typeheader) — see the gitea-merge-form-encoded skill.