security: トークン取り扱いの機械的担保 — Debug redaction / bindings 非露出ガードテスト / legacy token 列の整理

[hitalin]

背景

同ドメインの Misskey マルチカラムクライアント onodai145/tsumugi（Tauri v2 + Rust + Svelte）とのアーキテクチャ比較で、トークン封じ込めの「機械的な担保」に差があることが分かった。

notedeck は AccountPublic（hasToken: boolean、src/bindings.ts:2285）でフロントへのトークン露出を型レベルで防げているが、tsumugi はさらに一段深く、**「漏れない設計」ではなく「漏れたら CI が落ちる仕組み」**まで持っている。

tsumugi 側の実装（参考）:

• api/client.rs — クライアント構造体の Debug 実装で token を <redacted> に伏せる（ログ・panic メッセージ経由の漏洩防止）
• lib.rs の generates_frontend_bindings テスト — 生成された TS bindings に token: フィールドが含まれないことを assert!(!ts.contains("token:")) で検証
• エラー型のコメントで「token 等の機微情報は含めない」を規約化

notedeck 側の現状ギャップ

1. Account が #[derive(Debug)] で token を素通し（notecli src/models.rs:17-29）。Drop での zeroize はあるが、{:?} でログに出せば平文で漏れる。AuthResult（models.rs:1045-1051）も同様。
2. bindings スナップショットテストは「陳腐化検知」のみ（src-tauri/tests/bindings_snapshot.rs）で、内容の不変条件（アカウントトークン非露出）を検証していない。将来誰か（未来の自分や AI エージェント含む）が Account をうっかり specta export しても CI は通ってしまう。
3. accounts.token TEXT NOT NULL 列が schema に残存（notecli migrations/V1__initial_schema.sql:8）。keychain 移行済み・clear_token()（db.rs:309）はあるが、平文トークンの受け皿が DB に残り続けている。

提案

• Account / AuthResult に手書き Debug 実装（token を <redacted> に）
• bindings_snapshot.rs に不変条件テストを追加: 生成 TS に raw トークンフィールドが出ないことを assert。CreatedApiToken.token（ローカル HTTP API 用・発行時 1 回のみ返す設計）は意図的な露出なので allowlist 化する
• マイグレーションで accounts.token 列を NULL 許容化 or 削除し、平文トークンの永続経路を閉じる（新規行が常に空であることの担保）

参考

tsumugi の該当実装: https://github.com/onodai145/tsumugi （src-tauri/src/api/client.rs, src-tauri/src/lib.rs の bindings テスト）

[hitalin]

進捗

• 1. Debug redaction → notecli PR https://github.com/hitalin/notecli/pull/32（`RawMiAuthResponse` も token を含むため対象に追加）
• 2. bindings 非露出ガードテスト → develop d8046d4。生成 TS の全型を走査し、CreatedApiToken のみ allowlist。allowlist を外すと実際に fail することを確認済み
• 3. accounts.token 列の整理 → 設計上の矛盾が見つかったため保留（下記）

3 が単純に実施できない理由

accounts.token 列は legacy の残骸ではなく、意図的な keychain フォールバックだった:

• notecli CLAUDE.md に「認証情報は keychain 優先、DB フォールバック」と規約として明記
• notedeck commands/auth.rs は「DB にはトークン込みで保存（キーチェーンのフォールバック）」というコメント付きで、keychain への store + 読み戻し検証が成功した場合のみ DB をクリアする
• get_credentials 系は keychain miss 時に DB トークンへフォールバックし、lazy migration する

さらに Linux の keychain バックエンドは linux_keyutils_keyring_store（カーネル keyutils）で、カーネルメモリ常駐のため再起動をまたいで永続しない。つまり Linux では:

• keychain store が成功して DB がクリアされると、再起動後は keychain も DB も空 → ログアウトされるはず（WSL2 で再起動後にログアウトされる現象があればこれが原因の可能性大）
• 列を削除すると、Linux でログインを永続させる手段が消える

選択肢

1. 列を「意図的なフォールバック」として明文化して現状維持 — 機械的担保は 1・2 で確保済み。この項目はスコープから外す
2. Linux バックエンドを永続ストア（secret-service / encrypted file 等）に変えた上で列を削除 — WSL2/ヘッドレスでは secret-service が無いことが多く、フォールバック問題は残る
3. DB 内トークンの暗号化保存 — 鍵の置き場所が keychain 以外に無いため、実効性は難読化程度

個人的には 1 を推奨（+ 上記の「Linux で再起動ごとにログアウトされるのでは」問題を別 issue として切り出して調査）。