plugin bundles three command-line tools built from apps/src/. They implement the signing workflow that plugin-sign and DSOLoader::loadVerified check at run time.
| Tool | Job | Page |
|---|---|---|
dso-keygen | Generate an Ed25519 developer key pair + fingerprint | dso-keygen |
dso-sign | Embed a signed JSON manifest in a DSO (ELF sections) | dso-sign |
dso-verify | Report a DSO's trust level; exit code carries the result | dso-verify |
Read The signing model first for what the manifest contains and how trust is decided.
Build & install
The tools build when OpenSSL is present (APPS=ON, the default in a standalone build). cmake --install — and every CPack archive — puts them on PATH and installs their shell completion:
<prefix>/bin/dso-keygen
<prefix>/bin/dso-sign
<prefix>/bin/dso-verify
<prefix>/share/bash-completion/completions/dso-{keygen,sign,verify}
<prefix>/share/zsh/site-functions/_dso-{keygen,sign,verify}
The Conan package ships all three in the plugin_apps component.
The 60-second workflow
# 1. once per developer
dso-keygen --name "Alice" --email alice@example.com --key-id alice \
--separate --out-dir keys/
# keys/private/alice.key keys/private/alice.fingerprint keys/public/alice.pub
# 2. once per build of the add-on
dso-sign libCircle.so --key keys/private/alice.key --name circle --version 1.2.0
# 3. once per host/deployment
cp keys/public/alice.pub /etc/app/trusted-keys.d/
# 4. check
dso-verify libCircle.so --keys /etc/app/trusted-keys.d/
# TRUSTED: libCircle.so
# ...
echo $? # 0
Why not openssl / signify / codesign?
Those sign a file and produce a detached signature you have to distribute and locate. dso-sign embeds the signature and a structured manifest inside the DSO, so a signed plugin is a single self-describing file, and the host verifies it with an mmap and a section-table walk — no extra artefact, no libelf. The trust model (a directory of *.pub keys, four levels, host decides the policy) is deliberately small.
