.env now holds PORT and POSTGRES_URL. Every encryption and signing key lives in $OFFICER_ROOT/secrets/officer-keys.db — 0600, 0700 directory, owned by the service user, created on first use. The design doc planned to move ONE at-rest key into the store. What shipped splits it: headscale, wallet, photos, jellyfin, invoiceshelf, vault and service-connections each get their own, plus jwt. VAULT_STORE_KEY encrypted all seven, so one leak opened all of them — and it was named after whichever plugin needed it first, which is why it read as safe to change if you did not run a vault. A core install bootstraps two, jwt and headscale; the rest appear when their plugin first asks. The file IS the secret. No second key unlocks it, because a key beside the store it opens buys nothing. The gain was never secrecy, it is blast radius: bun auto-loads .env into all twenty pm2 processes, so a key there is readable from /proc/<pid>/environ of twenty processes — officer-music held the key that decrypts wallet seed envelopes. Two defects found by testing the store rather than reading it, both of which would have shipped: The WAL was 0644. Enabling WAL creates -wal and -shm at 0644 rather than inheriting the database's mode, and a freshly written key lives in the WAL before checkpoint — so the 0600 on the database was decorative. The 0700 directory covered it, but only until someone loosened the directory. PRAGMA journal_mode = WAL takes an exclusive lock, and busy_timeout was set AFTER it. With twelve concurrent openers, six died on that line with SQLITE_BUSY. Every sidecar opens this store at boot, so they open it simultaneously by definition: most of them would have failed to start on a cold boot and none on a warm one. Fixed by ordering the pragmas; re-tested with twelve racing processes, one key, one row. crypto.ts takes a purpose as its first argument now, which the design doc had explicitly promised would not happen — 32 call sites across seven query modules. That promise is corrected in the doc rather than quietly dropped. Also live, not just comments: wallet/upstream.ts gated wallet storage on process.env.VAULT_STORE_KEY and would have reported "unconfigured" forever. It asks the store now, and the question it answers changed — not "did somebody set a variable" but "can this process open the store", since the key is created on demand. assertSecretsClosed covers the store, its directory and its WAL. The jwt key mints owner tokens, so a member's shell reading it is strictly worse than the .env leak that check was written for. Not typechecked: node_modules is empty and installs are frozen, so the officerdb/secret-store subpath could not be resolved at runtime here — verified that officerdb/types fails identically, so it is the empty tree and not the new export. The store module itself was tested directly: creation, idempotence across processes, hasKey not creating, permissions, and the twelve-way race. Every changed file parses; the setup section runs and degrades correctly when the import is unavailable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
76 lines
2.3 KiB
Bash
76 lines
2.3 KiB
Bash
#!/bin/bash
|
|
# =============================================================================
|
|
# officer-setup — the environment file
|
|
# =============================================================================
|
|
#
|
|
# Definitions only.
|
|
#
|
|
# ── No secrets are written here ──
|
|
#
|
|
# Every encryption and signing key lives in the secret store — a 0600 SQLite file
|
|
# at $OFFICER_ROOT/secrets/officer-keys.db, one key per purpose, created on first
|
|
# use. See docs/secret-store.md and the Secrets section of officer-setup.sh.
|
|
#
|
|
# So this file holds no credential except POSTGRES_URL, which is a connection
|
|
# string to a database bound to loopback.
|
|
#
|
|
# ── Derived, not asked ──
|
|
#
|
|
# DATA_PATH, OFFICER_ITEMS_DIR and HOME_DIR are gone too, and this time nothing
|
|
# replaces them. The platform derives the install root as the parent of its own
|
|
# working directory, so data/, capabilities/ and dockers/ follow from the layout
|
|
# on disk, and the owner's home comes from the OS. They were three environment
|
|
# variables that had to agree with each other and with the directory tree.
|
|
|
|
[[ -n "${OFFICER_SETUP_ENV_LOADED:-}" ]] && return 0
|
|
OFFICER_SETUP_ENV_LOADED=1
|
|
|
|
env_file() { echo "$(platform_dir)/.env"; }
|
|
|
|
env_exists() { [[ -f "$(env_file)" ]]; }
|
|
|
|
# One value out of an existing .env, without sourcing it — the file holds
|
|
# secrets and arbitrary shell would run as root.
|
|
env_get() {
|
|
[[ -r "$(env_file)" ]] || return 0
|
|
awk -F= -v k="$1" '
|
|
$1 == k {
|
|
v = substr($0, index($0, "=") + 1)
|
|
gsub(/^"|"$/, "", v)
|
|
print v
|
|
exit
|
|
}' "$(env_file)"
|
|
}
|
|
|
|
write_env() {
|
|
local dest
|
|
dest="$(env_file)"
|
|
|
|
[[ -f "$dest" ]] && cp -a "$dest" "${dest}.before-officer-setup"
|
|
|
|
# Restrictive from the moment it exists rather than chmod'd afterwards, so the
|
|
# secrets are never briefly world-readable. Restored straight after: umask is
|
|
# not scoped to a function, and leaving it at 077 would quietly make every file
|
|
# a later section creates owner-only.
|
|
local prior_umask
|
|
prior_umask="$(umask)"
|
|
umask 077
|
|
cat >"$dest" <<ENVF
|
|
# Written by officer-setup.
|
|
#
|
|
# Everything Officer reads at runtime. Kept at 0600 and owned by ${USERNAME}: it
|
|
# holds the token-signing secret and the database credential.
|
|
|
|
PORT="${ENV_PORT}"
|
|
|
|
POSTGRES_URL="${POSTGRES_URL}"
|
|
|
|
ENVF
|
|
|
|
umask "$prior_umask"
|
|
|
|
chown "${USERNAME}:$(user_group)" "$dest"
|
|
chmod 600 "$dest"
|
|
return 0
|
|
}
|