Uh oh!
There was an error while loading. Please reload this page.
fix(auth): isolate unsigned macOS keychain entries - #201
Conversation
Prevent local and unsigned macOS builds from writing to the release keychain namespace so developer builds do not trigger prompts or contaminate release credentials.
🦋 Changeset detectedLatest commit: 3b2c8ee The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughThis pull request introduces macOS-specific keychain service isolation to prevent local unsigned builds from accessing the release keychain namespace. The changes add a new Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes DetailsThe changes span four files with mixed complexity. The test additions are straightforward and homogeneous, following standard patterns. The credential-store modifications introduce new logic for parsing codesign output and managing service resolution through caching, requiring understanding of the signing detection heuristics and how they integrate with keyring operations. The integration updates are simple. Overall scope is contained and focused on a specific macOS keychain behavior. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Uh oh!
There was an error while loading. Please reload this page.
Summary
On macOS, local and unsigned CLI builds were writing OAuth tokens under the same Keychain service name (
clerk-cli) as the signed release binary. macOS binds Keychain item ACLs to the code signature of the writer, so a later read from a differently signed (or unsigned) binary triggers a login-password prompt, and an accepted prompt grants that build permanent access to the release credential entry.Net effect: running a locally compiled
clerk(viabun run build:compile,bun run src/cli.ts, or a Bun-launched script) after a signed release login would either pop a password prompt or silently contaminate the release Keychain entry with a dev-build ACL.Fix
clerk-cliKeychain service for binaries that codesign-verify as an official release:TeamIdentifier=L8SD6SB282andIdentifier=clerk, withCLI_VERSIONpopulated (i.e. built by the release workflow, not0.0.0-dev).bun runfrom source, non-Clerk signatures) to a newclerk-cli-devservice. Linux and Windows paths are unchanged.isReleaseSignedMacosBinary) is a pure function over thecodesign -dvvvoutput +CLI_VERSION, so it is covered by unit tests without shelling out. The per-process lookup is memoized in a promise so we runcodesignat most once per CLI run.Existing release credentials are not migrated. A developer who had previously approved a prompt will find their dev logins now live in
clerk-cli-dev; the releaseclerkkeeps usingclerk-clias before.Test plan
bun test packages/cli-core/src/lib/credential-store-signing.test.ts(new classifier: dev/unversioned, release, non-Clerk signer, mismatched identifier)bun test packages/cli-core/src/lib/credential-store.test.tsbun run format:check,bun run lint,bun run typecheck,bun run testclerk whoami, confirm no password prompt and--verbosereports theclerk-cli-devservice; then run the signed releaseclerk whoamiand confirm it still reads fromclerk-cli.