Skip to content

security: scope keychain references to provider ownership - #416

Open
luvs01 wants to merge 20 commits into
Devfrom
codex/fix-keychain-reference-vulnerability
Open

security: scope keychain references to provider ownership#416
luvs01 wants to merge 20 commits into
Devfrom
codex/fix-keychain-reference-vulnerability

Conversation

@luvs01

@luvs01 luvs01 commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Motivation

  • Keychain references were globally addressable (keychain:<account>) and could be resolved for any provider, enabling a management-token holder to bind another provider to a victim's key and exfiltrate the secret. The intent is to ensure a provider may only resolve keychain accounts that belong to it.

Description

  • Add keychainReferenceBelongsToProvider and require provider ownership in the resolver by changing resolveProviderApiKey to accept a providerName and return a credential only when the keychain: account is the provider or one of its pool slots. (src/providers/key-store.ts)
  • Prevent cross-provider restores by refusing restoreProviderKeyFromKeychain when a provider contains keychain references not owned by that provider. (src/providers/key-store.ts)
  • Propagate the provider identity into all call-sites that resolve API keys so key resolution is provider-scoped; the change updates call sites in router, OAuth model discovery, catalog/observation, quota probes, image/video bridge, Lab routing, OpenAI-sidecar, and compact-response paths to pass the provider name into resolveProviderApiKey. (src/router.ts, src/oauth/index.ts, src/codex/catalog/provider-fetch.ts, src/providers/quota.ts, src/images/plan.ts, src/lib/lab-live-route-production.ts, src/providers/openai-sidecar.ts, src/server/responses/compact.ts)
  • Add regression tests covering correct same-provider resolution, fail-closed behavior for cross-provider references, that routed clones do not leak victim secrets to attacker-named providers, and that restore rejects foreign references. (tests/provider-key-store.test.ts)

Testing

  • Ran the focused unit test bun test tests/provider-key-store.test.ts, which passed (7 tests).
  • Ran type checking with bun run typecheck, which completed without errors.
  • Ran bun run privacy:scan, which passed.
  • Ran the full test script (bun run test) during verification; it completed but reported unrelated, environment-sensitive failures (Lab sandbox/network proxy and timing/process-sensitive tests) that are outside the changed key-store surface and pre-existing in CI-like environments. All focused checks for the key-store change passed.

Codex Task

lidge-jun and others added 20 commits August 25, 2026 10:36
release: promote dev into main for v2.32.1
# Conflicts:
#	package.json
[WRONG BRANCH] merge dev into main for the v2.33.0 release
Promotes the dev integration line onto main. The resulting tree is byte-identical
to origin/dev, including package.json at 2.34.0.

The package.json conflict is resolved to dev's side, NOT to main's stale 2.33.0.
Earlier promotions (lidge-jun#2553, lidge-jun#2507) kept the target's version so the release bump
would land on its own "release: vX.Y.Z" commit. That is no longer legal: this very
delta adds tests/release-version-line.test.ts, which fails when the in-tree version
sits behind the highest release tag. With v2.34.0-preview.20260827 now published,
2.33.0 orders behind it, so a promotion carrying the stale line turns CI red on
every shard that runs the suite.

The consequence for the release step is that scripts/release.ts skips the bump
(release.ts:568, currentVersion === version), so v2.34.0 gets tagged on this merge
commit rather than on a separate release commit. The workflow creates the tag itself
after publishing and validates expected-sha against the checked-out commit, so the
tag still names exactly the audited tree.
[WRONG BRANCH] promote dev onto main for v2.34.0
[WRONG BRANCH] promote dev onto main for v2.35.0
[WRONG BRANCH] promote dev onto main for v2.36.0
[WRONG BRANCH] promote dev to main for the v2.37.0 release
[WRONG BRANCH] promote dev onto main for v2.38.0
[WRONG BRANCH] promote dev onto main for v2.39.0
…rkflow call (lidge-jun#3262)

Both v2.40.0 release dispatches (33615174183 preview, 33615177849 main) died
at startup_failure: a workflow_call cannot grant its callee more than the
calling job holds, and dev-version-bump.yml's job declares contents+pull-
requests write. lidge-jun#3129 wired the call but never dispatched a release, so this
is its first live run. The caller job now declares exactly the callee's two
permissions; no other job in release.yml gains anything.

Co-authored-by: jun <jun@lidge.dev>
(cherry picked from commit 7ce0ba5)
…400-relfix

release: carry the release.yml permissions fix onto main for v2.40.0
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 3, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-03T06:15:07.230387Z 00a7947 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@coderabbitai

coderabbitai Bot commented Sep 3, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Team

Run ID: 0a02eef9-55da-4a1a-9021-31901d0e2ebe


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the bug Something isn't working label Sep 3, 2026
@github-actions github-actions Bot changed the title security: scope keychain references to provider ownership [WRONG BRANCH] security: scope keychain references to provider ownership Sep 3, 2026
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

✅ READY

  • all PR quality gates passed.

Hygiene

Deterministic PR hygiene checks passed.

@github-actions
github-actions Bot marked this pull request as draft September 3, 2026 06:13

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 00a7947592

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/images/plan.ts
Comment on lines +38 to +40
export function resolveXaiImageApiKey(provider: OcxProviderConfig, providerName = "xai"): string | undefined {
if (provider.authMode === "oauth") return undefined;
const apiKey = resolveProviderApiKey(provider.apiKey)?.trim();
const apiKey = resolveProviderApiKey(provider.apiKey, providerName)?.trim();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Pass the custom xAI provider name through relay auth

When the image bridge discovers a custom-named xAI provider, tryXaiImageRelay still calls resolveXaiImageAuthToken(found.provider) without found.name; that function consequently reaches this helper with the default name "xai". After storing the custom provider's key in the OS keychain, its reference is keychain:<custom-name>, so the new ownership check rejects it and every direct /v1/images/generations or /v1/images/edits request returns the missing-auth response, even though the synthetic image/video bridge paths correctly pass found.name. Accept and propagate the discovered provider name through resolveXaiImageAuthToken, and cover the custom-name/keychain relay case in tests/server-images.test.ts.

AGENTS.md reference: src/AGENTS.md:L10-L10

Useful? React with 👍 / 👎.

@luvs01 luvs01 changed the title [WRONG BRANCH] security: scope keychain references to provider ownership security: scope keychain references to provider ownership Sep 3, 2026
@luvs01
luvs01 changed the base branch from main to dev September 3, 2026 06:21
@github-actions
github-actions Bot marked this pull request as ready for review September 3, 2026 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

aardvark bug Something isn't working codex

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants