Cloned plugin detection is mostly a paperwork problem. A copy of a popular DSH plugin rarely rewrites the code, because the point of plugin cloning is to borrow trust rather than to write software, so impersonation plugins usually look correct on the page and differ in the metadata. Here is how to detect a cloned plugin before it runs anything: four checks on the name, the author, the publish history and the install script, plus what to do when a renamed plugin package turns up in a list you already trust.
What a clone copies, and what it leaves behind
A clone is not a rewrite. It is a re-upload, and the parts that survive a re-upload are exactly the parts worth checking.
- The README and the description. Copied verbatim, typos included, which is the fastest tell you get.
- The code. Usually identical, which is why diffing the source is less useful than people expect.
- The install script. Sometimes extended, and that is where the real risk sits.
- What does not survive: the author, the commit history, the release cadence and the issue tracker. Those four are attached to the repository, not to the files.
That asymmetry is the whole method. Compare the parts a clone cannot carry.
Four checks for cloned plugin detection
Run them in order. Any single failure is a reason to look harder, and two together is a reason to skip the plugin.
| Check | Where to look | Clone signal |
|---|---|---|
| Name | The plugin page and its repo or package name | A familiar name with a suffix, a changed separator, or a scope you do not recognise |
| Author | The owner field against the original repository | An account created recently, or one that publishes nothing else |
| Publish history | First release date and release count | A first release dated after the original got popular, and only one version |
| Install script | The scanned install step on the detail page | A clone of a plugin whose original has no install script at all |
Impersonation plugins versus honest forks
Not every copy is hostile, and treating forks as attacks produces a lot of noise. Four distinctions hold up in practice.
- A fork says so. Its README names the upstream project and links back to it.
- A fork changes something. A diff, an extra feature, a pinned dependency. A clone ships identical files.
- A fork keeps its own name or an obvious variant. An impersonation plugin takes the name and moves a hyphen.
- A fork has a history you can read. A clone has one commit, dated last week.
Forks want credit for the change. Clones want the installs the original already earned.
When a renamed plugin package is already installed
The awkward case is not deciding whether to install. It is finding out that something you already run is a copy. Four steps, in order.
- Do not uninstall in a panic. Note the version, the install date and where it came from first, because that is what you need if it turns out to be hostile.
- Compare the install script against the original. If the clone added one, treat it as an incident rather than as cleanup.
- Check what the plugin can reach. Credentials, network access and file writes are the three that matter.
- Replace it with the original and watch the score. The index grades both, and the gap between them is usually the clearest summary available.
Keeping clones out of a team list
Individual caution works once. A list is what makes it repeatable.
- Record the author next to every plugin, not just the name. Clones change the name and keep the word you recognise.
- Re-check the list monthly rather than only at install time. A plugin that was legitimate when added can be renamed later.
- Watch for grade movement, not just low grades. A copy usually scores worse than the original it imitates.
- Route new requests through one person. Most impersonation plugins get in because nobody was assigned to look.
The full index is on dshquality.com, and the four-pillar score behind every entry is explained at /blog/dsh-quality-score-decoded. For adjacent reading, /blog/plugin-supply-chain-security-team-enforcement covers how a copy reaches your machine, /blog/how-to-avoid-risky-dsh-plugins covers the evaluation step, and /blog/tag-baiting-problem covers the naming tricks that make a clone look official. All posts are at /blog.
FAQ
- Can a clone pass a code review? Yes, because it usually is the same code. The signals sit in the metadata, the author and the publish history, not in the diff.
- Is a lower score proof that a plugin is a clone? No. A clone often scores lower because it has no history and no maintenance, but a low score on its own only means look closer.
- What if someone cloned a plugin I published? Open an issue on the copy, report it through the registry, and link your original from your own README. Most copies disappear once the original identifies itself clearly.
- Do clones matter when there is no install script? Less, but they still matter. A copy with no install script today can add a hostile one in a later version, which is why the publish history check comes before the trust decision.