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

[ian-flores]

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.