Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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.1k
フォーク
1.6k
平均マージ
5時間 29分
マージ済み PR（30日）
158

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/inspector のほかの issue

modelcontextprotocol/inspector の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。