Encrypted env blob support for varlock run + generated language modules

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

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

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
go, php, python, rust, typescript
領域
backend, security

調査の方向性

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.

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

説明

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
主要言語
TypeScript
スター
4.9k
フォーク
140
平均マージ
2日 3時間
マージ済み PR（30日）
35

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

dmno-dev/varlock のほかの issue

dmno-dev/varlock の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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