feat: encrypted secrets passphrase unlock at gtc start (v0.6.0)#101
Draft
BimaPangestu28 wants to merge 1 commit into
Draft
feat: encrypted secrets passphrase unlock at gtc start (v0.6.0)#101BimaPangestu28 wants to merge 1 commit into
BimaPangestu28 wants to merge 1 commit into
Conversation
Adds a decrypt-to-tempfile shim that lets gtc start consume bundles whose dev secret store has been encrypted by greentic-setup v0.6. Architecture: - New module passphrase_unlock parses the v1 header, prompts for passphrase via greentic-secrets-cli, derives the master key with Argon2id, decrypts the body in-memory with AES-256-GCM, then writes a 0600-mode plaintext copy to $XDG_RUNTIME_DIR (or /tmp) and points GREENTIC_DEV_SECRETS_PATH at it. - The tempfile is held alive in run_start via UnlockedDevStore which removes the file on Drop (best effort). - The runner stack stays on greentic-secrets-lib v0.5 — no version skew with greentic-runner-host etc. Only the new additive crates greentic-secrets-passphrase and greentic-secrets-cli are pulled in. CLI flags: - --passphrase-stdin: read passphrase from stdin (also via GREENTIC_PASSPHRASE_STDIN=1 env var) - --passphrase-file <PATH>: read from 0600-mode file When the bundle's dev store is in legacy plaintext format (or absent), the unlock is a no-op: bundles that never went through encrypted setup still work unchanged. Version 0.5.4 -> 0.6.0. [patch.crates-io] in Cargo.toml temporarily points greentic-secrets- passphrase + greentic-secrets-cli at the local clone while greenticai/greentic-secrets#51 awaits publish; remove the patch block before merging this PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When a bundle's dev secret store has been encrypted by `gtc setup` (greentic-setup v0.6), `gtc start` now prompts the user for the passphrase, decrypts the store body in-memory, writes a 0600-mode plaintext copy to a tempfile, and points `GREENTIC_DEV_SECRETS_PATH` at it so the v0.5 runner stack can read secrets unchanged.
What changes
CLI
New module `src/passphrase_unlock.rs`
Wiring
Why a tempfile shim instead of bumping greentic-secrets-lib?
The runtime stack (`greentic-runner-host`, `greentic-runner-desktop`, `greentic-distributor-client`) is currently pinned to `greentic-secrets-lib v0.5`. Bumping the entire chain to v0.6 in lockstep would block this PR on several upstream releases. The shim avoids that: greentic-start does the decrypt, the runner sees a normal plaintext store, the trait identity stays at v0.5 across the whole graph. When `greentic-runner-host` upgrades to v0.6 in a future release, this entire shim module can be deleted in favor of opening the encrypted store directly.
Version
`0.5.4` → `0.6.0`.
Security
Test plan
Related