Official discovery

Public add-ons without GitHub credentials

The Controller uses a signed catalog to discover official public add-on releases without a GitHub login or token. Choose a compatible release from Micro services to configure and deploy it. Private repository sources use separate operator-provided access.

Trust boundary

Trust and signing

addons.sig is a detached Ed25519 signature over the exact canonical UTF-8 bytes of addons.json, including its final newline. Every listed release pins a repository, tag, semantic version, and immutable target commit SHA.

Key rotation uses overlapping controller trust: add the new key alongside the old key, publish catalogs signed by the new key, confirm controller adoption, then retire the old key. The signing private key exists only in the controlled tools release environment; it is never in this website, browser code, or public catalog.

Controller contract

Controller verification and caching

  1. 1
    Fetch both static filesFetch the catalog and detached signature over HTTPS. This endpoint does not proxy GitHub.
  2. 2
    Verify the detached signatureUse a controller-pinned key. Reject malformed data, duplicate identities, invalid versions, and an invalid signature.
  3. 3
    Keep the last valid resultRefresh in the background and preserve the last verified catalog during a temporary endpoint failure.
  4. 4
    Validate again at deploymentClone the signed release tag, require its checked-out commit to equal the pinned SHA, then validate its package manifest before build or installation.

Machine or service tokens used by deployed microservices are unrelated to GitHub access. They must not be sent to this catalog endpoint or used for public add-on discovery.

Format v1

Catalog format

The generator emits compact JSON in the prescribed field order and exactly one trailing line feed before signing. The signature file is standard base64 encoding of the 64-byte Ed25519 detached signature, followed by one line feed.

Illustrative catalog entry
{
  "schemaVersion": 1,
  "addons": [{
    "repository": "uns-openhub/uns-archiver",
    "name": "uns-archiver",
    "version": "5.2.5",
    "tag": "v5.2.5",
    "releaseUrl": "https://github.com/uns-openhub/uns-archiver/releases/tag/v5.2.5",
    "commit": "622eab535053ffcf1d041990ce369907a85dcdac",
    "controllerCompatibility": ">=2 <3",
    "publishedAt": "2026-08-12T19:16:58Z"
  }]
}

The catalog generator rejects non-HTTPS release URLs, invalid repository names, tags, semantic versions or SHA values, duplicate add-on/version pairs, and releases with invalid chronology. Bare tags and draft releases are not public catalog releases.

Release procedure

Publish an official release

An official add-on starts with a reviewed entry in the tools-owned allowlist, a valid package.json.unsDatahub manifest, and a published non-draft GitHub Release. The controlled uns-datahub-tools release step then resolves the release to its commit, validates the manifest, builds the catalog, signs it, verifies the signature, and publishes only the two resulting static files here.

Adding a public repository to the organization is not enough to make it discoverable. A repository is added to the catalog only through that reviewed allowlist. This protects the official catalog from accidental or unreviewed public repositories.