Bundle integrity and release trust

PAM separates application packaging from transport security and host hardening. A bundle proves its recorded file integrity; it does not replace a trusted release channel, secret management or operating-system isolation.

Build and package

pam build --entry public/index.php --output dist
pam package --entry public/index.php --output artifacts

pam build creates a relocatable directory containing the application, Composer dependencies, PAM runtime and matching private PHP runtime. Its manifest records sorted paths, sizes and SHA-256 digests. The launcher validates the bundle before application PHP starts.

pam package creates a versioned platform/architecture tar.gz and neighboring .sha256 file for server projects. It refuses to overwrite an existing archive. Native and Desktop projects delegate to their platform packagers.

Release gate

pam release --check
pam release

--check runs pam doctor --ci, pam lint, and pam test without creating a distributable. A full release runs the same gates and then packages. Native releases also execute the signing check before packaging.

Publish checksums through a trusted channel and verify them before extraction. Keep signing keys outside the project and CI logs. A checksum downloaded from the same compromised location as an archive does not establish an independent trust root.

Current security boundary

PAM 1.0 does not expose the former experimental pam sandbox, pam record, pam replay, signed-bootstrap-snapshot, supply-chain-policy or WASI/RPC commands. Do not copy 0.1.x examples into 1.0 automation. Use container/host sandboxing, Composer audit through pam composer audit, and application-owned incident capture where those controls are required.

For listener limits, TLS, trusted proxies, lifecycle and deployment guidance, continue with production and compatibility.