Security and operation

This document accompanies Odexa v1.2 RC1 (1.2.0-rc.1). Current operator tooling explicitly runs 1.2.0-draft.3; the separate legacy service retains 1.2.0-draft.2. Test results apply to the named source/profile and do not constitute external security certification or approval of a production deployment.

Reporting a vulnerability

Report vulnerabilities privately to hello@odexa.org, with “Odexa security report” in the subject. The project owner has confirmed receipt of mail sent to this address and responsibility for monitoring it. No response deadline or round-the-clock coverage is promised. Include affected versions/profile, reproduction, expected/observed behavior, impact and a minimal synthetic example. Do not include secrets, live bearer tokens or personal records, or put an unpatched exploit against a third party in a public issue. Agree disclosure timing privately with the maintainer.

Delivery and monitoring were confirmed by the project owner on 21 September 2026. This is an operational contact confirmation, not a security audit.

Reference trust boundaries

• Origin HTTPS and its exact current policy/authority bytes appoint services. Failure, expiry, unsupported profiles and known rollback deny new access; a historical archive is never fallback authority.
• Agent assent and separately authenticated payer mandate are different actions and keys. Fixed-quote verification authenticates a provider assertion; it proves no debit or bank settlement. The bundled synthetic verifier is loopback-only and moves no money.
• Gateway completion is local transport testimony. Reporter signatures authenticate claims, not unobserved downstream use. Preserve unresolved admissions, queued reports and known missing duties.
• Archive public keys are untrusted unless independently pinned. Archive import is inert and cannot provision credentials or resurrect an agreement. Preserve exact original evidence through provider/key handover.

Deployment responsibilities and limits

Keep each operational/trust/archive directory private and owned by its operator. Back up databases, exact policy/authority history, original signed evidence and required key material consistently; restrict and encrypt backups according to their contents. Never publish an entire generated directory, commit private runtime files, reuse synthetic credentials across deployments or use init as a reset procedure. The initializer refuses nonempty directories; output commands refuse overwrites.

The adapter serves an exact route allowlist and one bounded reference resource. It checks the declared Host, duplicate/framing headers, request size and TLS; disables redirects and uses scoped credentials. Request bodies are bounded to 256 KiB, the reference article to 1 MiB, sockets time out after five seconds, and each listener admits at most 32 handler threads. There is no HTTP/2, transparent reverse proxy, public signup, multitenant administration, account recovery, scheduler, automatic certificate renewal or production denial-of-service guarantee. Put deployment-specific ingress, monitoring, backups, capacity limits and credential provisioning around the reference deliberately. Do not treat TLS-offloaded forwarded headers as origin authority without a separately reviewed adapter.

reports is an explicit outbox drain; an external scheduler may invoke it. Monitor queued/unresolved records and collector failures. Restart does not invent completion or retry a consumed gateway admission. Failure after a response write can leave an unresolved in-flight record. Static policy publication alone observes no traffic.

Current configuration is trusted local operator input. Generated local certificates are valid for two days; policy/authority for 24 hours. The service does not extend that validity automatically. Deployments must provide valid certificates, monotonically revised publications, fresh independent authority observations and explicit key transitions. Known compromised keys differ from retired keys. See provider handover before changing providers or signing identities.

Runtime and dependency inventory

Component	Declared requirement / purpose
Python	3.12+; HTTP/TLS, SQLite persistence, operator CLI and semantic validators
cryptography	>=50,<51; ES256 keys/signatures and local test certificates
setuptools	>=68 build backend; not a runtime service dependency
SQLite / OpenSSL	Supplied by the selected Python build; versions recorded with installation evidence
cffi / pycparser	Platform-dependent transitive cryptography dependencies; record resolved versions
Node.js	24 for the separate independent clients and managed storage executor; not required by the Python operator commands
AJV / ajv-formats	Independent development schema checks; not runtime service dependencies

The installation inventory records the exact executed Python/OpenSSL/SQLite and distribution versions plus wheel/source hashes. The package dependency range is not a universal lock file or assurance that future upstream releases are safe. Operators should resolve and retain a platform-specific dependency lock, track upstream advisories and rerun relevant conformance checks on upgrades. The integrated project review and technical corrections are complete. See release notes for the frozen edition and retained evidence.