Add create-github-app-token plugin implementation - #1
Conversation
Amp-Thread-ID: https://ampcode.com/threads/T-01a0277c-8ac1-77fc-91b8-f1fc859fe02f Co-authored-by: Lachlan Donald <lachlan@buildkite.com>
![buildsworth-bk-app[bot]](https://avatars.githubusercontent.com/in/3010600?s=60&v=4){kind=small}
There was a problem hiding this comment.
The preferred client-ID path rejects the identifier format GitHub now issues for newly created Apps; details inline.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 19610, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-5.6-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.
| client_id="$(plugin_indirect_value "$app_id_env" app-id-env)" || return | ||
| fi | ||
| [[ -n "$client_id" ]] || client_id="$(plugin_config app-id)" | ||
| [[ "$client_id" =~ ^(Iv1\.[A-Fa-f0-9]+|[0-9]+)$ ]] || { |
There was a problem hiding this comment.
Blocking: This accepts only legacy Iv1.<hex> client IDs, while newly created GitHub Apps receive opaque IDs such as Iv23li.... Those IDs are the preferred issuer documented by this plugin, but every such configuration fails here before JWT creation. Please treat client IDs as opaque non-empty values (while retaining numeric App-ID support) and cover the current format in a regression test.
There was a problem hiding this comment.
Still open — the current validation still only accepts Iv1.<hex> or numeric IDs, so opaque client IDs such as Iv23li... are rejected before JWT creation.
Amp-Thread-ID: https://ampcode.com/threads/T-01a0277c-8ac1-77fc-91b8-f1fc859fe02f Co-authored-by: Lachlan Donald <lachlan@buildkite.com>
There was a problem hiding this comment.
The previous blocker is still open; this pass also found one command-environment side effect, called out inline.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 19628, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
| local client_id client_id_env app_id_env private_key private_key_env private_key_secret | ||
| local installation_id installation_id_env output_variable skip_revoke jwt permissions payload token | ||
| local response state_dir | ||
| umask 077 |
There was a problem hiding this comment.
Blocking: Buildkite sources hook scripts into the job shell, so this changes the command's umask from the agent's value to 077 and never restores it. Every file or directory the user's command creates is therefore restricted (for example, 0666 becomes 0600), which can break shared workspaces and artifacts. Please preserve and restore the existing umask on every exit, or scope the restrictive mask to the sensitive file writes.
2 participants
Why
Buildkite users need a first-party equivalent to
actions/create-github-app-tokenthat can securely create short-lived GitHub App installation tokens without embedding private keys in pipeline configuration.What
pre-exitby default, with fail-closed handling and cleanup for temporary key and token state