Make forge auth handling argv-safe with no token export footguns #55

Closed
opened 2026-06-21 17:21:59 +01:00 by vnprc-agent · 1 comment
Contributor

Current forge authentication handling is unacceptable: token values are passed to curl in argv.

This is not limited to forge token verify --token. The current token_verify implementation loads the token and then calls curl -H "Authorization: token $verify_token", so even plain forge token verify with the configured token leaks the token to the child curl process argv while the request is running. The shared API helper uses the same curl -H "Authorization: token $TOKEN" pattern, so the fix must harden auth header handling across forge, not just one subcommand.

Project policy: no token exposure footguns in forge.

Do not add any command or flag that prints, echoes, displays, exports, or otherwise intentionally reveals a live token. In particular, do not add equivalents of gh auth token or gh auth status --show-token. If a future workflow needs to hand credentials to another tool, implement a narrow credential-helper style integration for that workflow instead of a generic token-dump command.

Desired design:

  • Introduce one shared safe request path for Forgejo API calls that never passes token material in argv. Use curl --config -, a private file descriptor, or an equivalent mechanism that keeps the Authorization header out of process arguments.
  • Change forge token verify to verify only a token supplied on stdin. No implicit configured-token mode, no --token <value>, and no --token-file <path>.
  • Add an auth command namespace for configured credentials:
    • forge auth status verifies the configured/default credential source without exposing token material in argv or output.
    • Do not add token-printing behavior.
  • Keep normal commands using the configured token source (FORGEJO_TOKEN or FORGE_TOKEN_FILE) internally, but route their API calls through the same argv-safe request helper.
  • Update help and README so stored/default auth is documented under forge auth, while forge token verify is documented as stdin-only candidate-token verification.
  • Update tests so they fail if any Forgejo API request sends an Authorization header via curl -H argv.
  • Update tests/forge/token.sh to expect --token and --token-file rejection, and add stdin verification coverage.
  • Add tests/forge/auth.sh coverage for configured-token status checks.
  • Add negative tests proving there is no auth token, --show-token, --token, or --token-file path.

Expected rotation usage:

extract-token-safely | forge token verify

Expected configured-auth usage:

forge auth status

This matters for the token rotation plan because verification commands must not put live token material in shell history, process argv, terminal scrollback, temporary files, generic token-export commands, or avoidable secret-path arguments.

Current `forge` authentication handling is unacceptable: token values are passed to `curl` in argv. This is not limited to `forge token verify --token`. The current `token_verify` implementation loads the token and then calls `curl -H "Authorization: token $verify_token"`, so even plain `forge token verify` with the configured token leaks the token to the child `curl` process argv while the request is running. The shared API helper uses the same `curl -H "Authorization: token $TOKEN"` pattern, so the fix must harden auth header handling across `forge`, not just one subcommand. Project policy: no token exposure footguns in `forge`. Do not add any command or flag that prints, echoes, displays, exports, or otherwise intentionally reveals a live token. In particular, do not add equivalents of `gh auth token` or `gh auth status --show-token`. If a future workflow needs to hand credentials to another tool, implement a narrow credential-helper style integration for that workflow instead of a generic token-dump command. Desired design: - Introduce one shared safe request path for Forgejo API calls that never passes token material in argv. Use `curl --config -`, a private file descriptor, or an equivalent mechanism that keeps the Authorization header out of process arguments. - Change `forge token verify` to verify only a token supplied on stdin. No implicit configured-token mode, no `--token <value>`, and no `--token-file <path>`. - Add an auth command namespace for configured credentials: - `forge auth status` verifies the configured/default credential source without exposing token material in argv or output. - Do not add token-printing behavior. - Keep normal commands using the configured token source (`FORGEJO_TOKEN` or `FORGE_TOKEN_FILE`) internally, but route their API calls through the same argv-safe request helper. - Update help and README so stored/default auth is documented under `forge auth`, while `forge token verify` is documented as stdin-only candidate-token verification. - Update tests so they fail if any Forgejo API request sends an Authorization header via `curl -H` argv. - Update `tests/forge/token.sh` to expect `--token` and `--token-file` rejection, and add stdin verification coverage. - Add `tests/forge/auth.sh` coverage for configured-token status checks. - Add negative tests proving there is no `auth token`, `--show-token`, `--token`, or `--token-file` path. Expected rotation usage: ```sh extract-token-safely | forge token verify ``` Expected configured-auth usage: ```sh forge auth status ``` This matters for the token rotation plan because verification commands must not put live token material in shell history, process argv, terminal scrollback, temporary files, generic token-export commands, or avoidable secret-path arguments.
vnprc-agent changed title from Remove forge token verify --token to Use stdin for forge token verification 2026-06-21 17:27:04 +01:00
vnprc-agent changed title from Use stdin for forge token verification to Make forge auth handling argv-safe 2026-06-21 17:33:28 +01:00
vnprc-agent changed title from Make forge auth handling argv-safe to Make forge auth handling argv-safe with no token export footguns 2026-06-21 17:38:14 +01:00
Owner

gh auth token just straight up prints the auth token. this decision was apparently made to optimize for ecosystem adoption over secure scripting practices. 🤦

hopefully it goes without saying that this is B-A-N-A-N-A-S

those corpo vampires would ship a fucking guillotine if it lead to marginally higher profits. fuck those assholes. there will be no footguns in my project so help me god

`gh auth token` just straight up prints the auth token. this decision was apparently made to optimize for ecosystem adoption over secure scripting practices. 🤦 hopefully it goes without saying that this is B-A-N-A-N-A-S those corpo vampires would ship a fucking guillotine if it lead to marginally higher profits. fuck those assholes. there will be no footguns in my project so help me god
vnprc closed this issue 2026-06-22 13:39:43 +01:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/tools#55
No description provided.