A stripped stamp re-adopted on a different secret-store backend still loses what only the old backend held
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Read the linked issue #2630 and PR #2671, then trace the ledger and secret-store carry-over and purge paths described in this report. Reproduce the sequence with mixed versions and a backend switch, including a changed client registration. Done means a design prevents loss of secrets without restoring values deliberately cleared under the successor namespace.
由索引模型根据 Issue 内容生成。
描述
Problem
Follow-up to #2630 (PR #2671, raised in its Copilot review). #2671 carries an unstamped file's missing secrets over from the namespaces its ledger records before purging them. It reads those namespaces through the current run's secret store only. The ledger records entries per store location, so the carry-over has a gap when the backend changes in between:
- 2.10 saves on the keychain under namespace
ns1, including a confidential DCR client'sclient_secret. - A ≤ 2.9.x save strips the stamp.
- The next 2.10 run lands on a different backend (locked keychain →
secrets.json, or the memory fallback). It re-adopts underns2. The carry-over readsns1from that backend, finds nothing, and the stamp commits. The keychain'sns1record is correctly kept, because only a keychain run purges keychain records. - A later keychain run sees a stamped file (
ns2), which never falls back, and purgesns1from the keychain. That deletes the only copy of the secret.
Why it was not fixed in #2671
The obvious fix is to reconcile missing fields from a superseded namespace into the current, stamped namespace before purging it. That is unsafe as it stands:
- A field missing from
ns2may be one the user deliberately cleared underns2(a logout, a policy downgrade). Carryingns1's value back would resurrect it. This is why a stamped file never falls back. - The store holds a
client_secretwithout theclient_idit belongs to. Ifns2re-registered as a public client, a carried-over secret would be paired with the wrong client.
Expected
A design that tells "never carried, because the backend was absent" apart from "cleared since". For example, the ledger could record per location whether a namespace's contents were carried into its successor, and the purge could reconcile only namespaces that were never carried, for the entries the stamped file still indexes. Alternatively, defer the purge and accept the leak, with a warning. Needs both mixed versions and a backend switch between runs, so it is narrower than #2630.
- 主要语言
- TypeScript
- 星标
- 11.1k
- 派生
- 1.5k
- 平均合并
- 4 小时 14 分钟
- 30 天内合并 PR
- 162
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/inspector#2723 ·
维护者通常 1 天内回复
-
Modern subscriptions: a subscriptions/listen refused with HTTP 403 is retried eight times in silence未关闭bug v2
难度 4/5 3-5 天 新手友好度 30/100
modelcontextprotocol/inspector#2722 · 1 条评论 ·
维护者通常 1 天内回复
-
bug v2
难度 3/5 1-2 天 新手友好度 50/100
modelcontextprotocol/inspector#2721 · 2 条评论 ·
维护者通常 1 天内回复
-
bug v2
难度 3/5 半天 新手友好度 62/100
modelcontextprotocol/inspector#2719 ·
维护者通常 1 天内回复
-
chore v2
难度 4/5 3-5 天 新手友好度 48/100
modelcontextprotocol/inspector#2715 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
one-zero-eight/apply-bot#39 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
bigbluebutton/bbb-ui-components-react#108 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
high priority
难度 2/5 1-3 小时 新手友好度 62/100
CI-CMG/deep-sea-corals-exb#84 · 1 条评论 ·