fix(platformctl): apply.py silent fallback bypasses Infisical when both PAT sources present #272

New issue

Closed

opened 2026-05-14 09:06:23 +02:00 by codex · 0 comments

codex commented

2026-05-14 09:06:23 +02:00

Collaborator

Context

During the 2026-05-14 Infisical Token Auth close-out dispatch, Codex audited control-plane/platformctl/apply.py before triggering the requested matrix-well-known no-op smoke.

The code currently resolves Forgejo credentials in this order:

explicit token argument
direct runner env PAT: PLATFORMCTL_FORGEJO_TOKEN or FORGEJO_TOKEN_CODEX
Infisical Token Auth file via PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE

This means that during the required 7-day soak, where the direct PAT must intentionally remain in the runner env as fallback, platformctl apply silently prefers the direct PAT and never exercises Infisical.

Evidence

control-plane/platformctl/apply.py:

def _forgejo_token(explicit: str | None = None) -> str | None:
    if explicit:
        return explicit
    direct = os.environ.get("PLATFORMCTL_FORGEJO_TOKEN") or os.environ.get("FORGEJO_TOKEN_CODEX")
    if direct:
        return direct
    return _forgejo_token_from_infisical()

_forgejo_token_from_infisical() exists and reads:

token file: PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE
endpoint helper: infisical.read_secret(...)
default secret path: /home-platform/forgejo_accounts
default key: p+codex@durlej.me

But it is never reached when direct PAT env is still present.

Why this blocks close-out

Task 4 of the Infisical close-out dispatch requires proving that the smoke resolved the Forgejo PAT via Infisical, not the direct PAT fallback. With the current order, a green smoke would be misleading: it would likely prove only that the old direct PAT still works.

Required behavior

Prefer Infisical when PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE is configured, then fall back to direct PAT only if Infisical is absent or explicitly fails in a logged way.

Suggested order:

explicit token argument
Infisical Token Auth file when configured
direct runner env PAT fallback
fail with actionable message

Also add a non-secret log marker so workflow logs can prove which path was used:

forgejo_token_source=infisical-token-auth
forgejo_token_source=direct-env-fallback

Acceptance criteria

Unit tests cover source precedence: Infisical beats direct PAT when both are configured.
Unit tests cover direct fallback when no Infisical token file is configured.
Workflow logs expose a non-secret source marker.
No token values are printed.
After fix merges, rerun the Infisical close-out smoke for matrix-well-known.

References

Issue #265 — Infisical Token Auth migration
Issue #142 — RS2000 cutover lane
Dispatch: Infisical Token Auth integration close-out, 2026-05-14

## Context During the 2026-05-14 Infisical Token Auth close-out dispatch, Codex audited `control-plane/platformctl/apply.py` before triggering the requested `matrix-well-known` no-op smoke. The code currently resolves Forgejo credentials in this order: 1. explicit token argument 2. direct runner env PAT: `PLATFORMCTL_FORGEJO_TOKEN` or `FORGEJO_TOKEN_CODEX` 3. Infisical Token Auth file via `PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE` This means that during the required 7-day soak, where the direct PAT must intentionally remain in the runner env as fallback, `platformctl apply` silently prefers the direct PAT and never exercises Infisical. ## Evidence `control-plane/platformctl/apply.py`: ```python def _forgejo_token(explicit: str | None = None) -> str | None: if explicit: return explicit direct = os.environ.get("PLATFORMCTL_FORGEJO_TOKEN") or os.environ.get("FORGEJO_TOKEN_CODEX") if direct: return direct return _forgejo_token_from_infisical() ``` `_forgejo_token_from_infisical()` exists and reads: - token file: `PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE` - endpoint helper: `infisical.read_secret(...)` - default secret path: `/home-platform/forgejo_accounts` - default key: `p+codex@durlej.me` But it is never reached when direct PAT env is still present. ## Why this blocks close-out Task 4 of the Infisical close-out dispatch requires proving that the smoke resolved the Forgejo PAT via Infisical, not the direct PAT fallback. With the current order, a green smoke would be misleading: it would likely prove only that the old direct PAT still works. ## Required behavior Prefer Infisical when `PLATFORMCTL_INFISICAL_TOKEN_AUTH_FILE` is configured, then fall back to direct PAT only if Infisical is absent or explicitly fails in a logged way. Suggested order: 1. explicit token argument 2. Infisical Token Auth file when configured 3. direct runner env PAT fallback 4. fail with actionable message Also add a non-secret log marker so workflow logs can prove which path was used: - `forgejo_token_source=infisical-token-auth` - `forgejo_token_source=direct-env-fallback` ## Acceptance criteria - Unit tests cover source precedence: Infisical beats direct PAT when both are configured. - Unit tests cover direct fallback when no Infisical token file is configured. - Workflow logs expose a non-secret source marker. - No token values are printed. - After fix merges, rerun the Infisical close-out smoke for `matrix-well-known`. ## References - Issue #265 — Infisical Token Auth migration - Issue #142 — RS2000 cutover lane - Dispatch: Infisical Token Auth integration close-out, 2026-05-14

codex added the

owner-attention

class/security-sensitive

labels

2026-05-14 09:06:23 +02:00

codex referenced this issue

2026-05-14 09:13:15 +02:00

[coordination-lane] Cutover Flight Phase 2: v2 catalog to gate #142

codex referenced this issue from a pull request that will close it,

2026-05-14 09:20:10 +02:00

fix(platformctl): prefer Infisical token auth before direct PAT #273

codex referenced this issue