Ronni Baslund
9435baa09d
The audit log now carries cryptographic chain-of-custody. Every chained
event references the previous event's sha256, and periodic checkpoints
sign the head with HMAC-SHA-256. An attacker who modifies a historical
row must also forge every checkpoint signature past it — which requires
the AUDIT_SIGNING_KEY, kept outside Mongo.
Schema (services/platform-api/src/schemas/):
- audit-event.schema.ts: new `seq` (monotonic) + `chained` (Phase-3-or-
later flag) + `prevHash` + `hash`. Compound unique index on seq with
partial filter so pre-Phase-3 rows don't collide on null.
- audit-counter.schema.ts: single doc `_id='audit_seq'`, incremented
atomically by findOneAndUpdate($inc).
- audit-checkpoint.schema.ts: { at, headSeq, headHash, signature,
sigAlg, reason }. Reason ∈ {startup, interval, threshold, manual}.
Audit module (services/platform-api/src/audit/):
- canonical.ts: stable JSON form + hashCanonical (sha256) +
checkpointSignature (HMAC-SHA-256) + verifyCheckpointSignature
(timingSafeEqual). Single source of truth for hash inputs — schema
additions land here at the same time as the field.
- audit.service.ts: record() now allocates seq → looks up lastHash() →
computes hash → inserts. Per-process write mutex serializes the
allocate+lookup so concurrent writers don't both chain off the same
predecessor. Documented multi-instance caveat (needs Mongo replica
set + transactions OR a distributed lock).
- checkpoint.service.ts: scheduler triggers on startup + every 5min
+ threshold of 100 events accumulated. Skips when no new chained
events since the last anchor.
- verifier.service.ts: walks chain in seq order, recomputes each
hash, validates checkpoint signatures. Returns a precise break:
'event-hash-mismatch' (in-place modification), 'event-prev-hash-
mismatch' (insertion/deletion), or 'checkpoint-signature-mismatch'.
- audit.controller.ts: GET /audit/verify, GET /audit/checkpoint/latest,
POST /audit/checkpoint (manual force).
Operator UI (apps/operator/):
- 3 new proxies under /api/audit/{verify, checkpoint/latest, checkpoint}.
- pages/audit.vue: new "Tamper evidence" card with "Force checkpoint"
+ "Verify chain" buttons. Header shows live head seq; result line
shows verified count or a precise break (kind + seq + expected vs
actual hash). Background tinted green/red on ok/broken.
Env (.env + docker-compose.yml):
- new AUDIT_SIGNING_KEY (32-byte hex HMAC secret). Prod swaps this for
ed25519 from an HSM/KMS; verifier code stays the same because sigAlg
is on the checkpoint doc.
Smoke-tested all three break paths against a clean chain of 5 events:
- normal verify: ok=true, 5/5 events verified, 1 checkpoint signed
- modified seq=3 in Mongo directly: verify returns ok=false with
break = { kind: 'event-hash-mismatch', seq: 3, expected, actual }
- restored, nuked checkpoint signature: break = { kind:
'checkpoint-signature-mismatch', headSeq: 5 }
- operator UI's verify panel reflects all three states correctly.
Legacy data: pre-Phase-3 events stay `chained: false` and are excluded
from the chain walk. Retroactive chaining of historical entries is a
one-off migration script we can run if we ever care to.
Out of scope (Phase 4 etc.):
- TTL + cold-storage archival to Hetzner Object Storage
- GDPR right-to-erasure tooling
- ed25519 / HSM signing (swap is well-defined; sigAlg field is ready)
- Multi-instance write coordination (Mongo transaction OR distributed
lock when we scale platform-api beyond 1 replica)
Dezky
Sovereign workspace platform for European businesses. Mail, files, calendar, video meetings — all EU-hosted, all open source.
Quick start (local development)
# 1. Clone and enter
git clone <repo-url> dezky
cd dezky
# 2. Run bootstrap (handles everything)
./scripts/bootstrap.sh
# 3. Open the portal
open https://app.dezky.local
The bootstrap script:
- Checks prerequisites (Docker, mkcert, openssl)
- Generates wildcard TLS certificate via mkcert
- Adds /etc/hosts entries (with your permission)
- Generates secure random secrets in
.env - Pulls Docker images
- Starts all services in correct order
- Prints next-step instructions
Service URLs (local development)
| Service | URL | Purpose |
|---|---|---|
| Portal | https://app.dezky.local | Customer-facing landing & launcher |
| Authentik | https://auth.dezky.local | Identity provider (OIDC/SAML) |
| Files (OCIS) | https://files.dezky.local | File storage & sharing |
| Mail (Stalwart) | https://mail.dezky.local | Mail server admin UI |
| Office | https://office.dezky.local | Collabora Online editor |
| Traefik | https://traefik.dezky.local | Reverse proxy dashboard |
What's in this repo
dezky/
├── apps/portal/ Nuxt 3 customer portal
├── services/platform-api/ NestJS service · tenants, partners, users, provisioning orchestration
├── packages/ Shared TypeScript libraries
├── infrastructure/
│ └── docker-compose/ Local development stack
├── scripts/ Setup, reset, helpers
└── docs/ Service references & guides
Prerequisites
- macOS or Linux (Windows users: use WSL2)
- Docker Desktop 24+ or OrbStack
- mkcert (
brew install mkcert) - pnpm 9+ (
brew install pnpm) - Node.js 20+
- 16 GB RAM recommended
Common commands
# Start everything
docker compose -f infrastructure/docker-compose/docker-compose.yml up -d
# View logs
docker compose -f infrastructure/docker-compose/docker-compose.yml logs -f [service]
# Stop everything (keeps data)
docker compose -f infrastructure/docker-compose/docker-compose.yml down
# Nuke and restart (DESTROYS DATA)
./scripts/reset.sh
Architecture
This is a multi-tenant SaaS platform. Each tenant gets:
- Isolated Authentik OIDC tenant
- Custom subdomain (e.g.
customer-name.dezky.local) - Mail domain in Stalwart with auto-generated DKIM
- Dedicated OCIS space hierarchy
- Branded launcher in the portal
All components are Apache 2.0 / MIT licensed — no per-seat fees, full whitelabel rights.
Production
The production target is a single Hetzner AX41-NVMe server (€39/mo) with:
- Stalwart on bare-metal
- k3s for all other services
- Hetzner Object Storage (€5/mo) as OCIS S3 backend
- Storage Box BX11 (€3.20/mo) for Restic backups
- Storage Box BX11 in Helsinki (€3.20/mo) for DR
See docs/PRODUCTION-DEPLOYMENT.md (TBD) for migration plan.
Stack rationale
These choices are deliberate after extensive license/architecture research. See CLAUDE.md for the full reasoning.
| Component | License | Why this one |
|---|---|---|
| Stalwart Mail | Apache 2.0 | Modern Rust, ActiveSync built-in, JMAP support |
| OCIS | Apache 2.0 | Cleaner license than Nextcloud (AGPL+trademark) |
| Zulip | Apache 2.0 | Only truly open-core-free chat option |
| Authentik | MIT | Better multi-tenancy than Keycloak |
| Hetzner | N/A | 100% EU sovereignty — core to business |
License
Application code: MIT (own code) Third-party services: see individual service licenses in stack.