Where to store mnemonics?

[dakom]

Right now we store them in-memory

Maybe we should optionally use keyring or similar instead (and load on every usage, not keeping in memory, which would also allow rotation)?

This issue is currently a R&D/question, not to implement

[reecepbcups]

Keyring could make sense? Just note that we would have to either

• put the keyring password in the wavs.toml / .env or
• set keyring to test (in which case is it really secure either way)

[dakom]

It's an OS configuration thing, afaik all OS's can be setup so that the key retrieval is silent after a user is logged in for a specific program (in other words - the actual password we'd need is the user's account on the system... we definitely don't want to require them setting that in wavs)

[reecepbcups]

Thinking back to how other production systems do it (cosmos-sdk / cometbft), they store the validator consensus signing key for every block in a flatfile like this.

Keyring is a nice to have, but not strictly required. A flat file / .env seems fine for me given the risks & how comet already does it. If we can improve, amazing. If not I am fine with where it is at now as well

[dakom]

they store the validator consensus signing key for every block in a flatfile like this.

🤯

[reecepbcups]

need password to access keyring (just storing in a file feels wrong, but where is the password go?) also if machine is compromised then it's already compromised unless its a TEE. Are we as secure as anything else we can do

[dakom]

I asked ChatGPT about this, since I'm not a DevOps/security expert, figured it would at least share some helpful info. It did... guess we should create issues for adding all these different kinds of connectors for credentials and slowly add that support in?

---

What “good” looks like (at a glance)

1. Never bake plaintext secrets into files or images (.env, Dockerfile, git).
2. Fetch secrets at runtime using the machine/workload identity, not a stored password.
3. Keep secrets in a dedicated secret manager with auditing & rotation (AWS/GCP/Azure/Vault/1Password SA).
4. Deliver secrets to the process over a memory-only channel (tmpfs, systemd credentials, K8s projected volumes) and avoid logs/core dumps.
5. Rotate on a schedule and on demand; use the shortest TTLs you can.

---

The “secret zero” problem (and why keyring isn’t the fix on servers)

Desktop keyrings are meant for interactive users. On headless servers, unlocking a keyring typically requires another secret (a passphrase, file key, or OS login) ⇒ you’ve moved the problem, not solved it. Instead, tie access to workload identity issued by the platform

... ChatGPT said a bunch of other per-platform stuff here ...

Concrete, secure defaults (copy/paste checklist)

• Cloud:

  • Put secrets in the cloud secret manager; enable encryption (KMS) + rotation.
  • Grant the service’s role read on only the needed secrets.
  • App fetches on start; caches in memory (secrecy), refreshes on schedule or on 403/expiry.
  • No secrets in env vars or images; no .env in CI artifacts.

• Kubernetes:

  • Use CSI Secrets Store or External Secrets Operator.
  • Project secrets as files on emptyDir: { medium: "Memory" }.
  • App supports SIGHUP reload; liveness/readiness reflect secret availability.

• Bare metal:

  • Use systemd credentials or Vault.
  • Back key material with TPM2 (no passphrase prompts).
  • Files live under /run/credentials/..., 0600, wiped on stop.