Skip to content

Release Signing Key

Every ANKASecure release is signed with an OpenPGP release signing key: the admin bundle, the signed release manifest that pins every container image by digest, and the SDK artifacts on Maven Central. Each release key signs a fixed range of releases, and the verifiers admit a key only for the releases of its range.

The release keys

Releases signed Primary key fingerprint
3.4.3 and later 115A3746E96629568FA493D2C3F2A5EDF5887E3E
3.0.0 to 3.4.2 CCB37806816378C5BE3810EFD76DBF1B69BD8558

Both keys carry the user ID AnkaSecure Release Signing Key (Production Release Key v3.0) <[email protected]>. The fingerprint is the identity of the key.

One exception: the 3.4.3 SDK and Key Management SDK artifacts on Maven Central (co.ankatech:ankasecure-sdk:3.4.3 and co.ankatech:ankasecure-key-management-sdk:3.4.3) are signed by the key for 3.0.0 to 3.4.2. Every other 3.4.3 artifact, and every artifact of a later release, is signed by the key for 3.4.3 and later.

The fingerprint in the table is written in the form the admin bundle installer takes: 40 upper-case hexadecimal characters, with no spaces. gpg --fingerprint prints the same characters in groups of four:

115A 3746 E966 2956 8FA4  93D2 C3F2 A5ED F588 7E3E

Verify the fingerprint independently

This page, the installer and the release artifacts are published by the same party, so a fingerprint read here proves nothing about a download that could have been altered together with this page. Look the key up by its address, never by the fingerprint printed here, on a keyserver that verifies the address by e-mail, and accept the key only when the fingerprint that keyserver returns is the one in the table.

  1. Look up [email protected] on keys.openpgp.org, which publishes a user ID only after its owner confirmed the address by e-mail, and show the key it returns without importing it:

    curl -fsS https://keys.openpgp.org/vks/v1/by-email/release%40ankatech.co | gpg --show-keys

    The lookup goes to keys.openpgp.org whatever keyserver your GnuPG is configured with. The key it returns must carry the user ID <[email protected]>, and its fingerprint must be 115A3746E96629568FA493D2C3F2A5EDF5887E3E. A key without that user ID, or no key at all, is not a confirmation: stop.

  2. Compare, character by character, the fingerprint keys.openpgp.org returned with the one in the table. If anything differs, stop and contact ANKATech support: do not install the release.

The key is also published on keyserver.ubuntu.com, where you may look it up as a cross-reference (gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 115A3746E96629568FA493D2C3F2A5EDF5887E3E). That keyserver accepts any upload under any address, so what it holds, a key it lists under [email protected] included, neither confirms nor refutes a release key: the confirmation is the verified address on keys.openpgp.org.

Upgrade an installation from 3.4.1 or 3.4.2

An installed admin bundle verifies the next admin bundle with its own release trust. A 3.4.1 or 3.4.2 admin bundle trusts only the key that signs 3.0.0 to 3.4.2, so the installer refuses the 3.4.3 admin bundle, signed by the key for 3.4.3 and later, and names this page. Accept the new key once, explicitly:

  1. Verify the fingerprint of the key for 3.4.3 and later independently, as above.
  2. Download the 3.4.3 installer from https://bootstrap.ankatech.co/install-admin-bundle.sh. Use that installer, not a copy kept from an earlier release: the release keys it carries are the ones it checks the bundle against.

  3. Install the 3.4.3 admin bundle over the installed one, naming the fingerprint you verified:

    sudo ./install-admin-bundle.sh --version 3.4.3 --force --accept-release-key <fingerprint>

    Type the 40-character fingerprint in place of <fingerprint>. --force replaces the installed admin bundle, which an upgrade always does.

  4. Upgrade each environment as usual, with envctl.sh <env> upgrade plan and then envctl.sh <env> upgrade apply.

--accept-release-key admits the key only when all of these hold, and refuses the installation otherwise, with nothing installed:

  • an admin bundle is installed, and its release trust does not already pin the key;
  • the installed trust reports the signature only as made by a key it does not hold or does not pin; a bundle altered after signing, carrying more than one signature, or signed by an expired or revoked key is refused with or without the option;
  • the fingerprint is exactly that of a release key the installer itself carries, and that key signed the bundle;
  • the signature verifies against that one key alone;
  • that key signs the bundle's release, and the bundle is a later release than the installed one.

The release range and downgrade checks run as on every installation. The installer prints the accepted key, its range and the release keys the installed bundle pins and, once the new admin bundle is installed, records one line on the host log under the tag ankasecure-install-admin-bundle:

release-key-accepted fpr=<fingerprint> from=<installed release> to=<new release>

A first installation needs no option: it verifies the bundle against the release keys the installer carries.