Release Signing Keys

Every Cloud Fellows product release is published with a checksum file and a detached OpenPGP signature over it. This page holds the public keys used to make those signatures, so you can confirm that a download really came from us and arrived unmodified.

Where trust starts

An OpenPGP signature proves that a release was made by the holder of a particular signing key. It cannot, by itself, prove who owns the first copy of that key. The complete fingerprint published on this page is the canonical trust anchor for Cloud Fellows release artifacts. Establish trust in it independently of the release you are checking; never accept a key or fingerprint supplied only with the download.

Start at the exact canonical address https://www.cloudfellows.de/signing-key.html. This website deliberately uses an Extended Validation (EV) TLS certificate to bind that address to our verified legal identity. Current versions of Safari and Chrome go beyond reporting that the certificate is valid: their first security view identifies its verified owner or subject as Cloud Fellows GmbH. Before trusting this public key for the first time, open your browser's certificate details and check that it reports a valid certificate for cloudfellows.de or www.cloudfellows.de and identifies the organization as:

Organization:      Cloud Fellows GmbH
Registration:      HRB 16592
Jurisdiction:      DE
State:             Nordrhein-Westfalen
Business category: Private Organization

The certificate in service when this guidance was published chains through Sectigo Public Server Authentication CA EV R36 and carries the CA/Browser Forum EV policy identifier 2.23.140.1.1. EV identity is not displayed directly in the address bar, and its exact presentation varies between browsers. The ordinary lock or a successful HTTPS connection alone is not this identity check: an attacker can obtain a valid Domain Validation certificate for a lookalike domain without proving that the domain belongs to Cloud Fellows GmbH.

The trust path is therefore:

browser or operating-system CA trust store
  -> EV-validated Cloud Fellows GmbH identity for this domain
  -> this page and its canonical OpenPGP fingerprint
  -> signatures on Cloud Fellows release checksums

HRB 16592 is not globally unique on its own because German register numbers are assigned by individual registry courts; the certificate does not name Amtsgericht Paderborn. Treat the organization, jurisdiction and registration number together as the verified identity. TLS certificates and their keys are renewed regularly and the issuing chain may change, so do not pin the fingerprint of the short-lived TLS certificate.

Current key

This is the key in use for all current releases:

The full forty-hex-digit fingerprint above — not the User ID or a shortened key ID — is the value to record and trust.

The Installation Notes published with each release name the key that release was signed with and repeat its fingerprint, so you can confirm the two agree.

Retired keys

None. This is the first Cloud Fellows release signing key. When a key is retired it stays listed here, with the period it was valid for, so that older releases remain verifiable. For a planned rollover, the previously trusted key will certify its successor. If you already trust the old key, that certification preserves continuity without requiring a new manual trust bootstrap. If the old key may have been compromised, do not rely on that certification; return to the EV identity check above and follow the incident guidance published here.

Importing the key

Download the key, look at it, and only then import it. --show-keys reads the file without importing anything, so you can compare the fingerprint before you commit to it:

curl -O https://www.cloudfellows.de/cloudfellows-release-signing-key-2026.asc
gpg --show-keys cloudfellows-release-signing-key-2026.asc
gpg --import cloudfellows-release-signing-key-2026.asc

The fingerprint that --show-keys prints must be the same forty hex digits as the one in the table above. It prints them as one unbroken run rather than in the spaced groups shown here — that is only formatting; the digits and their order are what must agree. If they do not, stop — do not import the key, and please tell us.

This is a one-time step. The same key verifies every release until it is retired.

Verifying a download

Each release publishes two files alongside the product archives: a .SHA256SUMS file listing the checksums, and a .SHA256SUMS.asc detached signature over it. Check the signature first, then the checksums — verifying a checksum file before establishing that it is authentic proves nothing:

gpg --verify <product-version-date>.SHA256SUMS.asc <product-version-date>.SHA256SUMS
shasum -a 256 --ignore-missing -c <product-version-date>.SHA256SUMS

<product-version-date> stands for the prefix the release you downloaded actually carries — product name, version and build date — and is the same on all four filenames. If your system has no shasum, use sha256sum --ignore-missing -c instead. Keep --ignore-missing either way: the checksum file covers every architecture we publish and you downloaded one of them, and without the flag the tool reports the ones you do not have as failures.

Reading the result

A successful check looks like this:

gpg: Good signature from "Cloud Fellows GmbH" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
<product-version-date>-linux-x86_64.tar.gz: OK

That warning is normal and is not a problem. It and the [unknown] marker mean only that you have not personally certified our key in your own OpenPGP web of trust — something almost nobody does for a vendor key. Neither says anything about whether the signature is good. What matters is the Good signature line together with a fingerprint you checked against the table above.

Anything else deserves attention:

Do not install a package that does not verify.