fix(core): never send a Mergify user token to GitHub - #1808
Conversation
|
This pull request is part of a Mergify stack:
|
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
56c3bb4 to
e5c6417
Compare
b78ede8 to
320f6ae
Compare
Revision history
|
e5c6417 to
8674722
Compare
320f6ae to
2d38845
Compare
8674722 to
7f19c7b
Compare
2d38845 to
003a947
Compare
003a947 to
dbdbefb
Compare
7f19c7b to
d255dfd
Compare
|
@sileht this pull request is now in conflict 😩 |
a87db99 to
5ca96d3
Compare
There was a problem hiding this comment.
🟡 Changes recommended
The gh auth token fallback can still send a mut_ credential, and related documentation is incomplete.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Updates GitHub token resolution to avoid sending Mergify mut_ tokens and improves diagnostics, tests, and documentation.
Changes:
- Filters Mergify tokens from environment credentials.
- Adds clearer failure diagnostics and regression tests.
- Documents the token-handling behavior.
File summaries
| File | Summary |
|---|---|
README.md |
Documents token filtering, but does not cover both environment variables. |
crates/mergify-core/src/auth.rs |
Filters environment tokens and adds tests; the gh auth token fallback and resolver documentation still need updates. |
Review details
Suppressed comments (1)
crates/mergify-core/src/auth.rs:253
- This changes the resolver contract, but the module-level
//!documentation still describesresolve_github_tokenas exactly the unfiltered--token → MERGIFY_TOKEN → GITHUB_TOKEN → gh auth tokenchain and says nothing is new. Update that contract documentation to mention that non-explicitmut_environment credentials are skipped (and theghfallback if the preceding issue is fixed), so the public resolver docs do not contradict this behavior.
// Which variables were skipped, in the order they were tried, so
// the failure below can name them. Both can carry a `mut_`
// value: somebody who pastes their `auth login` token into
// `GITHUB_TOKEN` — the variable GitHub Actions already exports —
// gets the same skip.
- Files reviewed: 2/2 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
`MERGIFY_TOKEN` is the natural place to put the credential `mergify auth login` mints, and `stack` reads that same variable for its GitHub calls. A user who exports one would get `401 Bad credentials` from api.github.com, which says nothing about why. Skip it there. The cost is nothing: `mut_` is Mergify's prefix, registered with GitHub's own secret scanning, so a value carrying it was never going to authenticate against GitHub. `stack` falls through to `GITHUB_TOKEN` or `gh auth token` as it would have if the variable were unset. `gh auth token` needs the same check, and not only because somebody could have logged `gh` in with the wrong string: it prints `$GITHUB_TOKEN` when that variable is set, so skipping the variable does not, on its own, keep its value out of the request -- the fallback hands the same token straight back. That is the GitHub Actions case, where `GITHUB_TOKEN` is exported for you. So the check is on the value, wherever it came from. The failure says so, and names the variable it actually skipped. Telling someone to set `MERGIFY_TOKEN` when they have set it, and it was skipped for a reason visible only at `-vv`, is the worst version of this message -- and `GITHUB_TOKEN` can carry a `mut_` value too, since it is the variable GitHub Actions already exports and therefore at least as likely a place to paste an `auth login` token. There the old wording named `MERGIFY_TOKEN`, which is unset, and prescribed `GITHUB_TOKEN`, which is the broken one. Where `gh` is one of the sources skipped it is installed and authenticated already, so the message asks for a login to a GitHub account rather than an install. An explicit `--token` is not second-guessed. The user aimed it at this command, and quietly using a different credential instead would be the more surprising failure of the two. This is a failure mode the rest of this stack creates -- there was no reason to hold a `mut_` token before it -- which is why it lands here rather than as a separate ticket. Fixes MRGFY-8703 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Change-Id: If3c422baf7dde5e912971015b991046ccbc886eb
5ca96d3 to
b93aca3
Compare
Merge Queue Status
This pull request spent 13 seconds in the queue, including 1 second running CI. Required conditions to merge
|
`key_for` files `https://host/api` and `https://host/api/` under one entry, and its comment justified that by saying every request "replaces the base path outright". That stopped being true with #1819, which made `Client::join()` append a request path to the base's path prefix instead of replacing it, so GitHub Enterprise's `/api/v3` survives. The conclusion did not change, only the reason. `join()` now gives the base a trailing slash and strips the path's leading one, so both spellings send `/v1/user` to `https://host/api/v1/user`, and one credential entry for both is still right. The comment now says that. Comment only. Fixes MRGFY-8703 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Depends-On: #1808
MERGIFY_TOKENis the natural place to put the credentialmergify auth loginmints, andstackreads that same variable for itsGitHub calls. A user who exports one would get
401 Bad credentialsfromapi.github.com, which says nothing about why.
Skip it there. The cost is nothing:
mut_is Mergify's prefix,registered with GitHub's own secret scanning, so a value carrying it was
never going to authenticate against GitHub.
stackfalls through toGITHUB_TOKENorgh auth tokenas it would have if the variable wereunset.
gh auth tokenneeds the same check, and not only because somebodycould have logged
ghin with the wrong string: it prints$GITHUB_TOKENwhen that variable is set, so skipping the variabledoes not, on its own, keep its value out of the request -- the
fallback hands the same token straight back. That is the GitHub
Actions case, where
GITHUB_TOKENis exported for you. So the checkis on the value, wherever it came from.
The failure says so, and names the variable it actually skipped.
Telling someone to set
MERGIFY_TOKENwhen they have set it, and itwas skipped for a reason visible only at
-vv, is the worst versionof this message -- and
GITHUB_TOKENcan carry amut_value too,since it is the variable GitHub Actions already exports and therefore
at least as likely a place to paste an
auth logintoken. There theold wording named
MERGIFY_TOKEN, which is unset, and prescribedGITHUB_TOKEN, which is the broken one. Whereghis one of thesources skipped it is installed and authenticated already, so the
message asks for a login to a GitHub account rather than an install.
An explicit
--tokenis not second-guessed. The user aimed it at thiscommand, and quietly using a different credential instead would be the
more surprising failure of the two.
This is a failure mode the rest of this stack creates -- there was no
reason to hold a
mut_token before it -- which is why it lands hererather than as a separate ticket.
Fixes MRGFY-8703
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com