Dedicated onboarding site (onboarding.app.eva.fyi): admin adds a user → magic-link email → a set-password page → redirect to App Store / Play Store → log into the native app. Fully built; not yet live.
Code is done, but activation is owner/infra-only — DNS, a VPS Node service + nginx + TLS cert, a GoTrue env change + restart, and mail-auth DNS records. None of it is applyable from here.
51.77.146.158): DNS onboarding.app.eva.fyi → 51.77.146.158; Node server.js in /opt/eva-onboarding under systemd; nginx TLS front + certbot.supabase-auth): SITE_URL / URI_ALLOW_LIST / MAILER_EXTERNAL_HOSTS = onboarding.app.eva.fyi; API_EXTERNAL_URL = https://onboarding.app.eva.fyi/supabase → docker restart supabase-auth.+ include:spf.web-hosting.com), publish DKIM (default._domainkey from cPanel), add DMARC (_dmarc, p=none).set-password.html: SUPABASE_ANON_KEY, APP_STORE_URL, PLAY_STORE_URL.flutter.app.eva.fyi is the live Flutter web app — NOT the onboarding site; do not redirect invitees there. GoTrue currently sends fine (POST /invite → 200), but two things break it: (a) links point at http://51.91.52.165:3000 (Studio, raw IP) because SITE_URL/MAILER_EXTERNAL_HOSTS are wrong; (b) mail from hello@eva.fyi via premium911.web-hosting.com fails SPF + has no DKIM → Gmail spams/drops it. Two independent fixes: link (GoTrue + site) and delivery (DNS).
The remaining 16 Low/Info hardening findings from the EVA-Services security audit, after 6 fixes + 1 verified-safe landed this session.
Set aside to move to other work. All Low/Info — non-urgent, no exploitable defects.
Resume the Phase-3 batches — all writable locally + Mac-testable. IDs: SEC03-F2, SEC04-F1/F2, SEC06-F2, SEC07-F1/F2, SEC08-F2, SEC11-F1, SEC12-F1/F2, SEC13-F1, SEC15-F1, SEC16-F1, SEC18-F1, SEC19-F1, SEC02-F4.
RESOLVED 2026-07-29 — backend is now 36 fixed / 0 open, deployed through 0ec368e + migration 047 applied live. All 16 Phase-3 Low/Info + SUPA-001 (migration 046) shipped; none remain parked. EVA-Services/REMEDIATION-PLAN.html (36/36) · SECURITY-AUDIT-SUITE.html
eva-ctl)No automated path to apply a principal's newly-added OpenClaw integrations (edit mcp.servers in openclaw.json + restart) — the backend has no Docker/SSH reach into the OpenClaw container, and it's worse when OpenClaw runs on the principal's own VPS.
Needs a design session — no clean automated mechanism today for either managed or self-hosted OpenClaw.
Design the pull-based eva-ctl agent (polls for config, applies, restarts) covering both managed and self-host.
All code / finding remediation is done + deployed — backend 36/36; frontend Phases 1–5 shipped with AUTH-001 proven live in production; AUTHZ-002 closed; BUILD-002 build-verified. What remains is not code: owner execution, infra, one Supabase-admin action, and product decisions.
Each needs keystore/Play-Console credentials, infra (TLS/firewall), Supabase-admin key regeneration, or a product call — none applyable from the codebase.
evaHabile.jks + key.properties live in git history). Generate a new keystore, purge history (git-filter-repo/BFG + force-push, re-clone), reset the Play upload key. Step-by-step: android/KEYSTORE-ROTATION.md.PRINCIPAL_ID/dev-token clamp and Android FLAG_SECURE.:54321) over TLS (the web demo already uses the flutter.app.eva.fyi/supabase proxy). Infra.046 already makes the old one inert, so this is hygiene. Supabase admin.:54321, firewall :8000 (bureau is already unreachable off-box).8ba1139) and an invalid -- inside network_security_config.xml that broke every Android release build (94cef9a). BUILD-001 is the single hard blocker — and it gates the AUTH-002/PLAT-001 on-device pass. Deployed through backend 8ba1139; frontend geetansh.
Each principal’s OpenClaw gateway exposes an OpenAI-compatible API (POST /v1/chat/completions) on its own port (18789–18792), bound 0.0.0.0 with ufw inactive — so the ports answer from the public internet (verified 200 off-box). The gateway token is the only gate on driving that principal’s agent, which then acts as them via their MCP key.
Closing it is an infra/firewall action, not code. Token rotation (2026-07-30) fixed the shared-secret duplicate; it did not close the ports. Needs care not to break the bureau’s host-side reach at 172.17.0.1.
18789–18792 only from the Docker host / trusted IPs, deny public (ufw or the OVH network firewall).127.0.0.1:1879x / 172.17.0.1 in compose instead of 0.0.0.0 — the bureau reaches them via 172.17.0.1, nothing external should.:8000 and Supabase :54321 are also 0.0.0.0 + no ufw — one “lock down public ports” pass covers all three (ties to NET-001 / backend-firewall in the card above).curl :1879x → refused; bureau → container still works; chat + briefs unaffected.47c1d0d5… is dead (401). The bureau’s chat path talks to 172.17.0.1:18789 (host-side), so a public-facing firewall rule won’t touch it. This is the real hardening follow-up: rotation removed the shared secret, but a single token is still all that stands between the internet and each agent.
Connecting Google shows “Google hasn’t verified this app” (Advanced → “Go to EVA (unsafe)”) because the app requests restricted scopes (gmail.modify, drive.readonly) + sensitive calendar, and Google hasn’t completed OAuth app verification. Publishing to Production, verifying the domain, and the privacy Limited-Use disclosure are all prerequisites (done) — the verification request itself is not submitted. The screen persists until Google’s review clears; nothing code-side removes it.
Verification needs a demo video + an external CASA (Cloud Application Security Assessment, Tier-2) for the restricted scopes — weeks, an authorized third-party assessor, and a fee. Owner-driven; not code.
infra@habilesoft.com) — submit verification + engage CASA assessoreva-fyi in Production; domain eva.fyi verified (Search Console); privacy Limited-Use section live (eva.fyi/privacy §5, d3e6d7e); app name/logo/home/terms set.eva-demo-501310/Testing to a new project eva-fyi in Production; backend now on client 369984447159-… (.env swapped, eva-bureau restarted). Tokens no longer expire weekly. Google is now connector-only (removed from the auth page, 8fedce1); the multi-account connector (link several Workspaces) shipped (515c59c/2770b55). What remains is ONLY the verification screen — the full submission pack (app summary, 3 scope justifications grounded in EVA’s real API calls, demo shot list, CASA note) is written and ready. Interim: “Go to EVA (unsafe)” works; user cap 100 until verified.
Q6 — migration runner: adopt an automated migration runner + checksum/version table (currently 45 migrations applied manually via Supabase SQL). Owner: infra + backend.
Q7 — retention policy: define official retention for audio, transcripts, memory facts, drafts, audit logs, backups. Gates the SEC19-F1 data-export endpoint + SEC-11 retention jobs. Owner: product / compliance.
Translation correctness — French & German: the FR/DE translation keys on the landing page (src/locales/fr.json, src/locales/de.json) are not actually correct translations right now — they need a full native-speaker pass and correction. Owner: content/product for review, dev to apply.