c43abef8abd145b533d9ab1f4d2bf191d41d184e
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a0ffdb8071 |
New-install privacy defaults, and expired bans purged daily
Personal-data catalog spec, defaults D2, D3, D4, D6 and D7 (settled 2026-09-28, new installs only): - D2: automatic IP bans expire after 30 days instead of never; D3: spam training samples, whole messages, are kept 90 days instead of 180; D4: Pyzor, which sends a digest of each message's text to a public server, is off; D6: delivery history is kept 14 days instead of 30. Written on the first boot of a new install only -- one with no roles yet, the same test the built-in roles use -- by reading each singleton, setting these fields and writing it back whole. A server with roles keeps its settings, saved or default. - D7: a webhook created from now on starts with the include policy and no events, so it sends nothing until events are chosen (Rust default and schema default, marked). The registry stores every field, so existing webhooks keep their policy. - Expired bans are also removed by the daily data clean-up. They already stopped blocking and were deleted when settings next loaded; a server that seldom reloads kept them. D1 (log retention) and D5 (the hashed-address blocklist off) are held, and the spec says why: x:TracerLog is stored inside x:Bootstrap with a field after it, so adding one changes that object's stored format; and the spam-rules loader D5 touches is being reworked by the v0.16.24 import. The spec also corrects finding 3: expired bans were deleted on settings load; bans were permanent only because no period is set. Tested: unit tests for the new-install values and that everything else in each singleton stays; the system suite, whose security test now purges an expired ban and checks its record is gone; the telemetry test; common's unit tests; fork checks. |
||
|
|
86d7ebd982 |
Audit log: a permanent, tamper-evident record of admin actions
What administrators and the server itself do to the control plane is now recorded, from inbuxa-drafts/specs/audit-hold-lock.md (AU-1 to AU-12): settings, accounts, domains, roles and every other registry change, with each field's before and after (secrets only as "changed"); the fork's own settings objects; administrator sign-ins (and failed ones to administrator accounts), master-user and recovery-admin sign-ins, once an hour per account, method and address; access to another account's data through impersonation or FetchAnyBlob, once an hour; exports and tamper checks; and registry writes the server makes on its own, named by subsystem (system:AcmeRenewal, system:auto-ban, system:directory-sync, ...), with a spam rules update as one summary record. No change without its record (AU-3): before a set method changes anything, a pending record per requested create, update and destroy is written; if that fails, the method is refused with serverFail. Its outcome follows as a later entry. A change interrupted by a crash stays "unfinished". Records live in the fork's subspace under L, as one SHA-256 hash chain per node. The chain's head is stored, never cached, and every append asserts it, so two writers can't take the same place. Nothing can edit or delete a record; the daily purge removes the oldest past the retention (default 730 days, minimum 90) and records where the chain now starts, so verification still passes. security.audit-recorded (647) copies each record to webhooks, OpenTelemetry and the log; security.audit-write-failed (648) reports a failed write. New JMAP objects under urn:inbuxa:jmap: inbuxa:AuditEvent/get and /query (filters: time, actor, action, target, account, tenant, outcome, address, text), inbuxa:AuditSettings, inbuxa:AuditExport (CSV or JSON Lines built on the server, each line with its chain hash, ending in a manifest; the created object names the blob and its SHA-256) and inbuxa:AuditVerification. New permissions sysAuditGet, sysAuditExport and sysAuditSettingsUpdate: the Administrator role gets all three, the Tenant Administrator role gets read and export, once, on existing installs too. A tenant administrator sees records whose actor or target is in its tenant, including a server administrator's changes there. Sign-in method on the session: access tokens now remember how they signed in (password, app password, API key, OAuth client, directory, master user, recovery admin), including across the HTTP credential cache. New OAuth access tokens carry their client id in the sealed claims; older ones show as client "unknown" until they expire. The schema gains the permissions, the two events and a Management > Compliance > Audit Log link. Stack: the request layer boxes every inner future where it's made. Without that, a debug build overflowed the default 2 MB worker stack on a registry set; measured with the same request, the branch and main now overflow at the same stack size (between 1856 and 1920 KiB, debug), so the layer adds nothing measurable. Tests: unit tests in inbuxa-features and jmap; system::audit::audit_log_tests (run with --ignored) passes on RocksDB, SQLite, PostgreSQL, PostgreSQL with a read replica, MySQL, MySQL with a replica and FoundationDB. The system, JMAP and SCIM suites pass. authorization.rs skipped fork permissions that guard no registry object; the audit suite checks a plain user is refused instead. |
||
|
|
7dae9b29fd |
Import upstream v0.16.22, stripped
Upstream commit: 474dd0229cb20cf513036619781ed97bd8073c3f Enterprise-only files removed or emptied: 63 Enterprise-only snippets removed: 117 in 50 files Dangling module declarations removed: 5 Cargo edits turning enterprise off: 14 Verification: clean Enterprise feature gates left for rebuilt features: 19 in 18 files Produced by tools/fork/strip.py. The full report is in docs/fork/strip-reports/ on main. |