Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#620 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ian-flores ci sta già lavorando.

Dal 21/10/2026.

  • #793 di @ian-flores — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
cli, security

Direzione di ricerca

Inizia da src/vip/auth.py, in particolare da auth_cache_path(), dal codice di scrittura della cache alle righe 689-697, da _load_cached_auth() e dal controllo di matches in auth.py:238. Esamina i sottocomandi CLI esistenti e la copertura di README.md/docs prima di scegliere il design della cache e del bundle. Il lavoro è completato quando le credenziali non sono esposte dall’output condiviso, il bundle dispone di un insieme di membri consentiti tramite allowlist con un credential selftest e gli utenti vengono avvisati finché la funzionalità non è completa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
8
Fork
1
Merge medio
2g 8h
PR unite (30g)
29

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di posit-dev/vip

Tutte le issue di posit-dev/vip

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.