Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Feature] Keep credentials out of shareable VIP output: redact the auth cache and add a bundle command

オープン
  • 何か問題がありますか？
#620 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

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

@ian-flores がすでに取り組んでいます。

2026年10月21日 から。

  • #793 @ian-flores による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
cli, security

調査の方向性

src/vip/auth.py から始め、特に auth_cache_path()、689-697 行目のキャッシュ書き込みコード、_load_cached_auth()、および auth.py:238 の matches チェックを確認してください。キャッシュとバンドルの設計を選ぶ前に、既存の CLI サブコマンドと README.md/docs のカバレッジを確認してください。共有出力によって認証情報が露出せず、バンドルに credential selftest を備えた許可リスト化されたメンバー集合があり、feature が完了するまでユーザーに警告が表示されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement

VIP writes live credentials into its working directory, and that directory is exactly what users are asked to hand over when something goes wrong. A support interaction that began with "here is the whole VIP output" arrived with .vip-auth-cache.json and .vip-auth-cache.meta.json in the archive. Nothing about that was user error: the files are dotfiles in the invocation directory, there is no command that produces a shareable subset, and no documentation says they should be excluded.

What is in those files

.vip-auth-cache.meta.json holds a Connect API key in cleartext (src/vip/auth.py:689-697):

meta = {
    "api_key": session.api_key,
    "key_name": session.key_name,
    "connect_url": session._connect_url,
    "requested_connect_url": session._requested_connect_url or session._connect_url,
    "workbench_url": session._workbench_url,
}
meta_path.write_text(json.dumps(meta))
os.chmod(meta_path, 0o600)

.vip-auth-cache.json is a full Playwright storage state, and it is the more sensitive of the two. Per the docstring at src/vip/auth.py:342, the auth flow "deliberately visits the IdP and Connect as well as Workbench -- so this file holds their cookies too." That means a shared archive can carry a live IdP session cookie, which is broader than any single product's API key. Worth stating explicitly because it is easy to check the meta file, see api_key: null on a password or headless deployment, and conclude nothing sensitive was shared — the storage state says otherwise, and refresh_auth_cache_from_storage_state exists precisely to keep those cookies live across runs.

Both files land in Path.cwd() (auth_cache_path(), src/vip/auth.py:326-341). The only protections today are 0600 permissions and .gitignore entries, and neither survives zip -r.

Why the existing mitigations do not cover this

#223 fixed a different surface — API keys and passwords appearing in test failure output via config dataclass reprs. The on-disk auth cache was not part of that change, and the credential there is a real minted key with a real TTL rather than an echoed config value.

There is also no command that packages results for sharing. The subcommands today are version, auth mint, verify, cleanup, install, uninstall, report, status, and scaffold. Users who need to send output to someone else have no option but to archive the directory by hand and hope they know which files to leave out.

Proposal

Two complementary pieces, in the order they reduce risk:

  1. Stop writing the secret where it does not need to be one. The API key in the meta file exists so a later run can reuse the session and so cleanup can delete the key it minted. Neither requires the key in plaintext next to the report — options include storing only the key name plus a reference, moving the cache under a user-scoped directory outside the reporting tree, or encrypting the value at rest. Whichever is chosen, _load_cached_auth (src/vip/auth.py:488-510) and the matches check (auth.py:238) are the consumers to keep working.

  2. Add a command that produces a shareable archive — vip bundle or similar — that collects the report artifacts and diagnostic context and excludes the auth cache and anything else credential-bearing by construction, rather than relying on the user to prune. An allowlist of what goes in beats a denylist of what stays out, so a future artifact does not leak by default.

Until either lands, docs/ should say plainly that the auth cache holds live session material and must not be shared. Right now neither README.md nor anything under docs/ mentions these files at all.

Note for whoever picks this up

If a bundle command is built, treat "does the archive contain a credential" as a selftest and not a review checklist item — assert against the archive's actual member list, so adding a new artifact to the output directory cannot silently start including it.

主要言語
Python
スター
8
フォーク
1
平均マージ
2日 2時間
マージ済み PR（30日）
33

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

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

posit-dev/vip のほかの issue

posit-dev/vip の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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