Encrypted env blob support for varlock run + generated language modules

Aperta
  • Qualcosa non va?
#863 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
go, php, python, rust, typescript
Ambito
backend, security

Direzione di ricerca

Start with the generated language loaders, CodeGenContext, varlock run blob injection, and the existing runtime/crypto helpers; then read smoke-tests/tests/lang-modules.test.ts and the four language module pages. Add conditional AES-256-GCM decryption for opted-in schemas, with explicit version handling and shared test vectors. Done means encrypted blob injection works in the compile-run suite for all four languages and the docs explain the key's limits and fallback for stale generated files.

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

Descrizione

Follow-up to #849, which ships generated env modules for Python/Rust/Go/PHP whose loaders parse the injected __VARLOCK_ENV blob. Today those loaders reject an encrypted blob with a clear error, and varlock run always injects the blob as plaintext — @encryptInjectedEnv only takes effect in the JS auto-load path and build-output integrations.

Goal

Extend the "no plaintext secrets in the process environment" posture (currently JS-only via @disableProcessEnvInjection + @encryptInjectedEnv) to every language with a generated module:

varlock run --inject blob + @encryptInjectedEnv → nothing in the child's environment is plaintext.

This hardens against accidental-exposure classes: APM/error-reporter env snapshots, env dumps in CI logs, grandchild env inheritance, log scrapers. The blob is the worst offender in such dumps — it concentrates every secret in one var whose name matches no redaction heuristic.

Threat-model note (document, don't oversell): the ephemeral key travels in _VARLOCK_ENV_KEY in the same environment (matching the existing JS auto-load design), so this is accident hardening, not a boundary — an attacker with full env read gets ciphertext + key. Out-of-band key delivery (inherited fd/pipe) is a possible later upgrade that doesn't change the blob format; write the loaders so the key source is a seam.

Design

  1. varlock run: when settings.encryptInjectedEnv is set and blob injection is on, generate (or reuse) _VARLOCK_ENV_KEY, encrypt the blob via the existing runtime/crypto helpers, inject ciphertext + key. The JS runtime already decrypts (init-server/init-edge), so JS children work with zero changes. With --inject all individual vars remain plaintext — still encrypt the blob (strictly better), but document that the full posture requires --inject blob.

  2. Generated loaders — conditional emission. The code generator knows whether the schema sets @encryptInjectedEnv (it has the graph in CodeGenContext), so only emit the decrypt path for schemas that opt in. This preserves the zero-dependency promise for everyone else:

    • Go: stdlib crypto/aes + cipher.NewGCM — no new deps
    • PHP: openssl_decrypt(..., 'aes-256-gcm', ...) — no new deps
    • Rust: add aes-gcm crate to the documented cargo add line
    • Python: guarded cryptography import with a clear "pip install cryptography" error (stdlib has no AES-GCM)

    Format: varlock:v1: + base64(iv[12] ‖ ciphertext ‖ tag[16]), AES-256-GCM, 64-hex-char key from _VARLOCK_ENV_KEY. Make version detection explicit in each loader from day one — a future varlock:v2: fans out across five implementations.

  3. Tests: shared cross-language test vectors (fixed key + blob → known plaintext) and an encrypted variant of the smoke-tests/tests/lang-modules.test.ts compile-run suite.

  4. Docs: other-languages hub + the four language pages; extend the @disableProcessEnvInjection "no plaintext" story beyond JS; keep the existing clear error as the fallback for stale generated files.

Out of scope

  • Out-of-band key delivery (fd/pipe) — later upgrade
  • Encrypting individual injected vars
Lingua principale
TypeScript
Stelle
4.9k
Fork
140
Merge medio
2g 3h
PR unite (30g)
35

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 dmno-dev/varlock

Tutte le issue di dmno-dev/varlock

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.