Deferred future option: secure multi-user architecture, gateway and identity

Deferred future architecture — current maintainer direction (30 October 2026). Joshua's immediate objective is excellent single-user, native, locally deployed scientific software adopted organically by his lab. Multi-user hosting, SSO, external gateway/Wolfi, public identity infrastructure and the B0–B7 security expansion are future options, not release gates or active dependencies. Do not implement or ask him to administer these now. Preserve existing local protections and address demonstrated vulnerabilities, but prioritise scientific validity (#64), workflow recovery (#66), selective validated statistics (#65), performance and usability. Revisit this architecture only after successful local uptake and Joshua's explicit choice. Earlier comments are historical exploration, not current implementation instructions.

Confirmed maintainer requirement — 2026-10-30

Owner clarification via Jonathan: Joshua has explicitly required MetaManifold to be a SECURE MULTI-USER SERVICE. This supersedes the former single-operator/optional-multiuser assumption in the planning text. We have not independently reviewed the maintainer's exact threat model or deployment architecture; do not guess its details. Do not treat multi-user security as an optional institutional extension or defer it until after other upstream features.

Consequences and critical path

Security architectural gate (before any claim of secure shared deployment): identify trusted ingress and authentication mechanism (reverse-proxy OIDC/SSO vs integrated identity, decided with Joshua), a trustworthy application principal and session/service-account model, and a default-deny route resource/action authorization matrix. Enforce backend-side; browser/UI hiding is no control. Avoid trusting arbitrary forwarded-user headers and process ENV USER.
Ownership and tenancy model: studies/projects/runs/reference libraries/job state/remote jobs/exports, cross-study sharing, administrators and collaborators. Explicit decision on which objects are public/shared vs private. Keep existing IDs/provenance wherever possible; migration/backfill for existing data cannot invent owners silently.
Execution and storage isolation: bind submitted and resumed jobs (fix(analysis): read R's NA as missing so parametric fits run #66) to authenticated principals and immutable permission context; prevent cancellation, reattachment, SSH-stage reuse, artifact fetch or deletion crossing tenants. Inspect OS/R/Julia shared runtime, filesystem permissions, DuckDB concurrency, shared temp/staging areas, remote SSH credentials, and output/caches for cross-user leaks. Some isolation guarantees may require per-user/per-job workers, not merely route-level access checks.
Audit and incident response: attributable append-only event records for reads of sensitive materials, writes, exports, authz refusals, deletions, remote job actions; metadata minimisation, tamper model, retention and failure behaviour; no claim that a local hash chain alone is attacker-resistant.
Resource controls: per-user and global quotas for body size, file uploads, running jobs, R/Julia concurrency, CPU/memory/disk, SSE connections, remote execution; ensure one user cannot trivially starve another.
Security and scientific tests: hostile cross-tenant fixture tests (IDOR, read/write/download/delete, job resume/cancel, reference changes, caches, reports, browser sessions), role-matrix tests, migration/rollback tests, secure transport/trusted-proxy tests, error redaction, logs; preserve existing provenance, integrity and analysis output. Keep Julia/R/bun pins and upstream contribution rules.
Access-control first, external availability second: exact PR slicing after Joshua approves architecture: (1) threat/deployment/tenancy contract + protected default, (2) trusted principal and session boundary, (3) central backend resource/action authorisation and storage/job ownership, (4) migration plus cross-tenant tests, (5) audit/quotas/operational hardening. This is a large programme. The upstream Notice to Project Owner: Comprehensive Review & Roadmap Status (2026-09-25) #64 statistical repro and fix: parametric fits run again; CI names failing assertions #65 port can progress in separate branches concurrently, but do not market the service as secure multi-user until the gate is passed.

Decisions genuinely requiring Joshua

Which identity provider/SSO and supported deployment topology?
Private-by-default vs shared-by-default study assets; who owns reference libraries?
User and service roles, group collaboration, administrator scope, permissions and tenancy boundaries.
Whether Julia/R/shell pipelines can be mutually isolated in the same OS process/service account; what trust level is expected among users?
Migration treatment for pre-existing unowned projects and remote jobs, and support/operational duties.
Resource quotas, audit retention, backup and recovery requirements.

Highest-priority warning: the old dossier labels 'no identity' critical only for its high-assurance target. The current maintainer requirement makes it a functional product blocker for secure multi-user deployment. No previous security dossier PR implemented these controls. Sensitive exploit specifics belong in private disclosure.

Purpose

Prepare a core multi-user security programme for upstream, distinct from the larger fork-only institutional classification programme. This issue is a public tracking record only; do not disclose working exploit chains or secret data here.

Existing work

Fork PR #295 merged a static security dossier and proposed remediation, not production security fixes.
Source: security dossier and proposal. Its assumptions and line references were prepared against earlier fork code; revalidate against current upstream and fork separately.
The fork contains DOI/Zenodo publication routes absent from Joshua's current upstream. Treat those as fork-only; never report them to Joshua as an upstream vulnerability.
Existing code has valuable path containment, Origin safeguards, AST validation, data-integrity checks. Preserve these and regression-test them.

Decision blocks to discuss with Joshua (one architectural discussion before PRs)

Block	Potential benefit	Acceptance/regression cost and risk	Initial boundary
S0: evidence + threat model	Clarifies what the local single-user tool is / is not defending	Maintainer review and careful terminology; no production change	Publicly discuss scope, privately disclose specific unpatched vulnerabilities
S1: HTTP hardening / bounds / egress validation	Reduces exposure to accidental network use, untrusted input and resource exhaustion	May disrupt remote use, upload-heavy datasets or existing lab configurations; benchmark real limits	Small, reversible patches + negative tests
S2: audit + recoverable deletion	Better provenance, incident recovery, accountability	Disk growth, privacy of logs, performance, durability/concurrency, data-retention obligations	Explicitly decide whether intended for his default deployment
S3: identity + scoped access	Makes shared/multi-user deployment safer	Significant change to 155-route model, host/proxy trust, UI and ops requirements; avoid spoofable proxy headers and treating ENV USER as a human principal	Optional deployment profile, owner approval first
S4: classification/retention/export	Useful for regulated institutional settings	Strong policy/operational overhead; accreditation belongs to the deploying institution	Fork/institution extension unless explicitly wanted
S5: security evidence CI	Gives falsifiable regression evidence	Runtime, false positives and dependencies; not a universal 'certified' score	Minimal tests first; optional separate scan lane

Important corrections before implementation

Loopback + environment flag does not by itself authenticate a reverse-proxy header: require enforced trusted proxy boundary.
A process's USER is not a human-user identity on a multi-user web service.
A local hash chain is tamper-evident only within its trust model; an attacker able to rewrite the entire log can recompute it. Consider storage separation/anchoring and durability tests.
Whole-disk encryption and legal compliance cannot be attested by source changes alone.

Acceptance

Ask maintainer which deployment contexts he wants to support and what friction budget is acceptable.
Verify findings against pinned upstream and fork commits, with safe fixtures; coordinate privately on sensitive cases.
Propose one logical change per PR, from current upstream main, no merge commits, verified signatures, passing pinned Julia/R/bun CI, no unapproved package/framework/lockfile/licence changes.
Offer concise benefit/risk/reversibility table to Joshua before implementing architectural blocks.
Bring accepted upstream commits back into the enhanced fork through focused fork PRs; record intentional differences, not perpetual failed sync.
Keep R1/R2/... institutional assurance labels as claims awaiting independent deployment evidence, not facts about a green CI run.

🔗 Related PRs

#295 - docs(security): publish the security dossier, standards assessment, proposal and remedy ultraplan [closed]
#304 - security(B0): read-only native Linux capability preflight [open]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

Architectural candidate, NOT chosen: Wolfi-backed OCI workers and optional VM isolation (2026-10-30)

Jonathan asks whether to secure supply chain via Wolfi containers / VM/hypervisor. Recommendation: evaluate, not wholesale migrate. Wolfi is a glibc-based minimal Linux userspace for OCI images (no kernel/hypervisor). It can improve package provenance/SBOM and image minimization, but does not itself implement authn/authz/tenant isolation. Container isolation shares a host kernel; VM-backed workers may be warranted where arbitrary user-controlled scripts/commands or mutually untrusted tenants are allowed. A trusted control plane and identity-bound durable jobs are prerequisites regardless of packaging.

Decision structure: trusted single operator vs untrusted tenants is settled in favor of secure multi-user; still ask Joshua precisely whether researcher uploads are only data/configuration or can include executable plugins/scripts, and whether existing remote SSH/HPC hosts and data storage are in-scope. Keep Oxygen/React/RCall/DuckDB constraints; avoid unrelated architecture changes in upstream.

Reversible pilot: create only one isolated representative pipeline-worker image behind an optional worker-executor seam, with exact pinned Julia 1.12.5 / R/tool compatibility or documented mismatch; use no production defaults yet. Compare current output hashes, datasets, memory/time and #66 detach/reattach/cancel semantics; subject to reviewed network, volumes, runtime uid, seccomp, capabilities, rootless user namespaces, no privileged mounts, no host socket, no cross-tenant shared mutable cache, scrubbed logs. VM-backed runner if model requires it; no Kubernetes prerequisite.

Supply chain gate independent of Wolfi: pin OCI images by digest and language packages via Manifest.toml/renv.lock/bun.lock, build from pinned sources, emit SBOM and provenance, sign images/attestations with verifiable CI identity (cosign), scan image vulnerabilities, and verify signatures/allowlist before workload execution. Wolfi has a rolling latest-package policy, potential tension with Joshua's immutable Julia/R/Bioconductor pins and scientific reproducibility; test support/patching availability rather than assuming secure = reproducible. Security updates require pinned version rebuild and scientific regression tests.

Critical decision: a hypervisor does not solve cross-user access control in application API, SQL, audit or browser; Wolfi does not remove work of isolating RCall/Julia processes or SSH credentials. Product core security is still a multi-stage project; optional worker isolation may reduce blast radius and be a safer design than full-framework replatforming. No container/VM implementation or benchmark performed yet.

References: https://www.chainguard.dev/docs/open-source/wolfi ; https://kubernetes.io/docs/concepts/security/multi-tenancy/ ; https://www.chainguard.dev/docs/chainguard/containers/faq ; https://docs.sigstore.dev/cosign/verifying/verify/ .

Deployment constraint confirmed: native Linux, no required VMs or containers (2026-10-30)

Jonathan relays Joshua's practical constraints: Joshua dislikes VMs (performance) and especially containers; typical Linux remote compute hosts cannot be modified at the hypervisor/kernel/runtime level, and the shipped application must run substantially as delivered. Jonathan personally favours containers, but that must not become an upstream deployment requirement. This supersedes the earlier suggestion that an OCI/Wolfi worker pilot should define the target architecture.

Adopt a native-first multi-user security design:

No mandatory VM, OCI runtime, Kubernetes, rootless Docker, kernel module, root access or privileged install. Keep existing pinned Julia/R/bun scientific runtime and Linux SSH/HPC execution. Optional image packaging/VM support remains outside critical path and must not be imported into upstream without approval.
Mandatory app control-plane security, regardless of packaging: verified login/session or trusted institutional proxy identity, fail-closed backend resource/action authorisation, ownership and sharing for study/run/reference data, durable owner-bound jobs (fix(analysis): read R's NA as missing so parametric fits run #66), access-controlled exports and cancellation, tenant-aware audit, quotas. Verify trusted proxy configuration and deny spoofable client headers. SSO/proxy or HTTPS ingress may need administrator-provided infrastructure; do not claim no-admin secure multi-user operation if those prerequisites are absent.
Native execution trust boundary: users submit inputs/parameters to an allowlisted scientific workflow. Explicitly decide whether they can execute arbitrary code or supply plugins. Without separate OS identities/sandbox/worker hosts, a shared Unix UID and interpreter process do not isolate malicious users. For arbitrary code require host-supported dedicated OS accounts/sandboxing or managed remote workers, or refuse the unsupported execution mode.
Opportunistic nonprivileged hardening, probed and tested: restrict worker directories and permissions, sanitized environment and secrets, guarded child process creation, no_new_privs, cgroups/rlimits when available, Landlock on supported kernels, bubblewrap/user namespaces only if usable without privilege and the operator accepts them. These are extra defence-in-depth, not substitutes for identities and cross-tenant policy. Missing essential security capabilities must fail a deployment acceptance check rather than silently downgrade.
BOINC lesson, not BOINC runtime: BOINC VirtualBox apps use VM checkpoint/restart, but cannot be transplanted without hypervisor support. Borrow the durable work-unit contract: stable identity, immutable input/config/tool hashes, explicit persisted state and output receipts, controlled retries, cancellation/reaping, checkpoint reuse when the scientific tool supports it (e.g. IQ-TREE), job reconstruction after server restart. No blind claim of arbitrary Julia/R process snapshotting.
Supply chain without Wolfi: signed native release archives, verified pin checksums, SBOM and provenance, hash-verified downloads, vulnerability triage against locked versions, release signing and verifiable staged update/rollback, plus pinned build/test attestations. This is useful even if no container image is ever shipped.
fix(analysis): read R's NA as missing so parametric fits run #66 SSH-specific: per-job unguessable ID, ownership, credentials, remote staging path and outputs must be isolated; no content-hash-only reuse across users (same input != same authority). Reattach/cancel may only act on the original authorised work unit. Remote hosts may lack setsid, nohup, cgroups, Landlock or user services; probe capabilities and offer safe supported modes.

Critical decision to obtain from Joshua: Is the required service multi-user with trusted scientific workloads restricted to supported commands, or multi-tenant with potentially untrusted user-supplied scripts/executables? What OS/proxy identity, TLS termination, Unix accounts and SSH boundaries are actually available? If shared-host constraints prohibit the required security invariants, report an unsupported deployment profile instead of weakening the definition of secure.

This remains a design and risk note, not a completed patch, tested sandbox, or maintainer-approved architecture.

Evidence: upstream src/server/jobs.jl currently declares an in-memory, single-user store and has no user principal on Job; src/pipeline/remote_exec.jl SSHes into staging dirs with random names and cleanup traps; start.sh launches Julia natively. External references: BOINC VirtualBox, Linux Landlock, bubblewrap.

Native Linux security architecture v0.2 — host capabilities, protocols, crypto, delivery blocks (2026-10-30)

Constraints supplied by Jonathan from Joshua: secure multi-user service is mandatory; existing Oxygen.jl/React 18/RCall/DuckDB/scientific pipeline retained; Linux user-space deployment and SSH remote execution; no required VM, container, hypervisor access, kernel/reboot or root configuration. This is a proposal for maintainer review, not an accepted design or completed validation.

Authority matrix (do not conflate)

Mechanism	Who controls it	Proposed use / scope
Backend identity, per-study/run/job/resource authorisation, sessions, CSRF, audit, quotas, error redaction, output access and app headers	Application	Required and testable under current stack. Origin/CORS is not authentication; default-deny for sensitive operations.
Native release pin verification, SBOM/SPDX, SLSA provenance, archive signing/verification, rollback and pinned hash checks	Builder and installer	Required for supply chain; no OCI needed. Hashes alone verify integrity against a known digest, not authenticity of the publisher without trusted signed provenance.
Landlock (filesystem restrictions; supported network operations), `no_new_privs`, RLIMITs, strict umask, private tempdirs, per-job resource quotas	Application may activate when kernel supports	Prefer for native workers, with audited capability probing and negative tests; Landlock policies are additive to DAC/SELinux; sandbox must be applied before untrusted execution and subprocess creation. Do not rely on Landlock/rlimit alone against shared-UID malicious code or as full multi-tenant isolation.
SELinux enforcing mode, real confined type/domain, AppArmor host profiles, cgroup v2 delegation, per-user OS accounts, system service permissions	Host admin/operator	Supported integration profile; detection and verification by application. `getenforce=Enforcing` does not mean the Julia process is confined in an appropriate domain. Installing SELinux policy, relabeling paths and switching modes is an admin/deployment task. Never attempt `setenforce` or broadly disable SELinux from the application; test actual process labels and access denial. Offer equivalent AppArmor/other available LSM profiles where SELinux absent. No compulsory elevated privileges.
HTTPS ingress, DNSSEC/CAA/TLSA/DNS records, trusted reverse-proxy identity, domain `.well-known`	Host/domain operator or jointly managed deployment	App can provide secure responses and `.well-known/security.txt` if routed to it, but cannot set DNS records, configure upstream TLS or claim HSTS enforcement across proxy without hosting cooperation. Provide verification checks and deployment documentation.
Host OS firewall, kernel lockdown, LUKS/FDE, backups, host auditd, security updates, SSH daemon config	Host admin	Deployment evidence/attestation, not falsely claimed application feature.

Three noninterchangeable deployment gates

Compatible trusted ingress: genuine HTTPS (including when behind proxy), authenticated OIDC/SSO with validated issuer/audience/expiry/nonce and a secure session, or an explicitly configured trusted upstream authenticator with anti-spoof boundary; backend authority checks mandatory regardless. If identity/TLS boundary unavailable, do not offer secure multi-user network service.
Permitted scientific execution: users submit validated data/parameters to an allowlisted fixed workflow. If arbitrary scripts/executables are permitted, require a verified host-provided isolation boundary (separate OS accounts/workers or host-managed isolation), otherwise refuse that execution capability. Running all tenants' arbitrary code in one shared Unix UID cannot be deemed isolated by using SELinux in a generic domain.
Tenant-aware storage and remote execution: every study/run/job/remote stage/output/cache/exports/DOI action tied to an authenticated resource principal and access policy. Random directory names and content hashes do NOT establish access authority. Plan migration of legacy unowned assets.

Cryptography: fit to protocol and purpose rather than choosing unusual primitives

Network: use established TLS 1.3 implementations at host ingress or an explicitly supported direct TLS endpoint. Never invent a bespoke E2E transport protocol. Application must enforce secure-cookies (HttpOnly, Secure, SameSite), session rotation, CSRF protections, status-coded refusals and cache controls.
SSH: keep OpenSSH and strict host-key verification. Probe negotiated PQ-hybrid key exchange, prefer mlkem768x25519-sha256 or sntrup761x25519-sha512 on compatible servers; ML-KEM-1024 exists in newer RFC 10042 hybrid variants but do not assume the upstream server supports it. No silent fallback if future policy requires PQ transport. Never ship StrictHostKeyChecking=no.
Signing: Ed25519 is a practical well-supported current option for release/identity signatures where the ecosystem supports it. Ed448 is classical and not a quantum-resistant upgrade; ML-DSA (formerly Dilithium; FIPS 204) is a separate future profile, conditioned on compatible mainstream libraries/verifiers, not a custom implementation.
Hashing and KDF: preserve SHA-256 already used for input/provenance pins; BLAKE3 can be a performance experiment for internal content hashes but is not needed for security and MUST NOT silently change established IDs/attestations; SHAKE is an XOF, not a general replacement for passwords, digital signatures or transport encryption. Use established standard AEAD, KDF and OS cryptographic randomness; no home-made cryptography.
True E2EE: conflicts with ordinary server-side analysis when server must read data. Provide TLS-in-transit + appropriate at-rest encryption and per-tenant access by default; genuine client-side E2E requires different processing/delegation architecture and should be explicitly scoped, not falsely advertised.

HTTP/DNS/security.txt realities

App can ship route-uniform Content-Security-Policy (notably frame-ancestors 'none', tuned for Vite build), X-Content-Type-Options: nosniff, Referrer-Policy, privacy-sensitive Cache-Control: no-store, cookie attributes, uniform API errors, safe CORS, request/body/upload bounds, rate limits and safe SSE limits; assert via tests against HTML, JSON, file downloads, error responses and redirect responses. HSTS only on correct HTTPS deployment, coordinated with proxy.
/.well-known/security.txt (RFC 9116) is helpful if MetaManifold controls the origin/domain and has a maintained disclosure contact; optional for shared hosts. DNS CAA/SSHFP/TLSA/DNSSEC/HSTS preload depend on domain/hosting governance and do not replace application authn/authz. Avoid unrelated .well-known endpoints.
Traceable authenticity for files should use signed checksums/provenance, not domain DNS assumptions alone.

Ordered blocks (some parallel)

B0 — baseline and deployment contract [FIRST]: small, read-only, nonprivileged capability report: getenforce, process SELinux context, LSM list, Landlock support, AppArmor, no_new_privs/rlimit, cgroup delegation, uid/gid/umask, TLS/identity boundary, SSH implementation+negotiated KEX, secure storage, ciphers and support; machine-readable evidence with careful redaction and manual operator attestations. Never assume these from distro name.
B1 — HTTP + installation hardening [FIRST, parallel B0]: security headers and CSRF/cookie tests, caps, release verifier/signatures/SBOM seed, secure deployment preflight (no privileged changes); preserve current host+origin validation.
B2 — identity/authorization [FIRST ARCHITECTURAL GATE]: explicit session/principal, resource-action policy, unowned-data migration design, cross-tenant refusal tests, safe account provisioning and TLS trusted-proxy options.
B3 — durable owned jobs and SSH recovery [after B2 design]: fix(analysis): read R's NA as missing so parametric fits run #66 stable job ID vs content digest; detached native remote stage, state machine, ownership, cancellation, verified file transfer and tools/checkpoint semantics; old running state reconciled. No data reuse across tenants without explicit consent/policy.
B4 — data and native-worker isolation [with B3]: private tenant-scoped output/cache paths, permissioned storage API and DB access, verified subprocess permissions and host-account strategy, Landlock integration if supported, tool/data path sandbox negative tests. If host cannot supply required isolation for allowed workload, refuse secure profile.
B5 — durable audit/quota/incident/retention [parallel B2–B4]: authenticated event receipts and tamper-model, global and per-principal job/upload/SSE limits, cancellation/error semantics, recoverability, backup/restore, deletion consistency and alerting. Audit should not expose secrets/raw research data.
B6 — signed native supply-chain/releases [parallel B1–B5]: verify lock and binary tool pins, archive checksums plus signatures, SBOM/SPDX, SLSA provenance as supported, vulnerability triage, release verification instructions, no forced containerization. Preserve reproducible science with explicit update policy.
B7 — enhanced deployment profiles [LATER]: tested SELinux policy package/admin guide, alternative AppArmor integration, optional delegated cgroup/service hardening, host-managed TLS / DNS hygiene, PQ profile if compatible; no unconditional requirement that a nonprivileged user install policy.

Release gate: do not claim "secure multi-user" until a real cross-user threat model, authn/authz, identity-bound long-running jobs, storage isolation, ingress, negative tests, incident/accountability and executable-workload boundary all pass; enforce unsupported deployment refusal. All findings from static sources require runtime validation on actual supported Linux hosts.

Grounding: fork security dossier PR #295; current upstream jobs.jl says single-user in-memory and stores no principal; remote SSH staging is transient in remote_exec.jl; upstream request path Origin/host checks are useful but incomplete. Relevant authoritative sources: Red Hat SELinux docs https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_selinux/getting-started-with-selinux_using-selinux ; Linux Landlock https://docs.kernel.org/userspace-api/landlock.html ; OWASP headers https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html ; OpenSSH PQ https://www.openssh.org/pq.html ; SSH hybrid RFC 10042 https://www.rfc-editor.org/info/rfc10042/ ; RFC 9116 https://www.rfc-editor.org/info/rfc9116/ ; FIPS 203,204 https://csrc.nist.gov/pubs/fips/203/final https://csrc.nist.gov/pubs/fips/204/final ; SLSA https://slsa.dev/spec/v1.0/ .

Zero-trust feasibility and UX / algorithm performance impact — 2026-10-30

Decision: adopt zero-trust principles for the app's resource and workflow boundary, not an unsupported claim of complete host/device zero-trust assurance. Current native-Linux/no-admin/no-container/VM constraints remain. NIST SP 800-207, NCSC ZTA principles and OWASP's authorization/multi-tenancy guidance are relevant: https://csrc.nist.gov/pubs/sp/800/207/final ; https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles ; https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html .

Trust boundaries

Existing: browser -> Origin/Host guard -> unauthenticated Julia routes -> shared in-memory JobQueue -> Julia/R/SSH -> shared storage. Network reachability and shared process account confer too much implicit authority.
Target: verified IdP/SSO+MFA / trusted HTTPS ingress -> short, secure user session -> backend principal with typed tenant+resource+action authorization at every protected object read/write -> explicitly scoped study/run/data access -> durable, owner-bound job manifest and policy/version binding -> authenticated least-privilege worker/SSH identity -> tenant-scoped files, results, caches, events, exports, audit. New service connections must have independently verified endpoints; signed artifacts and attestations support supply chain, not access authority.
Continuous verification: policy evaluation at requests and relevant long-job transitions (start, resume, cancel, result retrieval, export), versioned decisions, revocation plan, non-bypassable entry points and negative cross-tenant tests. No need to pop MFA for every API call.
Limits: can verify substantial app/data/job zero-trust behaviour; cannot independently attest researcher devices, host root/hypervisor, arbitrary executable isolation under a shared Unix UID, server TLS proxy identity, or remote SSH host operator controls. Document essential deployment prerequisites; refuse unsupported untrusted-code mode.
No arbitrary cryptography upgrades: standard TLS, OpenSSH/negotiated PQ hybrid if available, trustworthy signatures and SHA-256 pinning. Avoid claiming E2EE while server analyses plaintext.

User experience contract

Researchers get single sign-on/passkeys/MFA when risk warrants, see their studies/explicit collaborator sharing, per-job progress, recovery after browser disconnect, clear permission/quota failures, and an attributable activity trail; no repeated security prompt for routine actions. Existing unowned studies need deliberate safe migration. More explicit refusals and queueing are real changes; don't present every refusal as an error in analysis.
Library/reference trees may be intentionally shared; study-specific observations and saved evidence must be scoped. Distinguish institution/workspace/tenant, group and individual permissions; don't infer that all studies are private if the scientific workflow requires collaboration.
If IdP temporarily unavailable, reject new sessions; for already admitted long-running compute jobs, define continue/pause/cancel and prevent unauthorised output disclosure. Never make IdP outages silently turn into access bypass.

Scientific and performance invariants

Numerical semantics: exact same validated input bytes, tool/algorithm versions, parameters and seeds should feed unchanged algorithms; security envelope is not a correction to Notice to Project Owner: Comprehensive Review & Roadmap Status (2026-09-25) #64's statistical calibration nor proof of biological correctness. Test independently whether outputs remain scientifically equivalent, including floating point/non-deterministic runs; don't demand byte-identical metadata, timestamps or platform-dependent artifacts.
Performance hypothesis (UNMEASURED): auth/policy lookup and append-only journal add per-API/transition overhead; TLS handshake amortises on persistent connections; indexed/transaction-scoped checks should not be in per-read/per-nucleotide/PCR hot loops. The expensive changes may be queued-job contention, process startup/RCall reinitialisation, repeated large FASTQ hashing, extra staging I/O and storage encryption; quotas reduce bad tail latency and crashes but may add legitimate wait time. Same computation should have broadly similar compute time if we retain native worker, avoid extra copies and preserve hardware/threading. No numeric speed claim until measured.
Measurement gate: pinned data+seeds/hardware and unchanged reference binaries; API p50/p95/p99 for list/download/submit, cold/warm auth, single and 2/5/10 concurrent researchers, wall time and CPU/RSS/IO for DADA2 and IQ-TREE, queue wait, resume after failed SSH and server restart, result parity, multi-tenant error leak/IDOR tests, denied requests, audit and revocation latency, failure/recovery drills. Report throughput and tail latency separately from algorithm compute time. Explicitly test a malicious or accidental "noisy neighbour."
Formal proof opportunities: independently reusable finite policy resource/action matrix (default deny), typed job state transitions and noninterference/refusal properties in Agda; implementation parity tests at Julia/HTTP/DB boundary. Model proofs do not prove host or Julia semantics.

Timing relative to B0–B7

B0 deployment/identity/workload trust model and baseline measurements first; B1 lightweight HTTP hardening plus baseline; B2 verified identities and authorisation first release gate; B3 durable SSH jobs and B4 owner-scoped storage/compute must meet cross-tenant negative tests; B5 audit/quotas and B6 native-supply-chain can proceed in parallel. B7 host-admin SELinux integration is an additional assurance profile, not a substitute for B2–B4 or a default prerequisite on incompatible hosts.

Status: architecture/measurement proposal, no implementation or benchmark claimed.

Implementation started — B0/B1 draft PRs (2026-10-30)

B0 / fork draft PR #304: native, nonprivileged read-only Linux preflight (scripts/security/linux-preflight.sh, test, README). Shell syntax and smoke/format test passed in a separate Linux execution environment; Julia/R scientific suite not locally available. Reports global SELinux mode separately from process confinement, and treats LSM/Landlock/cgroup observations conservatively. This is not a runtime enforcement or secure-host certification. Fork PR automated checks currently in progress; commits unsigned.
B1 / fork draft PR #305: adds a narrowly scoped response middleware for X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, X-Frame-Options: SAMEORIGIN plus regression tests across API 200, missing-file 404, Origin 403 and preflight 204. Preserves upload-specific CSP and existing CORS. No changes to algorithms, packages or host settings. Julia tests have NOT completed; no execution guarantee until CI. Review browser embedding before upstream transfer; draft/fork-only, unsigned commits.
B2 still first architectural gate: trusted identity/TLS boundary, principal/session policy, sharing and ownership model, remote worker OS account/credential model and whether user-controlled executable code exists; decisions belong with Joshua. B0/B1 do not make current server secure multi-user.
PR test(estimation): use an over-dispersed fixture for the NB fits #67 remains separate: statistical reproducer review addressed, latest upstream CI green, signing blocker on its commits remains; see Coordination: upstream/fork contribution register, accepted differences and cherry-pick gates #302.

Do not attempt to merge either draft before its own checks and explicit owner review; GitHub API-produced commits need local signing for Joshua's upstream rules.

Confirmed maintainer requirements — institutional SSO, authenticated jump/proxy, optional WireGuard (2026-10-30)

Jonathan reports Joshua's current intended deployment:

Institutional SSO for researcher identity (provider-specific issuer/claims not yet chosen).
Only approved scientific workflows submitted via validated data and parameters. Researchers must NOT be given arbitrary shell/R/Julia plugin execution by the web API.
Authenticated access via a jump server / institutional reverse proxy, with WireGuard or an equivalent approved private-access transport where available.
Native Linux and SSH hosts, with no mandatory container, VM, hypervisor or host-admin permissions; existing scientific toolchain/pins preserved.

These are design requirements, not proof that any corresponding protection has shipped.

Separate the three channels — all must be modelled

Browser → application: institution SSO (prefer OIDC Authorization Code + PKCE at an approved proxy, with secure managed session; institution-specific SAML may be terminated at the trusted proxy if required). Application validates a correctly authenticated, nonspoofable principal/claim from a proven trust boundary, maps immutable subject + issuer to a local principal, then applies resource/action authorisation on every study, run, file, job, event, export and administrative action. Email/display name is not a stable identity key. Configure claim trust and role/group mapping; group changes/revocation have an explicit freshness contract.

Ingress proxy/jump host: no direct alternate reachability to an unauthenticated MetaManifold backend. Use loopback/Unix socket when proxy co-resident, otherwise a verified mutually authenticated secure channel to the backend; strictly pin trusted proxy peers and reject/strip arbitrary X-Forwarded-*, X-User, X-Email and similar client-supplied identity headers. Never accept X-Forwarded-User solely because a header exists. If intermediary only transports opaque TLS, the backend must itself authenticate (TLS passthrough does not produce trustworthy headers). An institution's proxy must preserve SSE, large FASTQ uploads, PDF/report downloads and correct Origin/HTTPS redirect handling.

Scientific controller → remote compute host: use standard OpenSSH host-key verification and ProxyJump/-J or approved SSH ProxyCommand as configured in the worker's SSH client profile. ProxyJump authenticates and tunnels to the compute host, not researcher SSO. Do not forward SSH agents/private keys to the jump server by default. Bind SSH credentials and remote job IDs to authorised study/job context. Test loss of connection through the jump host, cancellation, output reattachment, expiry and shared-host staging ownership (#66).

WireGuard: an optional institution-controlled private network access lane, using peer keys and restricted routing. Peers/devices are not human researchers and are not a substitute for SSO or backend study authorisation. No requirement that MetaManifold can install WireGuard, create a network interface or gain kernel/network admin rights; application connects to an endpoint provided by the host/network operator. A userspace VPN alternative must be explicitly approved and measured if chosen. WireGuard can coexist with SSH ProxyJump; don't require both by default.

Supported patterns to test

A. browser -> institution HTTPS/OIDC-authenticated proxy -> loopback MetaManifold -> owned jobs -> native SSH.
B. browser -> approved private network/WireGuard -> institution proxy/SSO -> MetaManifold.
C. MetaManifold -> OpenSSH ProxyJump -> remote Linux compute account; can coexist with A/B.

Immediate acceptance checks / implementation sequencing

B0: document actual ingress/proxy and SSH jump capabilities in read-only preflight; separately record whether WireGuard routing is a configured service—not from kernel advertising alone.
B2 (critical): design a two-way boundary contract (proxies that can assert identity and direct OIDC integration) + typed principal/tenancy/role model with deny-by-default. Cross-tenant negative tests for every route; deny on absent/forged/stale identity and any direct bypass. Browser SSO/session/login/logout and service-to-service credential separation.
B3 fix(analysis): read R's NA as missing so parametric fits run #66: durable jobs and remote SSH through jump host; verified remote host keys, loss/recovery semantics and authorisation to resume/abort/retrieve; no SSH private key or user token in persisted job record.
B4/B5: tenant-scoped files/results/streams/audit, quotas and revocation; proxy setup tested for streaming and uploads.
B6: native signed supply chain remains unchanged by choice of VPN or proxy.

Need from Joshua/institution before coding SSO integration: OIDC vs SAML providers, issuer/tenant identifiers and issuer discovery URLs (never secrets), stable subject and group claims, which component terminates TLS/OIDC, whether a proxy and backend can be bound by Unix socket/loopback or mTLS, whether SSH jump is shared with web ingress, which standard host/network deployment capabilities are available. Implementation must remain generic (no OU-specific or Hypatia-specific identity code).

References: OWASP multi-tenant, OAuth2 Proxy trusted upstream headers, Keycloak proxy-headers guidance, OpenSSH ProxyJump, WireGuard.

Open scientific participation is a core design constraint (2026-10-30)

Jonathan relays a crucial aspect of Joshua's open-source mission: MetaManifold must not make affiliation with, or privileged access rights at, an institution a precondition for participating in scientific investigation. Independent researchers, artists, educators, learners and young people should have credible routes to using supported scientific tools and knowledge. The threat model is serious, but it must not be mistaken for an institutional-membership eligibility rule.

Architectural correction: institutional SSO remains a required supported deployment option, but must not be the sole architecture or a hard dependency across all deployments. Define a provider-neutral verified principal/session and resource-action authorisation contract; support trusted institutional OIDC/SAML-at-proxy where available and an independently operated sign-in mechanism (e.g., standard OIDC provider or passkeys) for noninstitutional/community deployments, without bespoke authentication cryptography. No one gets unauthorised study access by virtue of affiliation, and lack of affiliation is not itself grounds to deny a locally authorised account. Users can retain account identity across providers only via explicit, verified account linking; never infer identity from equal email strings. Hosts may still have their own licensing, capacity, institutional policy and dataset restrictions; open-source code does not imply that every institution must fund unlimited public compute.

Separate policies explicitly:

Participation/registration eligibility (deployment operator's published access rules, with noninstitutional options in the ecosystem).
Identity assurance (actual user, session, login method, verified issuer; institutional SSO is one option).
Research-resource authorisation (study, data, job, export, collaboration and admin rights).
Compute entitlement and fair use (quotas, concurrency, access to expensive resources; resource limits should be transparent, reviewable and not disguised as scientific merit).
Content and learner safety (privacy by default for minors and learners, age-appropriate controls and accessible UX, no needless identity collection, community/supervised education modes as appropriate; confirm legal and institutional requirements before implementation).

Useful tiers of deployments, not unequal scientific correctness: public documentation and synthetic-data demos; optional hosted community service with fair compute budgets; self-hosted native deployment; institutional deployments with SSO and restricted data. Wherever the same approved workflow, toolchain and input contract is available, scientific result semantics must not depend on social status, account type or authentication method. Restricted datasets/expensive institutional clusters may have separate justified policies.

Gateway design: Wolfi gateway is optional and independently reusable, not tied to any university IdP or single commercial login provider; an accessible gateway can route researchers to approved public/community/self-host services while respecting private university networks. Proxy and WireGuard authenticate network paths, not someone's eligibility to do research.

First test/acceptance requirement for B2: include at least two login-source fixtures (institutional researcher and noninstitutional researcher) that map to equivalent local permissions for an explicitly shared project, plus negative cross-tenant and revoked-account tests. Authorization depends on resource grants, not an institutional=true predicate. Document migration/account linking and the experience when an IdP is unavailable.

This is a foundational design requirement; not a claim that public hosting, compute funding, minor onboarding or noninstitutional login have already been implemented or approved by Joshua. Reconcile detailed hosting policy with Joshua without overfitting independent authentication into an institution-only deployment.

Navigation Menu

Repository navigation

Deferred future option: secure multi-user architecture, gateway and identity #301

Confirmed maintainer requirement — 2026-10-30

Consequences and critical path

Decisions genuinely requiring Joshua

Purpose

Existing work

Decision blocks to discuss with Joshua (one architectural discussion before PRs)

Important corrections before implementation

Acceptance

Architectural candidate, NOT chosen: Wolfi-backed OCI workers and optional VM isolation (2026-10-30)

Deployment constraint confirmed: native Linux, no required VMs or containers (2026-10-30)

Native Linux security architecture v0.2 — host capabilities, protocols, crypto, delivery blocks (2026-10-30)

Authority matrix (do not conflate)

Three noninterchangeable deployment gates

Cryptography: fit to protocol and purpose rather than choosing unusual primitives

HTTP/DNS/security.txt realities

Ordered blocks (some parallel)

Zero-trust feasibility and UX / algorithm performance impact — 2026-10-30

Trust boundaries

User experience contract

Scientific and performance invariants

Timing relative to B0–B7

Implementation started — B0/B1 draft PRs (2026-10-30)

Confirmed maintainer requirements — institutional SSO, authenticated jump/proxy, optional WireGuard (2026-10-30)

Separate the three channels — all must be modelled

Supported patterns to test

Immediate acceptance checks / implementation sequencing

Open scientific participation is a core design constraint (2026-10-30)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Deferred future option: secure multi-user architecture, gateway and identity #301

Description

Confirmed maintainer requirement — 2026-10-30

Consequences and critical path

Decisions genuinely requiring Joshua

Purpose

Existing work

Decision blocks to discuss with Joshua (one architectural discussion before PRs)

Important corrections before implementation

Acceptance

Activity

coderabbitai commented on Oct 30, 2026

hyperpolymath commented on Oct 30, 2026

Architectural candidate, NOT chosen: Wolfi-backed OCI workers and optional VM isolation (2026-10-30)

hyperpolymath commented on Oct 30, 2026

Deployment constraint confirmed: native Linux, no required VMs or containers (2026-10-30)

hyperpolymath commented on Oct 30, 2026

Native Linux security architecture v0.2 — host capabilities, protocols, crypto, delivery blocks (2026-10-30)

Authority matrix (do not conflate)

Three noninterchangeable deployment gates

Cryptography: fit to protocol and purpose rather than choosing unusual primitives

HTTP/DNS/security.txt realities

Ordered blocks (some parallel)

hyperpolymath commented on Oct 30, 2026

Zero-trust feasibility and UX / algorithm performance impact — 2026-10-30

Trust boundaries

User experience contract

Scientific and performance invariants

Timing relative to B0–B7

hyperpolymath commented on Oct 30, 2026

Implementation started — B0/B1 draft PRs (2026-10-30)

hyperpolymath commented on Oct 30, 2026

Confirmed maintainer requirements — institutional SSO, authenticated jump/proxy, optional WireGuard (2026-10-30)

Separate the three channels — all must be modelled

Supported patterns to test

Immediate acceptance checks / implementation sequencing

hyperpolymath commented on Oct 30, 2026

Open scientific participation is a core design constraint (2026-10-30)

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions