Appliance signing keys

If you’ve received a qRaptor appliance export — a sealed archive meant to run on your own infrastructure — this page is how you confirm it genuinely came from qRaptor before you install it.

⚠️

Never take a verification key from inside the archive you’re checking. A tampered archive could ship its own matching fake key and still “verify” — that’s exactly the attack this page exists to prevent. Always get the release key from here, independently of the file you’re checking.

Two keys, one argument

qRaptor signs every export with two keys:

	Signs	Proves	You use it
Release key	`manifest.yaml` — every configuration file, the roles, permissions and governance rules, and the exact digest of every image	The archive is what qRaptor sealed, and it runs exactly those images	Pass it to `verify.sh` and `install.sh`
Image key	Each container image, including the app images built for your export	Each image itself came from qRaptor	Nothing to pass — `install.sh` uses it automatically

You only ever pass the release key. The export records the image key inside the manifest that the release key signs, so once the release signature checks out, the image key is trusted too. The image key is published below so you can compare its fingerprint, or use it with your own tooling — for example a Kubernetes admission policy.

The registry pull credential is not a key. It only lets Docker download your project’s images and proves nothing about integrity — a leaked one can’t make a tampered archive pass. Mint it from the export’s page right before you install; it lasts 3 days.

Release key


Fingerprint	`sha256:44beb2facaf3c964f8114356d7478fa511962411c5c56484999a6a012541ada2`
Algorithm	Ed25519


-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEACFfpmKA+lu/QR8rKdIPPAvnozM0KHsbjKqfW6ZI3sbw=
-----END PUBLIC KEY-----

Save it as a file and pass it to both scripts:


./verify.sh  /path/to/qraptor-release.pub
QR_REGISTRY_USERNAME='robot$…' QR_REGISTRY_PASSWORD='…' ./install.sh /path/to/qraptor-release.pub

Also set it in .env so the running appliance re-checks its own archive at every boot:

QR_RELEASE_PUBLIC_KEY — the key itself (the PEM text above), read by the appliance’s auth service.
QR_RELEASE_PUBLIC_KEY_FILE — the path to the same file, so you can run the scripts without the argument.

Image key


Fingerprint	`sha256:22b948448d2ff3f6c2fa6143780fb875943c31dd6dc811b5f17e9d669b0483cf`
Algorithm	ECDSA P-256


-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuFuX96coyc9p3kRPuUTfdSLOlqao
w9grZwbzViQa7WQeanwg4Y2oH6uSdtvhKLS5I7smzzbM3SHy1+g4H4QLxw==
-----END PUBLIC KEY-----

How image signatures are checked

Install cosign on the host. install.sh then verifies every image after it signs in to the registry, and prints signed by qRaptor for each one. If an image the archive lists as signed has no valid signature, install.sh stops before starting anything.

Signatures are checked offline, against the image key — qRaptor doesn’t record them in Sigstore’s public transparency log. To check one image yourself:


cosign verify --insecure-ignore-tlog=true --key qraptor-images.pub \
  registry.qraptor.ai/apps-<subscription>/agent-runtime@sha256:<digest>

cosign prints a notice that it skipped the transparency log. That’s expected; the signature is still checked against the key.

Without cosign, install.sh still installs: every image is pinned by a digest the release signature covers, so a swapped image can’t run. It notes that the image signatures themselves weren’t checked. Set REQUIRE_IMAGE_SIGNATURES=1 to refuse to install without cosign.

How `verify.sh` works

Checks the signature over the manifest, and that the key fingerprint matches the one recorded inside the signed bytes.
Re-hashes every file in bundle/ against the manifest.
Re-hashes the compose project and install scripts.
Confirms every image in compose.yaml is digest-pinned and matches the manifest, in both directions.
With cosign installed and access to the registry, verifies each image’s signature. Before you’ve signed in to the registry, it notes that install.sh checks them.

Steps 1–4 need only openssl and sha256sum, with no network. It exits 0 for trusted, 1 for not trusted, 2 for cannot verify.

The auth service also re-checks the archive’s signature and file hashes at every boot, and refuses to start from a bundle it doesn’t trust.

⚠️

An export produced without a signing key configured is unsigned. It says so in its README and in the export warnings — treat an unsigned archive as untrusted.

Supported versions

These are currently qRaptor’s only release key and image key — there’s no rotation history yet. If that changes, a new key is published here before anything is signed with it, and the previous key stays published for as long as any supported appliance was signed with it. An archive names which keys sealed it — verify.sh shows the release key_id, and the manifest records the image key’s fingerprint.

If verification fails

Stop. Don’t install an archive whose signatures don’t check out — that’s what this whole process exists to catch. Contact support@augmentappz.ai with the key_id and fingerprint verify.sh printed, and we’ll help you work out what happened before you go any further.

Installing an appliance — where verify.sh and .env are used.
Appliance export overview — what this is and whether you need it.