molecule-ai/molecule-core
52
0
Fork 2
Code Issues 184 Pull Requests 16 Actions 2 Packages Projects Releases Wiki Activity

fix(ci)(security): pipe RFC_324_TEAM_READ_TOKEN to curl via -K/stdin instead of -H argv (token-in-process-table) #541

New Issue
Closed
opened 2026-05-11 18:48:10 +00:00 by core-devops · 0 comments
core-devops commented 2026-05-11 18:48:10 +00:00
Member
Copy Link
Copy Source

Context

Follow-up to PR #535 (RFC#324 Step 1 of 5 — qa-review + security-review workflow add). hongming-pc review #1421 nit 4.

In .gitea/workflows/qa-review.yml, .gitea/workflows/security-review.yml, and .gitea/scripts/review-check.sh, the Gitea API call shape is:

curl -sS -o "$PR_JSON" -w '%{http_code}' \
  -H "Authorization: token ${GITEA_TOKEN}" \
  "${API}/repos/${OWNER}/${NAME}/pulls/${PR_NUMBER}"

The expanded Authorization: token <secret> ends up in curl's argv — visible to any other process on the runner via /proc/<pid>/cmdline or ps -ef.

Why it matters here specifically

For most workflow tokens this is low-impact: GITHUB_TOKEN is ephemeral and scoped to a single workflow run. But RFC_324_TEAM_READ_TOKEN is a long-lived org-secret (provisioning tracked in internal#325) — an org-Owners-tier identity that's a member of both qa and security teams. Leak window from process-table is the entire token lifetime, not a single workflow run.

A co-tenant step (or — under pull_request_target — a future malicious step we forgot to guard) running ps -e -o args on the same runner during the curl invocation reads the secret. The runner is single-tenant per-job today, but defence-in-depth says don't put long-lived secrets in argv.

Fix options

Option 1 (preferred) — curl -K <(...) config-file via process-substitution.

curl_authed() {
  local url="$1" outfile="$2"
  curl -sS -o "$outfile" -w '%{http_code}' \
    -K <(printf 'header = "Authorization: token %s"\n' "$GITEA_TOKEN") \
    "$url"
}

The token lives in a transient FIFO file descriptor — never on the curl command line. bash only.

Option 2 — safe_curl helper per internal#178. If that helper has shipped, reuse it. Same effect, more shared maintenance.

Option 3 — --config - (stdin). printf '...' | curl -K - .... Portable to non-bash shells (sh) but trickier with the rest of the -sS -o ... -w ... flags; need to assemble the full config on stdin.

Recommendation: Option 1 unless safe_curl (option 2) is already available — it covers all six curl call sites in review-check.sh with one helper.

Acceptance

  • Introduce curl_authed() helper at the top of review-check.sh (or a sourced .gitea/scripts/lib/safe_curl.sh).
  • Replace all -H "Authorization: token ${GITEA_TOKEN}" invocations with curl_authed.
  • Same fix in the Privilege check step of qa-review.yml and security-review.yml (note: per RFC#324 v1.3, that step is now informational-only, but still shouldn't leak the token).
  • Bats test (per #540) verifies the helper still passes a syntactically valid Authorization header (mock-curl asserts on a config-file argument).

Tier

tier:medium — defence-in-depth on a long-lived org-secret. Not blocking the workflow's correctness, but should land before RFC_324_TEAM_READ_TOKEN is provisioned (internal#325) and the workflows start carrying live load.

Owner

core-security (token-handling owner) or core-devops (workflow author). Either persona.

Cross-refs

  • PR #535 (RFC#324 Step 1 workflow-add)
  • hongming-pc review #1421 nit 4
  • internal#325 — RFC_324_TEAM_READ_TOKEN provisioning
  • internal#178 — safe_curl helper origin (if already shipped, link the path)
## Context Follow-up to PR #535 (RFC#324 Step 1 of 5 — `qa-review` + `security-review` workflow add). hongming-pc review #1421 nit 4. In `.gitea/workflows/qa-review.yml`, `.gitea/workflows/security-review.yml`, and `.gitea/scripts/review-check.sh`, the Gitea API call shape is: ```bash curl -sS -o "$PR_JSON" -w '%{http_code}' \ -H "Authorization: token ${GITEA_TOKEN}" \ "${API}/repos/${OWNER}/${NAME}/pulls/${PR_NUMBER}" ``` The expanded `Authorization: token <secret>` ends up in `curl`'s **argv** — visible to any other process on the runner via `/proc/<pid>/cmdline` or `ps -ef`. ## Why it matters here specifically For most workflow tokens this is low-impact: `GITHUB_TOKEN` is ephemeral and scoped to a single workflow run. **But `RFC_324_TEAM_READ_TOKEN` is a long-lived org-secret** (provisioning tracked in `internal#325`) — an org-Owners-tier identity that's a member of both `qa` and `security` teams. Leak window from process-table is the entire token lifetime, not a single workflow run. A co-tenant step (or — under `pull_request_target` — a future malicious step we forgot to guard) running `ps -e -o args` on the same runner during the curl invocation reads the secret. The runner is single-tenant per-job today, but defence-in-depth says don't put long-lived secrets in argv. ## Fix options **Option 1 (preferred) — `curl -K <(...)` config-file via process-substitution.** ```bash curl_authed() { local url="$1" outfile="$2" curl -sS -o "$outfile" -w '%{http_code}' \ -K <(printf 'header = "Authorization: token %s"\n' "$GITEA_TOKEN") \ "$url" } ``` The token lives in a transient FIFO file descriptor — never on the curl command line. `bash` only. **Option 2 — `safe_curl` helper per `internal#178`.** If that helper has shipped, reuse it. Same effect, more shared maintenance. **Option 3 — `--config -` (stdin).** `printf '...' | curl -K - ...`. Portable to non-bash shells (`sh`) but trickier with the rest of the `-sS -o ... -w ...` flags; need to assemble the full config on stdin. Recommendation: **Option 1** unless `safe_curl` (option 2) is already available — it covers all six curl call sites in `review-check.sh` with one helper. ## Acceptance - [ ] Introduce `curl_authed()` helper at the top of `review-check.sh` (or a sourced `.gitea/scripts/lib/safe_curl.sh`). - [ ] Replace all `-H "Authorization: token ${GITEA_TOKEN}"` invocations with `curl_authed`. - [ ] Same fix in the `Privilege check` step of `qa-review.yml` and `security-review.yml` (note: per RFC#324 v1.3, that step is now informational-only, but still shouldn't leak the token). - [ ] Bats test (per #540) verifies the helper still passes a syntactically valid Authorization header (mock-curl asserts on a config-file argument). ## Tier `tier:medium` — defence-in-depth on a long-lived org-secret. Not blocking the workflow's correctness, but should land before `RFC_324_TEAM_READ_TOKEN` is provisioned (`internal#325`) and the workflows start carrying live load. ## Owner `core-security` (token-handling owner) or `core-devops` (workflow author). Either persona. ## Cross-refs - PR #535 (RFC#324 Step 1 workflow-add) - hongming-pc review #1421 nit 4 - `internal#325` — `RFC_324_TEAM_READ_TOKEN` provisioning - `internal#178` — `safe_curl` helper origin (if already shipped, link the path)
core-devops added the securitytier:medium labels 2026-05-11 18:48:10 +00:00
core-devops self-assigned this 2026-05-11 19:10:10 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label security tier:medium
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees core-devops
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#541
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?