Consider deprecating FORGEJO_TOKEN env var in favor of file-only token access #57

Open
opened 2026-06-22 04:49:15 +01:00 by vnprc-agent · 0 comments
Contributor

User story: So that I can choose credential handling with clear exposure tradeoffs, forge should explicitly deprecate or document raw token environment variables instead of leaving that risk implicit.

Part of the "Forge / workspace CLI tooling" arc.


FORGEJO_TOKEN is visible in /proc/PID/environ with the same access model as /proc/PID/cmdline. PR #56 hardened curl argv, but the env var token source has similar exposure characteristics: it persists for the entire shell session, is inherited by every child process, and is readable by any process that can read /proc/PID/environ (same permission model as the argv we just fixed).

This is not urgent — the primary threat model for forge is accidental exposure (logs, history, dotfile repos) rather than active process snooping, and the env var is convenient for CI and container contexts. But the inconsistency should be resolved explicitly rather than left as a silent gap.

Options:

  1. Deprecate FORGEJO_TOKEN entirely. File-only token access. Simple, consistent, but breaks existing scripts and CI workflows that set the env var.

  2. Keep FORGEJO_TOKEN but document the tradeoff. Acknowledge that env vars have proc visibility, recommend file-based access as the default, and position the env var as an opt-in convenience for contexts where proc visibility is acceptable (single-user VMs, CI runners).

  3. Replace FORGEJO_TOKEN with FORGE_TOKEN_FILE override only. Instead of accepting a raw token in the environment, accept only a file path. This keeps the env-based override pattern without putting the token itself in the environment. Scripts that currently do FORGEJO_TOKEN=xxx forge ... would change to writing a temp file.

  4. Add a FORGE_TOKEN_CMD credential helper. A command that prints the token to stdout, invoked on demand. Similar to git's credential.helper or AWS's credential_process. This is the most composable option but the heaviest to implement.

The right answer depends on whether we consider proc-visible env vars an acceptable exposure surface for this tool's threat model.

**User story:** So that I can choose credential handling with clear exposure tradeoffs, `forge` should explicitly deprecate or document raw token environment variables instead of leaving that risk implicit. _Part of the "Forge / workspace CLI tooling" arc._ --- `FORGEJO_TOKEN` is visible in `/proc/PID/environ` with the same access model as `/proc/PID/cmdline`. PR #56 hardened curl argv, but the env var token source has similar exposure characteristics: it persists for the entire shell session, is inherited by every child process, and is readable by any process that can read `/proc/PID/environ` (same permission model as the argv we just fixed). This is not urgent — the primary threat model for forge is accidental exposure (logs, history, dotfile repos) rather than active process snooping, and the env var is convenient for CI and container contexts. But the inconsistency should be resolved explicitly rather than left as a silent gap. Options: 1. **Deprecate `FORGEJO_TOKEN` entirely.** File-only token access. Simple, consistent, but breaks existing scripts and CI workflows that set the env var. 2. **Keep `FORGEJO_TOKEN` but document the tradeoff.** Acknowledge that env vars have proc visibility, recommend file-based access as the default, and position the env var as an opt-in convenience for contexts where proc visibility is acceptable (single-user VMs, CI runners). 3. **Replace `FORGEJO_TOKEN` with `FORGE_TOKEN_FILE` override only.** Instead of accepting a raw token in the environment, accept only a file path. This keeps the env-based override pattern without putting the token itself in the environment. Scripts that currently do `FORGEJO_TOKEN=xxx forge ...` would change to writing a temp file. 4. **Add a `FORGE_TOKEN_CMD` credential helper.** A command that prints the token to stdout, invoked on demand. Similar to git's `credential.helper` or AWS's `credential_process`. This is the most composable option but the heaviest to implement. The right answer depends on whether we consider proc-visible env vars an acceptable exposure surface for this tool's threat model.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
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#57
No description provided.