Release integrity

Authenticated releases

EnigmaIS signs release metadata with a dedicated release key. The metadata binds the product, version, source revision, package hashes, and any production container image digests. Customer CA keys and licence-signing keys are separate from this release key.

Standalone production installations use sealed Python wheels and an offline dependency wheelhouse with pinned hashes. Upgrades install into a fresh versioned environment; switching the running service remains an operator-controlled maintenance step.

Startup verification

Production launchers verify the signed application inventory before entering the CA. Unknown signers, missing signatures, modified or missing files, injected files, symbolic links, and unsigned Python bytecode block startup. The inventory covers application code, shared CA code, portal assets, migrations, and release bootstrap code.

The producer’s licensing public-key ring is embedded in the signed application package. Changing or removing it blocks production startup. Licensing keys rotate through a new signed release; customers cannot substitute keys through configuration.

Remove the obsolete MYOWNCA_LICENSE_PUBLIC_KEYS setting from the environment, config.toml, and secrets.env. Any occurrence blocks startup, including empty or identical values and settings in development installations.

Configuration, databases, operational private keys, and logs remain mutable operational state. They are outside the developer-signed file inventory and need the appropriate host controls. Editable source checkouts are explicitly identified development installations; without an embedded licensing ring they have no trusted licensing keys.

Independent monitoring

Daily external checks continue to work when CA startup is blocked. Standalone deployments use a separate verifier environment; the container inspector checks the image digest and exported filesystem without executing code inside the target container.

A scheduled failure alerts operators without automatically stopping a running CA. Startup remains blocked until the installation is restored to a verified state. Configure an HTTPS alert destination, collect check records, and monitor for failed delivery and missing daily results.

Deployment responsibilities

• Authenticate the first verifier and public key independently of the downloaded release.
• Keep application code and trust anchors read-only to the CA service account.
• Monitor the host, interpreter, third-party dependencies, launchers, configuration, and verification tools as appropriate for the deployment.
• Test alert delivery, key rotation, recovery, and rollback before accepting a production installation.

These controls support PCI DSS integrity requirements. They do not establish PCI compliance or software certification. Requirement 11.5.2 includes critical-file change detection, personnel alerts, and comparisons at least weekly; startup checks alone do not provide that monitoring. Review the applicable scope and evidence with your assessor using the PCI SSC documentation.

An administrator who controls the host can replace the verifier and its trust anchors. Application integrity checks rely on those components being protected. The application’s docs/release-signing.md runbook provides release, installation, monitoring, and incident-response procedures. Contact EnigmaIS for evaluation access.