A .rdplug package is a manifest, a WebAssembly component, optional translations, and an Ed25519 signature. This page covers producing one and getting it to users.

rdownloader plugin keygen --output ./keys --role plugin

--role takes plugin, release, tool-manifest or repository. For a plugin you want plugin: a key trusted for one role signs nothing under another.

Keep the private key in your secret store, not in version control. The scaffold from rdownloader plugin new writes one into plugin-signing.key to get you started, and a .gitignore that keeps it, target/ and *.rdplug out of a commit — move the key into your secret store before you publish anything.

rdownloader plugin package \
  --manifest manifest.toml \
  --component target/myhoster.wasm \
  --locales locales \
  --key plugin-signing.key \
  --output myhoster.rdplug

--key can be omitted when RDOWNLOADER_PLUGIN_SIGNING_KEY holds the PEM text — which is how the CI workflow signs.

--development writes an unsigned package instead. Only serve --plugin-development-mode and verify --development-mode accept one, so it is for a local test and never for a release.

rdownloader plugin verify myhoster.rdplug
rdownloader plugin verify myhoster.rdplug --trusted-key KEY_ID=BASE64
rdownloader plugin conformance myhoster.rdplug --json

verify checks the signature against the trusted keys. conformance answers whether this application would actually run the package — the check to pass before publishing.

--no-default-plugin-key drops the compiled-in release key from consideration; --development-mode accepts an unsigned package.

rdownloader plugin install myhoster.rdplug --root data/plugins

Or through the web interface under Settings → Plugins — as an upload or from a plugin repository, both on the Catalogue tab — either way after the install preview.

rdownloader plugin keys list
rdownloader plugin keys trust --from-package myhoster.rdplug [--yes]
rdownloader plugin keys revoke <KEY_ID>

A user installing your package for the first time is shown your key's fingerprint and asked to approve it. Publish that fingerprint somewhere they can compare it against.

A trusted key carries a role and an optional expiry, so a key can be rotated with an overlap window.

One bad build is withdrawn by its digest, not by revoking the key: revoking a key takes down every package that author ever signed. A published .rdplug keeps verifying in every later release.

The SDK ships a reusable CI workflow template that builds the component, runs the import check, packages, signs from RDOWNLOADER_PLUGIN_SIGNING_KEY and runs conformance. Point your repository at it rather than reassembling the steps.

It reads the repository and nothing more, its actions are pinned to commits, and the rDownloader release it downloads (RDOWNLOADER_VERSION, the release the SDK came with) is checked against that release's SHA256SUMS before it runs. Only a push to the default branch or a tag signs; a pull request builds an unsigned development package and checks it in development mode, so code nobody has merged yet never runs beside the signing key.

A plugin is published without changing the core repository; provider metadata and translations travel in the package. Two ways reach users:

• A file. Publish the .rdplug and its key fingerprint; users upload it under Settings → Plugins → Add.
• A repository. Publish a signed index beside your packages; users add it with its address and your repository public key, and then see your plugins under Available plugins and your new versions under Updates. A repository only delivers: every package in it still needs your plugin key, approved by the user.

A repository is one signed JSON document, rdownloader-plugin-index.json, listing each package with its plugin id, version, type, contract version, minimum rDownloader version, package digest, size, address, publisher (key id, fingerprint, author), permissions and plain-text release notes, plus the package digests it withdraws. It is signed with a repository key — a role of its own, separate from the plugin key:

rdownloader plugin keygen --role repository --output ./keys
rdownloader plugin index build ./packages --out rdownloader-plugin-index.json \
  --key ./keys/rdownloader-repository.key --key-id example-repository-v1 \
  --base-url https://example.org/plugins/ --notes ./notes

• index build reads every signed .rdplug in the directory and checks that each is signed by the key its manifest names. --key can be omitted when RDOWNLOADER_REPOSITORY_SIGNING_KEY holds the PEM text. --key-id names your key; without it the index claims the official repository's id, and a key that is not the official one is refused under it.
• --sequence defaults to the signing time in Unix seconds, so a later index always supersedes an earlier one; a client refuses an index older than one it already accepted.
• The index is valid for 90 days (--valid-days, at most 366); an expired index is refused, so publish a new one before then.
• --base-url makes the package addresses absolute. Without it they are relative to the index's own address and cannot leave its directory.
• --notes <dir> takes <package file stem>.txt release notes, at most 2,000 characters of plain text each; a file holding only the maintenance sentence (Maintenance release: internal changes only, no change in behaviour.) gives its package no notes. --revocations <file> takes the withdrawal list.
• rdownloader plugin index verify <index> --packages <dir> checks an index against the official repository key compiled into the application, and each listed package against its digest and size. A third-party index is checked by adding the repository to a test installation.

The entry must match the package: a client refuses a downloaded package whose id, name, version, type, contract, signing key, author or permissions differ from its entry. A third-party repository can withdraw only versions that were installed from it.

Give users the index address and the repository public key's Base64, and publish its fingerprint: adding the repository shows that fingerprint for them to compare. The limits of the format are in the Plugin reference.

Running the repository over time — hosting, adding versions, re-signing before the index expires, withdrawing a version, a lost key, and the SDK workflow that publishes it on GitHub Pages — is Running a plugin repository.

1. cargo test passes in the scaffold's own tests.
2. cargo build --release --target wasm32-unknown-unknown and wasm-tools component new succeed.
3. The import check passes — nothing outside rdownloader:plugin.
4. locales/en.json exists.
5. The manifest asks for exactly the capabilities you use, with the narrowest domain allowlist that works.
6. rdownloader plugin conformance <package> --json is clean.
7. The key fingerprint is published somewhere users can compare it.
8. Publishing through a repository: a test installation adds the repository, lists the package under Available plugins and installs it.

• Developing a plugin
• Installing and trust
• Plugin overview
• Plugin reference — keys and trust, building a package, superseded versions
• Running a plugin repository
• Command line client

Reference in the repository: sdk/