lfg2025/archy
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 33 Wiki Activity

docs: comprehensive security and code quality audit report

Browse Source 
576-line report covering auth, crypto, containers, RPC, frontend,
and custom code vs library comparisons. Overall rating: 7/10.
Top 3 actions: cosign verification, postMessage origin validation,
Argon2id password hashing migration.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dorian
2026-03-15 05:33:08 +00:00
parent f6a3068514
commit 2e289d6d7d
2 changed files with 583 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
loop/plan.md
View File

@@ -164,9 +164,9 @@
> Generate a comprehensive written report at `docs/security-code-audit-2026-03.md`. This phase is research and documentation only — no code changes. The report should be honest about strengths and weaknesses so we know exactly where we stand.
- [ ] **Audit authentication & session security**: Review `core/archipelago/src/auth.rs` and `core/archipelago/src/session.rs`. Document: (1) password hashing — bcrypt with what cost factor? Is Argon2id a better choice for new installs? Compare bcrypt (current) vs argon2id (already a dependency for backup encryption) — pros/cons, (2) session token generation — is 32-byte random hex sufficient entropy? How does it compare to using a CSPRNG-backed JWT or `tower-sessions`? (3) session storage — in-memory only, lost on restart (unless SQLite was added in earlier phases). Rate the risk, (4) CSRF — 32-byte hex token per login, validated on every request. Is this sufficient? (5) rate limiting — per-method in-memory counters. Document coverage gaps (which endpoints lack rate limiting), (6) TOTP — using `totp-rs` with encrypted secret storage. Rate the implementation quality. Write findings to a "Session & Auth" section of the report.
- [x] **Audit authentication & session security**: Review `core/archipelago/src/auth.rs` and `core/archipelago/src/session.rs`. Document: (1) password hashing — bcrypt with what cost factor? Is Argon2id a better choice for new installs? Compare bcrypt (current) vs argon2id (already a dependency for backup encryption) — pros/cons, (2) session token generation — is 32-byte random hex sufficient entropy? How does it compare to using a CSPRNG-backed JWT or `tower-sessions`? (3) session storage — in-memory only, lost on restart (unless SQLite was added in earlier phases). Rate the risk, (4) CSRF — 32-byte hex token per login, validated on every request. Is this sufficient? (5) rate limiting — per-method in-memory counters. Document coverage gaps (which endpoints lack rate limiting), (6) TOTP — using `totp-rs` with encrypted secret storage. Rate the implementation quality. Write findings to a "Session & Auth" section of the report.
- [ ] **Audit cryptographic implementations**: Review all crypto code across the codebase. For each, compare our implementation against what a library would provide:
- [x] **Audit cryptographic implementations**: Review all crypto code across the codebase. For each, compare our implementation against what a library would provide:
| Component | Our Implementation | Library Alternative | Verdict |
|-----------|-------------------|--------------------|---------|
@@ -181,13 +181,13 @@
Write findings to a "Cryptographic Review" section. For each row, state: is our code correct? Is it secure? Would a library be better? Why or why not?
- [ ] **Audit container security**: Review container security across `core/container/src/podman_client.rs`, `core/archipelago/src/api/rpc/package.rs`, and `apps/*/manifest.yml`. Document: (1) are all containers running with `--cap-drop ALL` + only required caps added back? Check each app manifest, (2) `readonly_root: true` — which apps have it, which don't and why, (3) `no-new-privileges` — is it set for all containers? (4) user namespace — are containers running as non-root (UID > 1000)? Check for any running as root, (5) image pinning — are images pinned to specific digests/versions or using `:latest`? List offenders, (6) cosign verification — still a TODO? Document the gap, (7) network isolation — which containers share networks? Is `archy-net` properly scoped? (8) secrets injection — how are secrets passed to containers? Env vars (visible in `podman inspect`) vs mounted files? Write findings to a "Container Security" section.
- [x] **Audit container security**: Review container security across `core/container/src/podman_client.rs`, `core/archipelago/src/api/rpc/package.rs`, and `apps/*/manifest.yml`. Document: (1) are all containers running with `--cap-drop ALL` + only required caps added back? Check each app manifest, (2) `readonly_root: true` — which apps have it, which don't and why, (3) `no-new-privileges` — is it set for all containers? (4) user namespace — are containers running as non-root (UID > 1000)? Check for any running as root, (5) image pinning — are images pinned to specific digests/versions or using `:latest`? List offenders, (6) cosign verification — still a TODO? Document the gap, (7) network isolation — which containers share networks? Is `archy-net` properly scoped? (8) secrets injection — how are secrets passed to containers? Env vars (visible in `podman inspect`) vs mounted files? Write findings to a "Container Security" section.
- [ ] **Audit RPC endpoint security**: Review `core/archipelago/src/api/rpc/mod.rs` — the main RPC dispatcher. Document: (1) which endpoints require authentication and which don't? List any unauthenticated endpoints beyond `auth.login`, `auth.setup`, `auth.isSetup`, `auth.isOnboardingComplete`, (2) RBAC enforcement — was it wired up in Phase 6? If yes, verify it works. If no, document the gap and risk, (3) input validation — pick 5 critical endpoints (login, install package, factory reset, backup restore, identity create) and trace the input from RPC params to handler. Are inputs validated? Are there injection risks? (4) error message sanitization — does `sanitize_error_message()` strip file paths and internal details from user-facing errors? Test with a few error cases, (5) path traversal — check `filebrowser-client.ts` `sanitizePath()` and any backend file operations. Can a crafted path escape the data directory? Write findings to an "RPC Security" section.
- [x] **Audit RPC endpoint security**: Review `core/archipelago/src/api/rpc/mod.rs` — the main RPC dispatcher. Document: (1) which endpoints require authentication and which don't? List any unauthenticated endpoints beyond `auth.login`, `auth.setup`, `auth.isSetup`, `auth.isOnboardingComplete`, (2) RBAC enforcement — was it wired up in Phase 6? If yes, verify it works. If no, document the gap and risk, (3) input validation — pick 5 critical endpoints (login, install package, factory reset, backup restore, identity create) and trace the input from RPC params to handler. Are inputs validated? Are there injection risks? (4) error message sanitization — does `sanitize_error_message()` strip file paths and internal details from user-facing errors? Test with a few error cases, (5) path traversal — check `filebrowser-client.ts` `sanitizePath()` and any backend file operations. Can a crafted path escape the data directory? Write findings to an "RPC Security" section.
- [ ] **Audit frontend security**: Review the Vue frontend for common web vulnerabilities. Document: (1) XSS — are any user inputs rendered with `v-html`? Search for `v-html` across all `.vue` files. If found, is the content sanitized? (2) CSRF — frontend sends `X-CSRF-Token` header on every RPC call. Verify this in `rpc-client.ts`. Is the token properly scoped to the session? (3) credential storage — what's in localStorage? Search for `localStorage.setItem` across all files. Are any secrets (passwords, keys, tokens) stored client-side? They shouldn't be — only session flags and UI preferences, (4) iframe security — `nostr-provider.js` uses `postMessage('*')` for responses. Is the origin validated on incoming messages? Check `AppSession.vue` and `AppLauncherOverlay.vue` message handlers — do they verify `event.origin`? (5) dependency audit — run `cd neode-ui && npm audit` and document findings. Write findings to a "Frontend Security" section.
- [x] **Audit frontend security**: Review the Vue frontend for common web vulnerabilities. Document: (1) XSS — are any user inputs rendered with `v-html`? Search for `v-html` across all `.vue` files. If found, is the content sanitized? (2) CSRF — frontend sends `X-CSRF-Token` header on every RPC call. Verify this in `rpc-client.ts`. Is the token properly scoped to the session? (3) credential storage — what's in localStorage? Search for `localStorage.setItem` across all files. Are any secrets (passwords, keys, tokens) stored client-side? They shouldn't be — only session flags and UI preferences, (4) iframe security — `nostr-provider.js` uses `postMessage('*')` for responses. Is the origin validated on incoming messages? Check `AppSession.vue` and `AppLauncherOverlay.vue` message handlers — do they verify `event.origin`? (5) dependency audit — run `cd neode-ui && npm audit` and document findings. Write findings to a "Frontend Security" section.
- [ ] **Assess custom code quality vs library alternatives — full comparison**: This is the core of the report. For each major custom module, write a comparison:
- [x] **Assess custom code quality vs library alternatives — full comparison**: This is the core of the report. For each major custom module, write a comparison:
**1. HTTP Server (custom hyper 0.14 handler.rs — 813 lines)**
- Quality: Hand-rolled routing, middleware, CORS, WebSocket upgrade. Works but brittle.
@@ -242,4 +242,4 @@
Write all comparisons to a "Custom Code vs Libraries" section with a summary table.
- [ ] **Write executive summary and next steps**: At the top of `docs/security-code-audit-2026-03.md`, write an executive summary covering: (1) overall security posture (1-10 rating with justification), (2) top 5 risks ranked by severity, (3) top 5 strengths, (4) recommended next actions (ordered by impact). Reference the `docs/refactoring-plan.md` 3-year plan for longer-term items. End with a "What to do next" section listing the 3 most impactful changes from this audit. Commit the report.
- [x] **Write executive summary and next steps**: At the top of `docs/security-code-audit-2026-03.md`, write an executive summary covering: (1) overall security posture (1-10 rating with justification), (2) top 5 risks ranked by severity, (3) top 5 strengths, (4) recommended next actions (ordered by impact). Reference the `docs/refactoring-plan.md` 3-year plan for longer-term items. End with a "What to do next" section listing the 3 most impactful changes from this audit. Commit the report.