Introducing the Promethix Trust Centre and Build Provenance

One of the areas I have been tightening up recently is release verification for Promethix projects.

That has led to the introduction of the Promethix Trust Centre at trust.promethix.dev, which exists to make it easier to validate and verify Promethix build and release artefacts rather than treating published packages and images as things that should simply be trusted on sight.

The idea is straightforward: if I publish something, there should also be a clear way to answer basic questions such as:

• what was built
• where it came from
• which commit and workflow produced it
• what checksum or signing material should be expected
• how someone else can verify it independently

This is still evolving, but the shape of it is now visible in a couple of real projects.

What the Trust Centre Is For

The Trust Centre is intended to be the stable verification side of Promethix releases.

In practice, that means publishing or referencing the material needed to validate artefacts after they have been built and distributed: checksums, SBOMs, provenance metadata, verification keys, and instructions for how to use them.

The goal is not to create security theatre or claim some magical guarantee. It is simply to make the release chain more inspectable and defensible.

GitHub Builds Versus Promethix-Managed Builds

Not every Promethix artefact comes through the same build path, and that distinction matters.

For projects built on GitHub with Actions, provenance and attestation can lean on GitHub’s own trust and verification model, including GitHub Actions build provenance attestations where they are enabled.

Promethix also has its own CI/CD estate, configured and run by me, using tools such as Gitea, Forgejo, and Drone. In that world, the verification model is necessarily different. Rather than pretending those builds inherit GitHub’s trust path, the intention is for Drone-built artefacts to rely on Promethix-controlled signing and PKI material, with the relevant public verification material linked from the Trust Centre.

AdoScope: NuGet Provenance, Checksums and SBOMs

For AdoScope, the provenance model is centred around the NuGet package and the build artefacts that go with it.

The build workflow publishes:

• the .nupkg
• a .sha256 checksum for the package
• a CycloneDX SBOM
• release metadata
• GitHub build provenance attestations for the generated artefacts

The intended verification location for those release materials is:

• https://trust.promethix.dev/nuget/

NuGet packages are a slight special case here. If you are distributing through nuget.org, package signing generally expects a publicly recognised code-signing certificate rather than an internal PKI chain. In practice, that means the stronger trust story for AdoScope currently comes from the provenance, checksums, SBOM, and signed attestation path around the package rather than from package signing based on Promethix-managed certificates alone.

That still gives a cleaner way to validate what was published, where it came from, and what supporting artefacts should exist alongside the package.

Cloudflare Tunnel Operator: Signed Container Images

For the Promethix Cloudflare Tunnel Operator, the release model is slightly different because the primary artefact is a container image rather than a NuGet package.

There, the main focus is image signing and verification.

Container images are signed with cosign, and the public verification key is published through the Trust Centre at:

• https://trust.promethix.dev/cosign/promethix-code-signing.pub

That allows consumers to verify an image by digest rather than relying on mutable tags such as latest, which is a much better fit for anything that is supposed to be repeatable or auditable.

Longer term, the same general approach applies to Promethix-managed CI/CD more broadly: where artefacts are built outside GitHub, the Trust Centre should still provide the public verification side of the chain, whether that is signing keys, PKI-linked verification material, or clear instructions for how those releases are intended to be validated.

Why I Bother With This

With the recent discussion, especially in the open source world, around trust, build integrity, and supply chain attacks, this sort of approach helps alleviate at least some of those concerns by making release artefacts easier to inspect and verify.

Even for small projects, it is useful to know that a package or image can be tied back to a particular repository state and build path, and that there is at least some structured verification material available to support that.

That also fits with the wider direction of the platform more generally. Internally I already run a properly structured PKI with an offline root CA, intermediate CAs, Vault-backed certificate management, cert-manager integration in the RKE2 platform, and a separate Windows-backed path for things like smart card and YubiKey management. The Trust Centre is not the same thing as that PKI, but it follows the same general principle: trust should be rooted in something explicit, inspectable, and operationally deliberate.

This is consistent with the broader direction I have been taking across Promethix work, aiming for more automation, more repeatability and more explicit release handling.

Direction from Here

At the moment, the Trust Centre is small in scope with a narrow purpose.

Hopefully it makes Promethix artefacts easier to verify and reason about, especially if being used in a system you are building.

From this point forward, I will aim to have all my build pipelines provide provenance.