No description
bf5aeedbc2
An owner can now rotate a profile's DEK — generating a fresh key, re-encrypting all the profile's data under it (client-side), and re-wrapping to the owner share + kept recipients. A revoked recipient's cached old DEK stops working, closing the soft-revoke window the ADR requires for graduation / suspected compromise. The server stays a blind store: it sees opaque old→new ciphertext blobs flow through, never the DEK or plaintext. No backend crypto. Backend: - ProfileRepository::update_wrapped_dek — rotate the owner share (account-wrapped profile DEK), owner-scoped. - ProfileShareRepository::find_active_for_profile + delete_for_profile_excluding — list current recipients and hard-delete omitted ones. - POST /api/profiles/:id/rekey: validates each submitted envelope against existing active shares (no smuggling new recipients in via rekey), rotates the owner share, upserts recipient envelopes with fresh ephemeral ECDH keys, hard-deletes omitted recipients. - rekey_tests.rs: rotation, hard-revoke-from-recipient-view, no-share rejection, non-owner rejection, revoke-all. Frontend: - useProfileStore.rekeyProfile: fetches all profile data, re-encrypts each row under a new DEK (resume-safe — rows already on the new DEK are skipped), builds fresh ECDH envelopes per kept recipient, commits via POST /rekey, swaps the in-memory DEK. - ProfileSharing: 'Rotate encryption key (hard revoke)' action with a strong confirmation dialog explaining the cost and the resume-safe retry. Best-effort + resumable retry (per design decision); no server-side write lock. Verification: backend cargo build/clippy (-D warnings)/fmt clean, tests compile (integration tests run in CI — Mongo is fixed there). Frontend tsc clean, 31/31 tests pass. ⚠️ Backend integration tests not run locally (no Mongo in this sandbox); CI will run them — I'll fix any failures. Admin-initiated rekey (ADR §5c reserves the permission) is out of scope — handler is owner-only until admin shares are creatable in Phase D. Refs #3. |
||
|---|---|---|
| .forgejo/workflows | ||
| backend | ||
| docs | ||
| scripts | ||
| web | ||
| .cursorrules | ||
| .gitignore | ||
| .gooserules | ||
| AGENTS.md | ||
| README.md | ||
Normogen
Normogen (Mapudungun for "Balanced Life") is an open-source health data platform for private, secure health data management.
📚 Documentation
All project documentation has been organized into the docs/ directory:
- Documentation Index - Start here for complete documentation
- Product Overview - Project introduction and features
- Quick Start - Get started quickly
- API Documentation - Backend API reference
🚀 Quick Start
# Clone repository
git clone <forgejo-url> normogen
cd normogen/backend
# Setup configuration
cp .env.example .env
# Edit .env with your values
# Run with Docker Compose
docker compose up -d
# Check status (default port is 6500 via NORMOGEN_PORT; Solaria maps it to host 6800)
curl http://localhost:6500/health
📊 Current Status
- Backend: ✅ Phase 2.x feature-complete (Rust + Axum + MongoDB), including drug interactions (Phase 2.8). Security-hardened: token-version validation, hashed refresh-token persistence, fail-fast config, real-IP audit logging. Deployed on Solaria.
- Frontend: 🚧 Early (React + TypeScript) — Login/Register pages + API/store layer exist; router not yet wired.
- Tests: 18 unit + 13 integration (auth + medication), CI-gated with MongoDB.
- Deployment: Docker on Solaria (image built manually — CI can't run DinD on Forgejo).
- See docs/product/STATUS.md for the full breakdown.
🗂️ Documentation Structure
docs/
├── product/ # Product definition, features, roadmap
├── implementation/ # Phase plans, specs, progress reports
├── testing/ # Test scripts and results
├── deployment/ # Deployment guides and scripts
├── development/ # Git workflow, CI/CD, development tools
└── archive/ # Historical documentation
📖 Full Documentation
See the Documentation Index for complete project documentation.
Last Updated: 2026-06-27