Problem
Explorer can currently start with development or incomplete configuration. Examples include the default bucket name victoria-email-inbox, the default explorer-dev-session-secret, an empty S3 prefix, and blank AWS credentials that only fail when an S3-backed route is exercised.
Adding isolated local authentication introduces more load-bearing configuration: the selected auth provider, auth database location, cookie settings, and the writable persistent-state directory. A client deployment must fail closed at startup rather than boot in a partially configured state.
Desired behavior
Add explicit startup validation for production deployments. Development convenience may remain available only behind an explicit development mode; production must never silently inherit development defaults.
Validation should cover:
- A recognized auth mode (
elcano or local), with exactly one provider configured.
- Elcano mode: a valid Ed25519 public key and valid HTTPS login URL.
- Local mode: an explicit persistent database path with a writable parent directory and safe file permissions.
- A non-default, sufficiently random Explorer session secret.
- An explicit non-empty S3 bucket, region, prefix, and date-prefix format.
- A credential strategy that is internally consistent: AWS provider-chain/instance-role credentials by default, or a complete static-key pair when explicitly selected.
- Numeric bounds such as search days, body-search days, header bytes, and job timeouts.
- No secrets or raw credentials in startup errors or logs.
Update the systemd deployment to create and permit a persistent state directory for local authentication, preferably with StateDirectory=explorer and restrictive permissions rather than making the application tree broadly writable.
Acceptance criteria
- Production startup fails with a clear, non-secret-bearing error when any required setting is absent, malformed, contradictory, or still set to a development default.
- An unknown auth mode fails startup.
- Elcano mode cannot start without a valid verification key.
- Local mode cannot start without a safe writable persistent database location.
- Empty S3 bucket/prefix values fail startup instead of expanding the readable key scope.
- Boto3 can use the standard AWS credential provider chain when static keys are not configured.
- A partial static credential pair fails startup.
- The packaged systemd unit provisions a mode-0700 state directory writable only by the Explorer service account.
- Unit tests cover valid and invalid configurations for both auth modes.
- The bootstrap/update path validates configuration before restarting and preserves the currently running version when validation fails.
Security/operations impact
Fail-closed validation prevents a typo, missing secret, or incomplete deployment from becoming an authentication failure, connection to the wrong bucket, or unexpectedly broad S3 access.
Problem
Explorer can currently start with development or incomplete configuration. Examples include the default bucket name
victoria-email-inbox, the defaultexplorer-dev-session-secret, an empty S3 prefix, and blank AWS credentials that only fail when an S3-backed route is exercised.Adding isolated local authentication introduces more load-bearing configuration: the selected auth provider, auth database location, cookie settings, and the writable persistent-state directory. A client deployment must fail closed at startup rather than boot in a partially configured state.
Desired behavior
Add explicit startup validation for production deployments. Development convenience may remain available only behind an explicit development mode; production must never silently inherit development defaults.
Validation should cover:
elcanoorlocal), with exactly one provider configured.Update the systemd deployment to create and permit a persistent state directory for local authentication, preferably with
StateDirectory=explorerand restrictive permissions rather than making the application tree broadly writable.Acceptance criteria
Security/operations impact
Fail-closed validation prevents a typo, missing secret, or incomplete deployment from becoming an authentication failure, connection to the wrong bucket, or unexpectedly broad S3 access.