A plugin name is not an identity. Before you install something, verify plugin authenticity: confirm who published it, confirm the package you are holding is the one they released, and confirm nobody in between swapped it. That is most of plugin verification and it takes about five minutes. This guide runs the publisher check first, then the package, then the signals that tell you one of the two failed. DSH plugin authenticity comes down to matching three independent sources against each other, and how to verify a plugin publisher is the step people skip because the name looked right.
The publisher check comes first
Names are cheap. A publisher identity is not, and it is the one thing nobody copies without leaving traces somewhere else.
- Find the publisher outside the registry. A real publisher has a repo, a site or an account that predates the plugin. If the only trace of them is the plugin page, treat that as a finding rather than a missing detail.
- Compare the publishing account age against the plugin age. An account opened the same week as its first release proves nothing on its own, but it is a reason to spend another two minutes.
- Check whether the publisher owns the namespace they claim. Namespaces that look squatted, and known publisher names with one letter changed, are the common pattern. The detail is at /blog/how-to-spot-renamed-or-cloned-dsh-plugin.
- Look for a second release. A publisher with a history has older versions to diff against. A single release gives you nothing to compare.
Then check the package you actually downloaded
Publisher and package are two separate questions. One publisher can ship a good plugin and a bad upload, and the second one is what lands on your machine.
- Match the checksum or signature against what the publisher published, not against what the registry displays. The registry is one of the three sources, not the authority.
- Read the install hooks before you run them. Hooks are where an otherwise clean package does its real work, and the mechanics are at /blog/how-install-script-scanning-works.
- Diff the file list against the previous version. A new file that none of the release notes mention is worth an explanation.
- Check what the package reaches out to during setup. Fetching a second binary on first run is the pattern most warnings are built around.
| Signal | Where to check it | What a mismatch means |
|---|---|---|
| Publisher identity | Repo, site or account outside the registry | The name is borrowed |
| Account age vs plugin age | Registry account page | No history to verify against |
| Namespace ownership | Publisher profile and package metadata | Possible impersonation |
| Checksum or signature | Publisher release page | The upload is not theirs |
| File list vs last version | Diff the two packages | Something was added quietly |
| Install hook contents | Manifest before install | Setup does more than declared |
Where verification breaks down
Three situations defeat the checks above, and each one needs a different answer.
- Middlemen. A plugin that wraps another publisher's work inherits none of that publisher's checks, which is the whole of /blog/plugin-middleman-trust.
- Renamed or cloned packages. The code is identical and the name is new, so nothing inside the package looks wrong. Only the publisher comparison catches it.
- Publishers with no footprint at all. Small authors exist and publish good work. When there is nothing to verify, fall back on release history and documentation quality, both covered at /blog/how-to-evaluate-plugin-documentation-quality.
Verification is not a verdict on the code. It answers a narrower question: is this package from whoever it claims to be from.
A five-minute routine
Run these in order and stop as soon as one fails.
- Open the publisher page outside the registry and confirm it predates the plugin.
- Compare the checksum or signature against the publisher release page.
- Read the install hooks once.
- Diff the file list against the previous version.
- If two of the four come back clean and none fail, install it and watch the first week.
FAQ
- Is a high score the same as verification? No. A score covers maintenance, documentation, ecosystem health and install behaviour. It does not confirm who uploaded the package. The review process behind scores is at /blog/dsh-plugin-review-process.
- What if the publisher has no web presence at all? Fall back on release history and documentation. A publisher with six versions and a readable README has more to lose than one with a single upload.
- Do I need to do this for every plugin? No. Do it for anything that touches credentials, CI or production. The triage order is at /blog/how-to-avoid-risky-dsh-plugins.
- Can a registry badge substitute for the publisher check? No. A badge means the registry matched its own records. Those records are one of the three sources, not the answer.
Verification is one gate rather than the last one. Every plugin on dshquality.com carries a score page that states what was checked and what was not, so you can see which half of the picture you are looking at. Why scoring here stays independent of self-reported data is at /blog/why-independent-plugin-scoring-beats-self-reported-ratings, and everything published on the site is at /blog.