Security

Items are instructions and code that run on developers' machines with their permissions, so the review is the boundary: nothing outside a personal workspace is released until a moderator, workspace admin or root who isn't the author approves it, and root approving their own work is recorded as an override. Risk flags (hooks, MCP servers, permission policies, status lines, executables, shell scripts, network addresses) show reviewers what to read closely; they never block. Skills, commands and agents are text that can still tell an AI tool to run commands, and no flag catches every such line: the reviewer reads them.

• Installing runs nothing. rmk writes files and checks each download's sha256 against the registry and rmk.lock; the AI tool runs what's written.
• Where the secrets are. The settings file holds AUTH_SECRET, which signs sign-in cookies, and DATABASE_URL, with the database password; setup writes it readable only by its owner. Access tokens are stored as hashes, passwords with argon2. Whoever reads the settings file can sign in as anyone until the secret is replaced (below).
• Signing in. Five attempts a minute per email; with two-factor sign-in, a code from an app after the password, which a root can require of reviewers or of everyone (Settings). A password alone gets no rmk token for an account with two-factor. Its secrets are encrypted with a key from AUTH_SECRET, the one secret: the server refuses to start while BETTER_AUTH_SECRETS is set.
• Identity providers. Only root sets them up, and each is tested before it can be turned on. Their client secrets are encrypted with a key from AUTH_SECRET, tied to the provider, and never shown again. Every sign-in checks the provider's signature on its answer, that the answer belongs to this sign-in, and that the email is verified; an issuer must be https://. Ronne signs people in only through its own routes: the sign-in library answers nothing else from the browser. Root can always sign in with a password, and disable-sso turns every provider off (Lockout and broken providers).
• What Ronne doesn't encrypt. The database, the stored items and backups are as safe as the disk and the database server they're on: encrypt those where you run them.
• Private isn't encrypted. A private workspace is invisible to non-members everywhere, but root sees every workspace, and whoever runs the server can read everything (Public and private).

The threat model goes through each boundary: who might attack it, what stops each threat, and the known gaps with what will close them. To report a vulnerability in Ronne itself, follow the security policy: privately, never in a public issue. Only the latest release gets fixes (Upgrading).

Ronne doesn't encrypt its own files: the platform does it better, and a key inside the app would be one more secret to lose.

• The server's disk for SQLite, the stored items and the backups: LUKS on Linux, FileVault on macOS, or your cloud provider's encrypted volumes.
• The database's own for PostgreSQL and MySQL: the managed service's encryption, or the database server's disk.
• Archives that leave the machine: backup --encrypt (AES-256-GCM, with a key made from your passphrase).