v2.4.0

Security hardening: safer defaults, checks that say when a setup is weak, and tests that hold
every path to the same rules. Prompted by an outside review of the code.

Upgrading

• The sign-in lockout is now on, everywhere: 10 failed password sign-ins per identity and
  address in 15 minutes. Installations that had it at 0 (the old default) are switched on once,
  at the first start of 2.4; turn it off again in Settings, Security, if you really need to
  (Health will warn).

Security

• Rate limits keep their total when the database fails. With several instances, requests are
  counted in PostgreSQL; if that failed, each instance counted on its own, so three instances
  allowed three times the limit, and only a debug log said so. Now each instance counts its
  share of each limit (the limit divided by the live instances), the failure is logged as a
  warning, and Health reports it.
• Health has security checks: slonbase connecting as a PostgreSQL superuser, the lockout
  off, rate limits off or recently degraded, and an application URL without https.
• The SQL console can run as a role of its own: --sql-console-role
  (SLONBASE_SQL_CONSOLE_ROLE, server.sql_console_role) runs its statements with
  SET LOCAL ROLE, so it can have fewer privileges than slonbase, such as read-only access
  (see configuration).
• One test for every way to reach a record: tests/authz_matrix.rs checks that list, view,
  counts, filters (through relations and @collection), forward and back expand, protected
  files, realtime, update, delete and batch all agree with the same rules, for a guest and two
  users.
• Generated filter tests: thousands of filters full of SQL and filter metacharacters are
  compiled, checking that a client's value never reaches the SQL text, only parameters, and
  20,000 random inputs that the parser and compiler never panic.
• A restricted dashboard role could reach what it forbids by another route (reported by two
  outside reviews, reproduced with tests before fixing; see the
  security reviews). A developer could create a superuser (which
  starts as an owner) through the superusers collection's id or through a batch; a read-only
  API key could change its owner's password; an import could carry the superusers
  collection; the SQL console was open to developers and admins, and reads every table.
  Roles now apply to a collection however it is addressed, to every request in a batch and an
  import, API keys can't change the account they belong to, and the SQL console is for owners.
• Backups extract within the free disk space and a limit of entries, and a failed automatic
  backup is retried; a restore stages the files before the database changes; CI runs on pull
  requests and fails, rather than skips, without its database.
• A threat model: what slonbase protects and trusts, how each boundary is
  enforced and tested, and how to check a deployment. SECURITY.md invites independent review.

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.4.0
• Debian/Ubuntu: slonbase_2.4.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.4.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.4.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.