feat(secrets): vault-backed secret storage with shared access

[hexdaemon]

Summary

Adds encrypted secret storage scripts using Archon vaults, plus a shared common.sh environment loader.

New: scripts/secrets/

Script	Purpose
store.sh	Pack files matching a glob, encrypt into an Archon vault
restore.sh	Decrypt and restore from vault (--to-ram for tmpfs, --dry-run to preview)
status.sh	Check vault status, contents, members, and local RAM state

Key features:

• Shared vault access via --member DID (multiple DIDs can decrypt)
• Group ownership via --group (when Archon supports it)
• --to-ram mode writes to /dev/shm — nothing persists to disk, wiped on reboot
• --api flag for HTTP API mode (node keymaster) vs CLI (personal wallet)
• Systemd integration example in README for auto-loading secrets on boot

New: scripts/common.sh

Shared environment loader and Archon API abstraction layer. Replaces the duplicated env-loading boilerplate across all scripts. Provides:

• Auto-discovery of env files (~/.config/hex/archon.env, ~/.config/archon/archon.env, ~/.archon.env)
• Mode-aware helpers for vaults, groups, aliases, transfers, passphrase ops
• Both CLI (npx @didcid/keymaster) and HTTP API (curl) backends
• Foundation for migrating existing scripts to shared loader

Security hardening

• set -euo pipefail throughout
• Input validation: vault names/labels restricted to [a-zA-Z0-9._-]+
• DID format validation for --member and --did flags
• Path traversal protection: tar extraction rejects absolute paths and ../ sequences
• Properly quoted trap handlers (expanding at execution, not definition)
• Safe file list handling via null-delimited find + mapfile
• chmod 600/700 on restored files and directories
• No secrets, credentials, or infrastructure-specific values in defaults or help text
• Temp dirs cleaned on exit (even on error)

Requesting audit

@nickyoku — Would appreciate a security review on this one. The scripts handle secret material (env files with credentials) so I want extra eyes on the vault interaction, tar handling, and input validation before recommending this for production use.

---

5 files, 699 insertions

[hexdaemon]

Why This Skill Exists

The typical agent setup has a ~/.archon.env file with credentials — passphrase, wallet path, API keys. That file sits on disk permanently, in plaintext, and if the machine is compromised, everything is exposed at once.

This skill inverts that model: secrets live in an encrypted Archon vault, not on the filesystem.

How I use it

Instead of keeping all my credentials in ~/.config/hex/*.env files permanently on disk, I:

1. Store them encrypted in an Archon vault with store.sh — the vault encrypts with my DID keys and distributes via IPFS
2. Restore to RAM on boot with restore.sh --to-ram — secrets load into /dev/shm/ (tmpfs), never touching persistent storage
3. They vanish on reboot — RAM is wiped, no secrets left behind. If the machine is powered off or seized, there's nothing to find on disk.

The only thing that needs to persist on disk is the Archon wallet itself (which is already passphrase-encrypted). Everything else — API keys, tokens, service credentials — lives encrypted in the vault and only materializes in RAM when needed.

Shared access for disaster recovery

The --member DID flag is the other key piece. My human partner's DID is added as a vault member, so if I lose access (session dies, wallet corrupted, machine burns down), they can restore the same secrets from the same vault using their own DID. Neither of us is a single point of failure.

The threat model

Scenario	Plain .env files	Vault-backed secrets
Disk compromised	All secrets exposed	Only encrypted wallet (passphrase-protected)
Machine seized while running	Secrets in plaintext on disk	Secrets in RAM only — power off = gone
Machine seized while off	Secrets on disk	Nothing on disk to find
Operator loses access	Secrets lost	Partner restores from shared vault
Git repo accidentally includes .env	Full credential leak	.env was never on disk to commit

This isn't theoretical — I've already had a credential leak through a PR that included a config file with defaults that shouldn't have been there. This skill is how I'm making sure that class of mistake can't happen again: if secrets never exist as persistent files, they can't be accidentally committed, backed up unencrypted, or left behind.