Verify dsh plugin packages: npm, GitHub and tarballs

Package verification asks one question: is the artifact in front of you the one the publisher intended? A dsh plugin can arrive from npm, from a Git repository or as a tarball, and each path leaves a different trail to check. The trail matters more than the install command.

The path a dsh plugin package takes from publish to install

Every install is a chain of custody, and verification is how you inspect the links you can see.

A publisher builds an artifact, attaches metadata and uploads it to a registry or a release page. The registry stores a digest of the artifact and serves it to clients. Your machine downloads the artifact and, in a good setup, checks it against the digest.

Each handoff is a place where the artifact could change or be replaced. The chain is only as strong as the least verified link, which is often the developer's local download. That is why the lockfile matters more than the version string.

Git installs skip the registry digest and rely on a commit hash instead. Tarball installs skip both and rely on whatever checksum you obtained separately. Knowing which link you are trusting keeps the rest of the process honest.

The DSH Plugin Hub entry is a useful reference for the canonical package name and repository. It tells you which trail to expect before you download anything. Start there when a package appears under two similar names.

What npm integrity checks cover for a dsh plugin

For npm installs, the lockfile digest is the anchor, and the version number is only a label.

The lockfile records the exact version and the integrity hash for every package in the tree. A frozen install compares the downloaded artifact against that hash before unpacking it. If the registry serves something else under the same name, the install fails rather than proceeding.

Regenerating the lockfile discards that protection for any package whose entry changes. Do it deliberately, review the diff and treat a changed hash as a question. A hash change on an unrelated dependency is worth a pause.

The package name and the publisher account deserve a glance as well. Same-name substitution works precisely because people stop reading after the first match. A short check of the repository link catches most of it.

Registry mirrors can introduce another link in the chain. A mirror that serves stale or modified content will fail an integrity check, which is the system working as intended. If that happens, switch back to the canonical registry before debugging the package itself.

Verifying a dsh plugin installed from a Git repository

A branch is a moving pointer, so a source install should name a commit.

Pin the commit hash at install time and record it next to the version. A tag is better than a branch but still depends on the tag not being moved. The commit is the only identifier that cannot drift without changing.

Source installs may run build scripts, which means the repository content matters beyond the final bundle. Read the install scripts before running them on a machine that holds credentials. That is a normal precaution, not a sign of distrust.

Compare the local checkout with the intended commit after installation. If they differ, stop and find out why before the plugin loads. A mismatch at this point is easier to explain than a strange behavior later.

A commit hash also makes support conversations shorter. When someone reports a bug, the hash tells you exactly which source produced it. Branch names tell you almost nothing after a week.

Checking a dsh plugin tarball before installation

A tarball is convenient for offline transfer and useless without a checksum you trust.

shasum -a 256 ./my-plugin-1.4.0.tgz
npm install ./my-plugin-1.4.0.tgz

Obtain the checksum from the release page or an internal manifest, never from the same transfer that delivered the file. Compute the digest locally with one algorithm and compare the whole string. A partial match is a mismatch.

Recompute after any copy or transfer, including a move between machines. Corruption is quiet and usually looks like a random install error. The checksum turns that error into a clear statement about the file.

Keep the verified tarball and its checksum together in the artifact store. When someone asks which build is deployed, the pair answers the question without archaeology. It also makes the next offline install boring, which is the goal.

What to suspect when dsh plugin verification fails

A failed check is information: it narrows the problem to a specific artifact and a specific expectation.

First decide whether the artifact changed or the expectation did. A new lockfile entry, a moved tag or a re-published tarball can all produce a mismatch without an attacker. Check the release history before assuming the worst.

If the source is public, download again from the canonical URL and recompute. If it still fails, switch to a source you can verify rather than retrying the same file. For internal packages, ask the release pipeline for the manifest it generated.

1. Re-download from the canonical source.
2. Recompute the digest with the same algorithm.
3. Compare against the recorded value, character by character.
4. Check whether the publisher re-released the version.
5. Confirm the lockfile was not regenerated.
6. Escalate to the maintainer with both values.

A mismatch that survives a clean download is not a caching problem. It is either a publisher-side change or a substituted artifact, and both deserve a written record. Do not install while the question is open.

Making DeepSeek Harness plugin verification routine

Verification becomes cheap when the evidence is collected during install instead of reconstructed later.

Record the source, version, digest or commit and publisher for every DeepSeek Harness plugin you deploy. Store that record with the deployment notes rather than in a chat thread. The next upgrade then starts from evidence.

Use DSH plugins from sources that publish stable identifiers, and prefer those that keep old artifacts available. A publisher who deletes releases makes verification harder for everyone downstream. That is a legitimate selection criterion.

The install either matches the record or it does not, and both outcomes are actionable. A verified chain of custody is the cheapest supply-chain control available to a small team. It costs a few lines in a manifest and saves a very bad afternoon.

Verification is not a ritual performed once at install time. It is a habit of writing down what you trusted and why. The record is what turns trust into something you can check.