Public Registry Signing Review Guide

This guide is for maintainers reviewing plugin submissions for the public registry.

The goal is simple:

  • reject unsigned or tampered releases

  • preserve key continuity across versions

  • keep the registry index aligned with auditable release artifacts

Review Inputs

Every submission should give you:

  • the plugin repository URL

  • the release version

  • the .w3dp download URL

  • the plugin ID

  • the signer public-key SHA-256 fingerprint

  • for a first release, the embedded public key PEM in the PR description

If any of those are missing, ask the developer to fill the gaps before you review the package itself.

Tools

Use the verification helper from a wprint3d-core checkout:

./plugin.sh verify /path/to/plugin.w3dp
./plugin.sh verify /path/to/plugin.w3dp --require-trusted
python3 scripts/plugin_verify_signature.py inspect /path/to/plugin.w3dp
python3 scripts/plugin_verify_signature.py verify /path/to/plugin.w3dp

To export the embedded public key for manual review:

python3 scripts/plugin_verify_signature.py inspect \
  /path/to/plugin.w3dp \
  --write-public-key tmp/plugin-signer.pub.pem

Review Workflow

1. Download the candidate package

Use the PR’s release URL or attached artifact and keep a local copy.

2. Confirm the package is actually signed

python3 scripts/plugin_verify_signature.py inspect candidate.w3dp
python3 scripts/plugin_verify_signature.py verify candidate.w3dp

Reject the submission if:

  • Algorithm is none

  • Embedded public key is no

  • Verified is no

3. Check signer continuity

If the plugin already has a public release in the registry, compare against the last accepted package:

python3 scripts/plugin_verify_signature.py verify \
  candidate.w3dp \
  --previous-package previous-release.w3dp

Expected result:

  • Verified: yes

  • Matches previous release key: yes

If the key changed:

  • do not merge immediately

  • ask the maintainer to explain the rotation in the PR

  • require out-of-band confirmation if the plugin is already trusted by many users

4. First-release handling

If there is no previous release:

  1. export the embedded public key

  2. compare the embedded public key against the PEM pasted in the PR description

  3. record the public-key SHA-256 fingerprint in the PR discussion

  4. use that key as the continuity anchor for future releases

  5. add that key to signers/index.json when you update the registry PR

5. Sanity-check the plugin package

At minimum:

  • inspect plugin.json

  • confirm id, version, and metadata match the PR

  • confirm the package URL and repository URL belong to the claimed maintainer

  • if the plugin is an update, confirm the version increment is sensible

If you have the stack available, also install the package in a test environment and confirm it loads without obvious runtime failure.

What To Ask The Maintainer When Something Is Wrong

Missing signature

Ask them to rebuild through the signing helper:

python3 scripts/plugin_sign.py path/to/plugin \
  --private-key ../plugin-signing/plugin-signing.pem

Tell them to resubmit the new .w3dp and include the verification output in the PR.

Invalid signature

Ask them to:

  1. rebuild from clean source

  2. re-sign the package

  3. rerun:

    python3 scripts/plugin_verify_signature.py verify path/to/package.w3dp
    
  4. post the successful output in the PR

Unexpected key rotation

Ask them to explain:

  • why the key changed

  • whether the previous key was compromised

  • whether users need to trust a new signing identity

Do not merge until the explanation is credible and documented in the PR.

Registry Update Workflow

The public registry is still PR-driven. The maintainer-side flow should be:

  1. verify the candidate package signature

  2. verify key continuity against the previous accepted release

  3. confirm the package URL is stable and downloadable

  4. update the registry index entry

  5. update signers/index.json so WPrint 3D instances can auto-sync the accepted signer key

  6. merge the PR only after the signature review passes

Local Restore And Inspection

If you need to inspect or salvage a package that is no longer in the registry, restore it into a disposable source tree:

./plugin.sh restore candidate.w3dp --output plugins/candidate-restore

That is useful for:

  • manual review of removed plugins

  • emergency republishing

  • helping maintainers fork and recover abandoned plugins

Suggested Registry Entry Shape

WPrint 3D resolves packageUrl directly, so a minimal entry can look like this:

{
  "plugins": [
    {
      "id": "acme.hello-world",
      "name": "ACME Hello World",
      "description": "Example plugin",
      "author": "ACME",
      "versions": [
        {
          "version": "1.2.3",
          "packageUrl": "https://github.com/acme/hello-world/releases/download/v1.2.3/hello-world.w3dp",
          "releasedAt": "2026-03-15",
          "sha256": "..."
        }
      ]
    }
  ]
}

If the registry stores additional metadata, keep it consistent with the submitted manifest and release notes.

The registry should also publish a signer manifest at signers/index.json, for example:

{
  "keys": [
    {
      "id": "acme.hello-world",
      "url": "https://raw.githubusercontent.com/wprint3d/plugin-registry/main/signers/acme.hello-world.pub.pem",
      "publicKeySha256": "..."
    }
  ]
}

WPrint 3D uses that file when plugin:sync-trusted-keys downloads trusted signer keys from the official registry and any marketplace-declared trusted registries.

Best Practices

  • Treat the previous accepted release as the signing trust anchor.

  • Prefer stable maintainer-controlled release URLs.

  • Keep a local archive of accepted registry packages for continuity checks.

  • Record the accepted public-key SHA-256 fingerprint in the PR thread for each first release.

  • Do not manually “fix” unsigned packages on behalf of developers. They need to sign and resubmit their own release artifacts.

  • If a package is invalid, fail closed and ask for a rebuilt artifact.