DSH plugin market verified badge: what it proves

Clicking Install the moment you see the verified badge is the most expensive misread in the plugin market: it turns "the source checks out" into "the code is fine". On a dsh plugin market card, verified is only a source-validation marker (2.2.5 index). It rules out the risk that a listing is fabricated, and it touches none of permissions, dependencies or build scripts. This article splits the badge by meaning: what it verifies, what it never verifies, and what you still have to add. The badge appears on market cards and listing pages inside DSH Plugin Hub.

What verified literally checks in dsh plugin market: source and basic data

Verified checks where a listing came from and whether its basic information lines up — not whether the plugin is safe when it runs. Separating those two propositions is the first step in reading the badge.

1. When you see verified, confirm which listing carries it; do not attribute plugin A's badge to plugin B.
2. Open the detail page and verify that the source repository matches the name on the card.
3. Treat verified as a ticket to keep reading, not a pass to install.
4. If the source repository will not even open, stop regardless of how bright the badge is.

The value of source validation is real: it tells you the listing did not appear from nowhere. Its boundary is equally real — it inspects the listing layer, not the code layer and certainly not the runtime layer.

The three risks it misses: DSH plugin permissions, dependencies, build scripts

Real plugin risk happens at runtime and at install time, and verified inspects neither moment. Three risks deserve item-by-item review:

1. Permission scope: which directories the plugin reads or writes, whether it opens a local port, whether it calls tools. A plugin that only needs to read one config but asks for whole-disk access is telling you something.
2. Dependency count and origin: more dependencies widen the supply chain, and an unknown package inside the tree remains risky even when the main package carries verified.
3. Build scripts: when installing from source, dependencies may execute scripts during installation. A verified listing can still request script execution, and you still decide whether to trust it.

All three share one property: they live in "how the code runs", not in "where the listing came from". A badge can prove the entry is real; it cannot prove the code is restrained.

After verified, three checks a DSH plugin still needs

The order is permissions, then dependencies, then build scripts, starting with the largest blast radius. All three can be assessed without reading the entire source.

1. Permissions: find the declared capability scope in the detail page or plugin notes and compare it with the function; flag anything over-provisioned.
2. Dependencies: inspect count and origin, and raise suspicion when an unfamiliar scope or an obviously unrelated package appears.
3. Build scripts: if installation asks permission to run a script, confirm the repository is trusted; if unsure, refuse and use a prebuilt release instead.
4. Source repository: finally check recent commits and issues to confirm it is not an empty shell.
5. Record the conclusion: write these judgments into your own notes so the next update can reuse them.

You do not have to finish all three before a quick trial, but you must finish them before a plugin enters daily work. Temporary testing can be looser; long-term use cannot.

A fast order for the three checks

1. Check whether permissions are over-scoped, because this has the widest impact.
2. Check dependency count and origin, asking "why is this needed?" for every unfamiliar package.
3. Check build scripts, and refuse execution when unsure by switching to a prebuilt release.
4. Check repository activity last to confirm someone can fix problems.

If all four still leave you unable to explain the plugin, trial it in an isolated environment instead of your daily profile.

Combining with stars and update time: DeepSeek Harness trust signals

Trust signals stack: verified covers source, update time covers maintenance and stars cover attention; three questions, no substitutes. Stacked together they produce a far more reliable picture than a single badge.

1. Check verified first: no badge does not mean unusable, but the source needs an extra verification step.
2. Check update time next: recent maintenance means someone responds when things break; long silence means you carry the risk.
3. Check Star/Fork only to build a candidate pool, never as a substitute for permission and dependency review.
4. When the signals conflict, trust source plus maintenance and put popularity last.
5. Record the combined conclusion and compare it on each update instead of re-judging from scratch.

This site breaks the combination down further in how to read DSH plugin trust signals. This article makes one point: verified is one cell in the table, not the table.

When to drop a verified DSH plugin anyway

Any one of over-scoped permissions, suspicious dependencies, opaque scripts or a dead repository is enough to drop it; do not let the badge talk you out of it. Dropping is not conservatism — it puts risk before installation instead of after.

1. The function only needs to read config, yet it requests access to the entire home directory or the network.
2. The dependency tree contains an unrelated unknown package and the source repository does not explain it.
3. Installation requires running a build script that the documentation never mentions.
4. The source repository has not updated in a long time, issues go unanswered, yet versions keep rising.
5. The plugin description does not match the source repository, or the detail page omits critical information.

The first three are code-layer risks; the last two are maintenance and source risks. If any holds, "it has verified" does not cancel it. For the full pre-install list, see the 60-second checklist before installing; for other card signals, see how to read market cards.