Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

A normal secret-store read still pairs a DCR client secret with a different client after a repeated hand-off (owner stamp unchecked on read)

已关闭
  • 哪里不对？
#2,768 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@cliffhall 已经在做这个了。

开始于 2026年10月25日。

  • #2792 来自 @cliffhall —— 已合并

评估

难度
4/5
预计耗时
3-5 天
新手友好度
56/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
authentication, security

调研方向

Start with absorbFileSecretsIntoKeyring and the ordinary read path in core/auth/node, then read the existing repeated hand-off test in clients/web/src/test/integration/auth/node/oauth-secrets-namespace.test.ts. Add a regression case for a valid owner stamp naming a different client_id; done means the read treats that secret as absent while unstamped values retain current behavior. The issue describes a narrow authentication path that needs familiarity with the DCR secret handling.

由索引模型根据 Issue 内容生成。

描述

bug v2

Found during the v2.12.0 release smoke (#2764), while verifying #2734 / PR #2739.

Problem

#2739 adds an owner stamp (…#owner, holding a client_id plus a MAC keyed by the value) beside each DCR client_secret / registration token. It also makes carries trust only that stamp. The ordinary read path does not consult the stamp, and the file-to-keychain hand-off (absorbFileSecretsIntoKeyring) is unchanged by design. So after the #2734 sequence, the live keychain namespace already pairs one client's secret with another client before any re-adoption or carry runs.

  1. Client A is registered, and its secret is absorbed into the keychain.
  2. The state file re-registers client B under the same namespace.
  3. The next hand-off keeps the existing keychain value (A's secret, whose stamp correctly names client-a).
  4. A normal read of the stamped file on the keychain now returns:
{"client_id":"client-b","client_secret":"secret-a"}

The output is the same on c1365148 (before #2739) and on the v2.12.0 merge tree. That makes it pre-existing and outside #2739's stated scope, not a regression. #2739's carry correctly refuses this pairing; the read does not.

Impact

A confidential DCR client in this state authenticates with the wrong secret (an invalid_client at the token endpoint) until it re-registers. It requires a repeated hand-off with a re-registration in between, which is a narrow path, but the failure is silent until the token request.

Expected

On read, a DCR secret whose stamp vouches for the value (MAC valid) but names a different client_id than the one the state file holds is treated as absent, not paired. The read then behaves as it would for a client with no stored secret. A value with no valid stamp (legacy, or rewritten by an older Inspector) keeps today's behavior, matching #2739's "purged as before, not guessed at" stance on unstamped values.

Evidence

Driven with a probe calling the real core/auth/node functions on real files (oauth.json, the namespace ledger, secrets.json) against a file-backed fake of @napi-rs/keyring, with no real keychain touched. It staged the #2734 repeated-hand-off repro from clients/web/src/test/integration/auth/node/oauth-secrets-namespace.test.ts. A regression test for the fix belongs in that integration file.

主要语言
TypeScript
星标
11.2k
派生
1.6k
平均合并
4 小时 56 分钟
30 天内合并 PR
155

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/inspector 的其他 Issue

查看 modelcontextprotocol/inspector 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。