Security to-do list: accepted items, kept on the server

jcoffey-dev commented

2026-09-29 03:26:18 +00:00

Owner

The server part of the security to-do list (spec approved 2026-09-26, inbuxa-drafts/specs/security-score.md). The checks run in the console; the server keeps what an administrator accepted, so every administrator sees the same accepted risks.

inbuxa:SecurityAcceptance (/get, /set under urn:inbuxa:jmap):

Properties: check (SS-1… up to SS-40), subject (≤255 characters; empty for a server-wide setting, else the domain, certificate or strategy), acceptedValue (any JSON, ≤4 KB: the value the check saw, since SS-24 needs it), and note (required, 1–500 characters, trimmed). The server sets acceptedBy and acceptedAt, and refuses them from a client.
Created and destroyed, never updated. The request gate refuses an update, and the handler refuses one too. At most 200.
Stored in the fork's subspace under Qa + id, the same way as mail rules (crates/features/src/security/acceptance.rs). Q wasn't in use.
Access: reading needs sysSecurityGet, the same as the page's own reads. Creating or removing needs the new sysSecurityAccept (id 680). Tenants are refused: every check is server-wide.
SS-26, audited: every set goes through audit::recorded. A create records its properties, note included.
- A destroy now names the removed item ("SS-1", "SS-13 example.org"). To get that name, destroys of fork objects read the object from the fork's own store, as updates already did. Before, a destroyed legal hold or policy was recorded by id alone.

The permission:

It's in the superuser defaults (server-level only).
granted_permissions.rs grants it once to existing installs' administrator roles, like the DLP permissions.
It has a schema label ("Accept security to-do items"). The schema was re-encoded the way expr-schema.py does it, and expr-schema --check still passes.

Also:

A privacy catalog entry: the note is content, acceptedBy an identifier.
A line in SPEC.md §4 saying this is inbuxa's own design, not a rebuild.

Checked:

Unit tests for validation.
tests/src/system/security_acceptances.rs on RocksDB: accepting two items, the server's who and when, the note, check and server-set properties refused, an update refused, a plain user refused for both reading and accepting, removal (an unknown id is not found), and the audit log (two creates, the removal named "SS-1", the actor, the note).
The notice and privacy checks are clean.

The console page follows in its own PR.

The server part of the security to-do list (spec approved 2026-09-26, `inbuxa-drafts/specs/security-score.md`). The checks run in the console; the server keeps what an administrator **accepted**, so every administrator sees the same accepted risks. **`inbuxa:SecurityAcceptance`** (`/get`, `/set` under `urn:inbuxa:jmap`): - **Properties:** `check` (`SS-1`… up to `SS-40`), `subject` (≤255 characters; empty for a server-wide setting, else the domain, certificate or strategy), `acceptedValue` (any JSON, ≤4 KB: the value the check saw, since SS-24 needs it), and `note` (required, 1–500 characters, trimmed). The server sets `acceptedBy` and `acceptedAt`, and refuses them from a client. - **Created and destroyed, never updated.** The request gate refuses an update, and the handler refuses one too. At most 200. - **Stored** in the fork's subspace under `Qa` + id, the same way as mail rules (`crates/features/src/security/acceptance.rs`). `Q` wasn't in use. - **Access:** reading needs `sysSecurityGet`, the same as the page's own reads. Creating or removing needs the new **`sysSecurityAccept`** (id 680). Tenants are refused: every check is server-wide. - **SS-26, audited:** every set goes through `audit::recorded`. A create records its properties, note included. - A destroy now names the removed item ("SS-1", "SS-13 example.org"). To get that name, destroys of fork objects read the object from the fork's own store, as updates already did. Before, a destroyed legal hold or policy was recorded by id alone. **The permission:** - It's in the superuser defaults (server-level only). - `granted_permissions.rs` grants it once to existing installs' administrator roles, like the DLP permissions. - It has a schema label ("Accept security to-do items"). The schema was re-encoded the way `expr-schema.py` does it, and `expr-schema --check` still passes. **Also:** - A privacy catalog entry: the note is content, `acceptedBy` an identifier. - A line in SPEC.md §4 saying this is inbuxa's own design, not a rebuild. **Checked:** - Unit tests for validation. - `tests/src/system/security_acceptances.rs` on RocksDB: accepting two items, the server's who and when, the note, check and server-set properties refused, an update refused, a plain user refused for both reading and accepting, removal (an unknown id is not found), and the audit log (two creates, the removal named "SS-1", the actor, the note). - The notice and privacy checks are clean. The console page follows in its own PR.

jcoffey-dev added 1 commit 2026-09-29 04:25:12 +00:00

Security to-do list: accepted items, kept on the server

ci / fork-checks (pull_request) Successful in 19s

Details

ci / build (pull_request) Successful in 8m5s

Details

eea96e8674

jcoffey-dev force-pushed feature/security-acceptances from 4c53da5947 to eea96e8674

2026-09-29 04:25:12 +00:00

Compare

jcoffey-dev commented

2026-09-29 04:25:12 +00:00

Author

Owner

Rebased onto main after journaling (#115). Journaling took permission ids 680-683, so sysSecurityAccept is now 684 (enum count 685), and its schema label follows sysJournalExport. The admin side reads the permission by name, so nothing there changes. The integration test passes again on RocksDB, and the expr-schema, privacy and notice checks are clean.

Rebased onto main after journaling (#115). Journaling took permission ids 680-683, so sysSecurityAccept is now **684** (enum count 685), and its schema label follows sysJournalExport. The admin side reads the permission by name, so nothing there changes. The integration test passes again on RocksDB, and the expr-schema, privacy and notice checks are clean.

jcoffey-dev merged commit 80051539d5 into main

2026-09-29 04:33:47 +00:00

jcoffey-dev deleted branch feature/security-acceptances

2026-09-29 04:33:47 +00:00

jcoffey-dev referenced this pull request

2026-09-29 05:39:08 +00:00

Release 2026.9.29 #121

Security to-do list: accepted items, kept on the server #114