Security

What UnENVerse protects, what it cannot, and how to check us. There is no third-party audit and no certification, and this page does not imply either.

What it protects against

• Someone with your disk. The vault is a SQLCipher database. The key comes from your master password through Argon2id (memory 64 MiB, 3 passes) and a random 16-byte salt. The password and the key are never written to disk, and the key is cleared from memory when the vault locks.
• Secrets leaking through the CLI. Output is redacted by default, and redaction fails closed: a field prints only if it is listed as safe. Getting a real value out takes an explicit option, and local runs that materialise values are logged.
• Silent tampering with history. The audit log and the config history are hash-chained, so editing or deleting a row is detectable with unv audit --verify and unv doctor.
• A hub that goes wrong. Node requests are signed. A node can require a human approval bound to the exact bytes, signed on your own device, so a compromised hub cannot push a file the node accepts.
• Hostile vault data. Vault contents are treated as untrusted input: every field is escaped before it is drawn, and only http and https addresses become links.

What it does not protect against

• Root on a running machine while the vault is unlocked. The key is in memory, because a program that decrypts things has to hold it. Lock the vault, and protect the session it runs in.
• A forgotten master password. There is no recovery. Keep an encrypted backup and the vault.salt file.
• Windows file permissions. On Linux the database, salt and session files are owner-only. On Windows they inherit the folder's access list, and unv doctor reports that as "not enforceable" instead of passing.
• Anything you copy out. Once a value is on the clipboard, in a rendered file or in a process environment, UnENVerse no longer controls it.

Who is trusted

The desktop app and the CLI trust the person at the keyboard. The optional unv-server trusts the owner's master password and gives each other user a scoped login, with rate limiting on failed attempts. Servers are pinned by certificate fingerprint, and a certificate is never silently re-pinned.

Verify what you run

Release files have checksums and keyless Sigstore signatures. Here is how to check them.

Report a vulnerability

Do not open a public issue for a suspected vulnerability. Contact the maintainer through the address on the maintainer's GitHub profile, or use GitHub's private vulnerability report on the repository's Security tab when it is offered there. Include a minimal reproduction, the affected version and the impact. Reports are acknowledged within seven days. See the full security policy. Please test only against vaults and systems you own.

Longer reading: the security model in the guide.