Signing and verification

Every Package must be signed before it can be installed. The signature proves the file hasn't been changed since a particular Organization signed it.

Keys

• Each Organization has an ed25519 signing key pair, created automatically the first time it signs.
• The private key is stored encrypted in the Organization's vault. Nothing (no API, no page, no command) returns it. It can only be used to sign.
• The public key is shared as a document of type elizon.signing-public-key.v1, which carries the key, its id (ed25519:<32 hex characters>) and the Organization's name.
• When a key is replaced, the old public key is kept, so artifacts signed before the change still verify.
• Export the public key with target key to give to Organizations that install your Packages.

Signing

build produces an unsigned artifact. sign then:

1. re-hashes every entry and checks it against .elizon/digests.json, offline,
2. sends only .elizon/digests.json (a list of hashes) to the Organization,
3. receives a signature over exactly those bytes, plus the public key,
4. appends .elizon/signature.json without touching any other entry, and verifies the result before writing it.

The .pkg never leaves your machine, and the key never leaves the Organization. Because the digest manifest covers every entry, the signature covers the whole Package.

Verification

Verification needs only the file and a set of trusted public keys, no network. The Review step in Studio and install both verify before anything is installed. There are four outcomes, and each asks for a different action:

Whom you trust

Every Package is self-signed. There's no registry or certificate authority, so "is the signature good?" and "do I trust this signer?" are separate questions. Only the first is maths. After verification, Elizon shows who signed it:

Self-signed by "Acme Ltd" (key ed25519:4f2c…). The name is the signer's own claim; no registry has counter-signed this Package.

An installing Organization trusts, and nothing else:

1. its own keys, current and past, so a Package you signed yourself installs with no extra step, and
2. public keys you add explicitly: Add signer's public key on the Review step, or --trust=<file> with the CLI.

A Package can't supply its own verification key, because a file that vouches for itself proves only that it's internally consistent, which a tampered file also is.

For installing a Package signed by another Organization, see Sharing across Organizations.

Pinning a signer

A manifest may set signature.signerKeyId. The Package then verifies only with that key, which is useful when you want an artifact to be rejected if anyone else re-signs it.