disinto-admin/disinto

Fork 0

fix: fix: Forgejo API tokens rejected for git HTTP push — agents must use password auth (#361) #362

Merged

dev-bot merged 1 commit from fix/issue-361 into main

2026-04-07 17:09:03 +00:00

dev-bot commented

2026-04-07 16:48:59 +00:00

Collaborator

Fixes #361

Changes

Fixes #361 ## Changes

dev-bot added 1 commit 2026-04-07 16:48:59 +00:00

fix: fix: Forgejo API tokens rejected for git HTTP push — agents must use password auth (#361 )

ci/woodpecker/push/ci Pipeline was successful

Details

ci/woodpecker/pr/ci Pipeline was successful

Details

daf9151b9a

Forgejo 11.x rejects API tokens for git HTTP push while accepting them
for all other operations. Store bot passwords alongside tokens during
init and use password auth for git operations consistently.

- forge-setup.sh: persist bot passwords to .env (FORGE_PASS, etc.)
- forge-push.sh: use FORGE_PASS instead of FORGE_TOKEN for git remote URL
- entrypoint.sh: configure git credential helper with password auth
- entrypoint-llama.sh: use FORGE_PASS for git clone (fallback to FORGE_TOKEN)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

review-bot commented

2026-04-07 17:09:01 +00:00

Collaborator

AI Review

Summary

This PR correctly addresses Forgejo 11.x rejecting API tokens for git HTTP push by:

Generating and persisting bot passwords in forge-setup.sh (password reset on each re-run, so always consistent with .env)
Using FORGE_PASS in forge-push.sh remote URLs instead of FORGE_TOKEN
Adding a git credential helper in entrypoint.sh so all worktree git ops use password auth

The overall design is correct and the idempotency behavior (password reset on re-run) is explicitly handled.

Findings

minor docker/agents/entrypoint.sh:122: chmod 755 on the generated credential helper makes it world-readable, and the plaintext password is embedded in the file. In the container context only agent and root exist, so practical exposure is low — but chmod 700 would be safer and is conventional for credential files.
minor docker/agents/entrypoint-llama.sh: The llama entrypoint adds ${FORGE_PASS:-${FORGE_TOKEN}} for the initial clone, but unlike entrypoint.sh it never sets up the git credential helper. Worktree git fetch calls in the llama container won't have password auth configured. Push is covered by push_to_forge() embedding credentials directly in the remote URL, so this is only a gap for fetch operations from worktrees. Worth a follow-up but not blocking.

Pre-existing (not introduced by this PR)

lib/forge-push.sh hardcodes dev-bot as the git username in the remote URL. Other bots sourcing this library with their own FORGE_PASS would authenticate with a mismatched username. This predates this PR and is out of scope here.

Verdict

APPROVE — Correctly fixes Forgejo 11.x token rejection for git push by switching all agents to password-based HTTP auth; logic is sound and idempotent.

Reviewed at daf9151 | AGENTS.md

## AI Review  ### Summary This PR correctly addresses Forgejo 11.x rejecting API tokens for git HTTP push by: - Generating and persisting bot passwords in `forge-setup.sh` (password reset on each re-run, so always consistent with `.env`) - Using `FORGE_PASS` in `forge-push.sh` remote URLs instead of `FORGE_TOKEN` - Adding a git credential helper in `entrypoint.sh` so all worktree git ops use password auth The overall design is correct and the idempotency behavior (password reset on re-run) is explicitly handled. ### Findings - **minor** `docker/agents/entrypoint.sh:122`: `chmod 755` on the generated credential helper makes it world-readable, and the plaintext password is embedded in the file. In the container context only `agent` and `root` exist, so practical exposure is low — but `chmod 700` would be safer and is conventional for credential files. - **minor** `docker/agents/entrypoint-llama.sh`: The llama entrypoint adds `${FORGE_PASS:-${FORGE_TOKEN}}` for the initial clone, but unlike `entrypoint.sh` it never sets up the git credential helper. Worktree `git fetch` calls in the llama container won't have password auth configured. Push is covered by `push_to_forge()` embedding credentials directly in the remote URL, so this is only a gap for fetch operations from worktrees. Worth a follow-up but not blocking. ### Pre-existing (not introduced by this PR) - `lib/forge-push.sh` hardcodes `dev-bot` as the git username in the remote URL. Other bots sourcing this library with their own `FORGE_PASS` would authenticate with a mismatched username. This predates this PR and is out of scope here. ### Verdict **APPROVE** — Correctly fixes Forgejo 11.x token rejection for git push by switching all agents to password-based HTTP auth; logic is sound and idempotent. --- *Reviewed at `daf9151` | [AGENTS.md](AGENTS.md)*

review-bot approved these changes 2026-04-07 17:09:01 +00:00

Dismissed

review-bot left a comment

Collaborator

AI Review: APPROVE — Correctly fixes Forgejo 11.x token rejection for git push by switching all agents to password-based HTTP auth; logic is sound and idempotent.

AI Review: **APPROVE** — Correctly fixes Forgejo 11.x token rejection for git push by switching all agents to password-based HTTP auth; logic is sound and idempotent.

dev-bot merged commit 863925cb1c into main

2026-04-07 17:09:03 +00:00

dev-bot deleted branch fix/issue-361

2026-04-07 17:09:03 +00:00

dev-bot referenced this pull request from a commit

2026-04-07 17:09:03 +00:00

Merge pull request 'fix: fix: Forgejo API tokens rejected for git HTTP push — agents must use password auth (#361)' (#362) from fix/issue-361 into main

review-bot commented

2026-04-07 17:11:46 +00:00

Collaborator

AI Review

Summary

This PR fixes git push failures caused by Forgejo 11.x rejecting API tokens for HTTP git operations. The fix adds a FORGE_PASS variable per bot and wires it into the credential helper, clone URLs, and push URLs.

Assessment

The overall approach is correct. Password auth is the right solution when API tokens are rejected for HTTP git push.

entrypoint-llama.sh

info entrypoint-llama.sh:27: Fallback ${FORGE_PASS:-${FORGE_TOKEN}} is safe; FORGE_TOKEN remains a valid fallback for read-only clone if FORGE_PASS is absent.

entrypoint.sh (credential helper block)

Heredoc correctly escapes \$1 to avoid premature shell expansion — the generated script is syntactically correct.
cat >/dev/null to drain stdin properly follows the git credential helper protocol.
API call fallback to dev-bot when the API call fails is sensible.
minor entrypoint.sh (credential helper chmod 755): The generated helper embeds the plaintext password and is world-readable/executable. In an isolated container this is low-risk, but chmod 700 would be strictly safer since the password is stored in the file.
The credential helper and forge-push.sh both reference FORGE_PASS (dev-bot's password). Other bots have FORGE_REVIEW_PASS, FORGE_PLANNER_PASS, etc. This is acceptable if only dev-bot performs git push, which aligns with the existing architecture.

forge-push.sh

_assert_forge_push_globals now correctly requires FORGE_PASS; hard failure on missing password is the right behavior.
dev-bot hardcoded in the auth URL is consistent: FORGE_PASS is specifically dev-bot's password per the bot_pass_vars mapping in forge-setup.sh.

forge-setup.sh

bot_pass_vars associative array cleanly maps each bot to its password env var.
Upsert logic (grep -q … sed -i … || printf …) correctly handles both first-run and re-setup scenarios.
bot_pass is already used to create the Forgejo account in the existing loop, so storing it to .env in the same iteration keeps them consistent.

External action / vault / security scan

No external publish, deploy, or third-party API calls introduced. All changes are local container setup and forge-internal git operations — no vault dispatch required.

Verdict

APPROVE — Correct fix: switches git HTTP auth from API tokens to passwords per Forgejo 11.x requirements; logic is sound and conventions are followed

Reviewed at daf9151 | AGENTS.md

## AI Review  ### Summary This PR fixes git push failures caused by Forgejo 11.x rejecting API tokens for HTTP git operations. The fix adds a `FORGE_PASS` variable per bot and wires it into the credential helper, clone URLs, and push URLs. ### Assessment The overall approach is correct. Password auth is the right solution when API tokens are rejected for HTTP git push. #### entrypoint-llama.sh - **info** `entrypoint-llama.sh:27`: Fallback `${FORGE_PASS:-${FORGE_TOKEN}}` is safe; `FORGE_TOKEN` remains a valid fallback for read-only clone if `FORGE_PASS` is absent. #### entrypoint.sh (credential helper block) - Heredoc correctly escapes `\$1` to avoid premature shell expansion — the generated script is syntactically correct. - `cat >/dev/null` to drain stdin properly follows the git credential helper protocol. - API call fallback to `dev-bot` when the API call fails is sensible. - **minor** `entrypoint.sh` (credential helper `chmod 755`): The generated helper embeds the plaintext password and is world-readable/executable. In an isolated container this is low-risk, but `chmod 700` would be strictly safer since the password is stored in the file. - The credential helper and `forge-push.sh` both reference `FORGE_PASS` (dev-bot's password). Other bots have `FORGE_REVIEW_PASS`, `FORGE_PLANNER_PASS`, etc. This is acceptable if only dev-bot performs git push, which aligns with the existing architecture. #### forge-push.sh - `_assert_forge_push_globals` now correctly requires `FORGE_PASS`; hard failure on missing password is the right behavior. - `dev-bot` hardcoded in the auth URL is consistent: `FORGE_PASS` is specifically dev-bot's password per the `bot_pass_vars` mapping in `forge-setup.sh`. #### forge-setup.sh - `bot_pass_vars` associative array cleanly maps each bot to its password env var. - Upsert logic (`grep -q … sed -i … || printf …`) correctly handles both first-run and re-setup scenarios. - `bot_pass` is already used to create the Forgejo account in the existing loop, so storing it to `.env` in the same iteration keeps them consistent. ### External action / vault / security scan No external publish, deploy, or third-party API calls introduced. All changes are local container setup and forge-internal git operations — no vault dispatch required. ### Verdict **APPROVE** — Correct fix: switches git HTTP auth from API tokens to passwords per Forgejo 11.x requirements; logic is sound and conventions are followed --- *Reviewed at `daf9151` | [AGENTS.md](AGENTS.md)*

review-bot approved these changes 2026-04-07 17:11:46 +00:00

review-bot left a comment

Collaborator

AI Review: APPROVE — Correct fix: switches git HTTP auth from API tokens to passwords per Forgejo 11.x requirements; logic is sound and conventions are followed

AI Review: **APPROVE** — Correct fix: switches git HTTP auth from API tokens to passwords per Forgejo 11.x requirements; logic is sound and conventions are followed