For operators and authors

Publishing and trust

How this catalogue is produced, what your instance checks before it runs anything from here, and how to publish a plugin of your own.

What your instance verifies

Two independent checks, both fail-closed:

Catalogue: A detached Ed25519 signature over the catalogue with the signature field removed, serialised with sorted keys and compact separators. A single changed byte anywhere invalidates it.
Archive: The SHA-256 recorded in the signed catalogue must match the downloaded ZIP before it is unpacked.

Pin the publisher key so the first check has something to check against:

MARKETPLACE_PUBLISHER_PUBLIC_KEY=580c30040c2eec36902d4ea9e778ee12cac270011703e9e9f8f7c617158711d5

Without a pinned key an instance refuses to sync at all, unless an operator consciously sets MARKETPLACE_ALLOW_UNSIGNED=1 for a private or development registry.

What the registry cannot do

The catalogue carries descriptive fields only. Trust markers such as verified, featured, status and download counts are set by your own instance and are stripped from anything the registry sends, so a registry cannot promote its own plugin inside your UI.

Publish your own

The registry is a static, reproducible build. Add a plugin directory, rebuild, and deploy:

git clone https://github.com/freesdn/freesdn
cd freesdn/registry
cp -r /path/to/my-plugin plugins/
python build.py --key-file publisher.key

Archives are deterministic: sorted entries and a fixed timestamp, so rebuilding an unchanged plugin yields an identical checksum and the catalogue stays stable.

To run a private registry for your own organisation, generate your own keypair with python build.py --generate-key, host public/ anywhere, and pin your own public key. Nothing in the protocol is specific to this deployment.

Reporting a problem

Security issues in a plugin or in the registry itself go to the disclosure route on the FreeSDN security page. Please do not open a public issue for a vulnerability.