Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

A stripped stamp re-adopted on a different secret-store backend still loses what only the old backend held

Đang mở
  • Có gì không ổn?
#2,672 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug v2

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:

  1. 2.10 saves on the keychain under namespace ns1, including a confidential DCR client's client_secret.
  2. A ≤ 2.9.x save strips the stamp.
  3. The next 2.10 run lands on a different backend (locked keychain → secrets.json, or the memory fallback). It re-adopts under ns2. The carry-over reads ns1 from that backend, finds nothing, and the stamp commits. The keychain's ns1 record is correctly kept, because only a keychain run purges keychain records.
  4. A later keychain run sees a stamped file (ns2), which never falls back, and purges ns1 from 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 ns2 may be one the user deliberately cleared under ns2 (a logout, a policy downgrade). Carrying ns1's value back would resurrect it. This is why a stamped file never falls back.
  • The store holds a client_secret without the client_id it belongs to. If ns2 re-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.

Ngôn ngữ chính
TypeScript
Star
11.1k
Fork
1.5k
Merge trung bình
4 giờ 28 phút
Pull request đã merge (30 ngày)
151

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/inspector

Tất cả issue của modelcontextprotocol/inspector

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.