sekrt

The vault

sekrt init creates a vault at ~/.local/share/sekrt and asks for the passphrase that will encrypt it. Commands that touch a secret ask for that passphrase; ls, find, rm and status never do, because they decrypt nothing. sekrt unlock caches the derived key (never the passphrase) in a RAM-backed, user-private location with a TTL: gpg-agent, without the agent.

The .env workflow

sekrt env push encrypts the .env of the repository you are standing in and files it under that repo; sekrt env pull restores it in any fresh clone, on any machine. Monorepos with one env file per service are handled, and an edited local file is never overwritten without --force.

Running a command with your secrets

sekrt expose cannot work, because a child process cannot set variables in the shell that started it. So sekrt wraps the command instead, and the values live in *its* environment for exactly as long as it runs. Never written to disk, never left in your shell, and never placed in a command line, because ps is world-readable. sekrt shell opens a subshell that tags its own prompt, so a shell holding secrets never looks like an ordinary one.

The TUI

sekrt with no arguments opens the interface: a folder tree of the vault, fuzzy filtering, a masked detail view, add and edit forms with a built-in generator, and one-key sync. Eleven colour presets, one per hue, editable live with t.

Security model

• AES-256-GCM per entry; key derived with scrypt (N=2¹⁵, r=8, p=1) and a random per-vault salt
• The entry's logical name is the GCM associated data, so a renamed or moved ciphertext fails to decrypt
• The remote sees names, folder structure and timestamps; contents are always ciphertext
• unlock caches the derived key in tmpfs (0600, wiped on logout), never the passphrase
• Clipboard clears after 45 s, and only if it still holds the copied value
• $SEKRT_PASSPHRASE is stripped from wrapped children, so they cannot decrypt anything they were not handed