restrict raw plain forgejo token and force everything through ward-kdl

coilysiren commented

2026-06-23 22:14:13 +00:00

Owner

No description provided.

coilyco-ops added the

P3

consult

labels

2026-06-24 04:15:57 +00:00

coilyco-ops commented

2026-06-24 17:27:39 +00:00

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - Security hardening (force all forgejo through ward-kdl), kept, but body is empty/underspecified.
consult - Needs a design decision on what to restrict and how, human-gated.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - Security hardening (force all forgejo through ward-kdl), kept, but body is empty/underspecified. - **consult** - Needs a design decision on what to restrict and how, human-gated.

coilyco-ops commented

2026-06-24 17:30:00 +00:00

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - Security hardening (force all forgejo through ward-kdl), kept, but body is empty/underspecified.
consult - Needs a design decision on what to restrict and how, human-gated.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - Security hardening (force all forgejo through ward-kdl), kept, but body is empty/underspecified. - **consult** - Needs a design decision on what to restrict and how, human-gated.

coilyco-ops added

headless

and removed

consult

labels

2026-07-02 00:18:47 +00:00

coilyco-ops commented

2026-07-02 00:21:25 +00:00

Member

Flipped headless with posture from #329: agents never hold the raw Forgejo token - implement enforcement plus an audit of remaining raw-token paths (see #161 for the container push-token site). Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops commented

2026-07-06 18:13:09 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-239 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-06T18:13:04Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#239 · branch issue-239 · driver claude · workflow direct-main
Run: engineer-claude-ward-239 · ward v0.414.0 · dispatched 2026-07-06T18:13:04Z
Comment thread: 3 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-06-24T17:27:39Z), @coilyco-ops (2026-06-24T17:30:00Z), @coilyco-ops (2026-07-02T00:21:25Z)

Issue body as seeded:

(empty issue body)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.414.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-239` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-06T18:13:04Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#239` · branch `issue-239` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-239` · ward `v0.414.0` · dispatched `2026-07-06T18:13:04Z` - **Comment thread:** 3 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-06-24T17:27:39Z), @coilyco-ops (2026-06-24T17:30:00Z), @coilyco-ops (2026-07-02T00:21:25Z) **Issue body as seeded:** _(empty issue body)_ Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.414.0). </details>  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-06 18:23:10 +00:00

feat(security): audit + freeze the raw Forgejo-token surface (closes #239)

coilysiren closed this issue

2026-07-06 18:23:10 +00:00

coilysiren commented

2026-07-06 18:23:47 +00:00

Author

Owner

WARD-OUTCOME: done - audited the raw FORGEJO_TOKEN read sites and added a build-time guard test freezing them.

This one read as "consult / needs a design decision," and it was - the empty body plus the broker docs made it clear the full token-drop (#608 Unit D) is genuinely blocked upstream on a cli-guard read op, so I deliberately did not try to force that cutover. The 2026-07-02 steering comment ("implement enforcement plus an audit of remaining raw-token paths") is what let me scope something landable: freeze the surface instead of moving it.

What surprised me was how clean the surface already is - only five raw os.Getenv("FORGEJO_TOKEN") reads, two of them proper resolver chokepoints and three root-only plumbing sites. So the guard test is basically an allowlist ratchet: it caught a synthetic new read when I test-drove it, and it doubles as executable documentation for the audit doc.

Fairly confident in the result. It's low-blast-radius (one test + docs), the enforcement is real (build fails on a new ad-hoc read), and it doesn't pretend to have done #608. Main friction was the pre-commit doc-size and 2-line-comment caps - trimmed the doc and the test comments to fit. Follow-up worth filing: once cli-guard lands the broker read op, #608/#161 can actually drop the token and this audit shrinks to just the two chokepoints.

— Claude (she/her), via ward agent

WARD-OUTCOME: done - audited the raw FORGEJO_TOKEN read sites and added a build-time guard test freezing them. This one read as "consult / needs a design decision," and it was - the empty body plus the broker docs made it clear the full token-drop (#608 Unit D) is genuinely blocked upstream on a cli-guard read op, so I deliberately did *not* try to force that cutover. The 2026-07-02 steering comment ("implement enforcement plus an audit of remaining raw-token paths") is what let me scope something landable: freeze the surface instead of moving it. What surprised me was how clean the surface already is - only five raw `os.Getenv("FORGEJO_TOKEN")` reads, two of them proper resolver chokepoints and three root-only plumbing sites. So the guard test is basically an allowlist ratchet: it caught a synthetic new read when I test-drove it, and it doubles as executable documentation for the audit doc. Fairly confident in the result. It's low-blast-radius (one test + docs), the enforcement is real (build fails on a new ad-hoc read), and it doesn't pretend to have done #608. Main friction was the pre-commit doc-size and 2-line-comment caps - trimmed the doc and the test comments to fit. Follow-up worth filing: once cli-guard lands the broker read op, #608/#161 can actually drop the token and this audit shrinks to just the two chokepoints. — Claude (she/her), via ward agent

coilysiren referenced this issue

2026-07-06 19:34:49 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren referenced this issue

2026-07-06 19:42:27 +00:00

ward: point container git-over-HTTPS push token at the coilyco-ops bot (follow-up to #151) #161

coilyco-ops referenced this issue

2026-07-06 19:43:21 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren referenced this issue

2026-07-06 19:53:25 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621