dsh plugin 安装包怎么校验：DeepSeek Harness 的 npm、GitHub 与 tarball

dsh plugin 的完整性校验，要解决的问题不是「能不能装上」，而是「装上的确实是你以为的那份包」。 DeepSeek Harness 的插件可能来自 npm、GitHub 源码或离线 tarball，三条路径各有自己的可信锚点。忽略这一步，等到插件行为异常时再回头查，成本会高得多。

dsh plugin 从发布到安装经过哪些环节

一个包从发布到落地，会经过打包、上传、解析、下载和写入五个环节，每个环节都可能改变最终内容。

发布者先在本地构建，把源码和元数据打成 tarball，再上传到 registry 或发布页。打包时哪些文件被包含、哪些被排除，由 package.json 里的字段决定。构建脚本如果在发布阶段执行过，产物还可能和仓库里的源码不完全一致。

安装端拿到的第一份信息是元数据，包括包名、版本、依赖和完整性字段。客户端据此决定下载哪个 tarball，以及下载后该用什么哈希核对。元数据本身也可能被镜像或代理改写，所以来源是否可信同样重要。

下载完成后，包会被解压到缓存目录，再根据解析结果写入 node_modules 或插件目录。写入阶段还可能执行安装脚本，这一步是供应链风险最集中的地方。只校验哈希、不关心脚本行为，仍然可能装进一份「内容正确但行为可疑」的包。

理解这条链路的意义在于定位问题。同样是启动失败，可能出在打包遗漏、下载损坏、依赖冲突或安装脚本报错。知道每一步做什么，才能判断该重试、该换源，还是该退回旧版本。

DeepSeek Harness 的 npm 完整性字段怎么核对

npm 安装的完整性基础是 lockfile 里的哈希，版本号本身不提供任何内容保证。

lockfile 记录了每个依赖的精确版本和完整性哈希。安装时客户端会拿下载内容重新计算哈希，与记录值比对，不一致就拒绝写入。这也是为什么删除 lockfile 再重新生成会削弱可复现性，因为新的解析结果可能带来不同的版本组合。

核对时先确认 integrity 字段存在，再确认它对应的版本与你要装的一致。只写一个范围版本、没有锁定具体版本的项目，实际上放弃了这层保护。用冻结安装可以避免安装过程顺手升级依赖。

npm view dsh-plugin-hub dist.integrity
shasum -a 256 dsh-plugin-hub-1.2.3.tgz

除了哈希，还要看包名和发布者。同名包替换是真实存在的攻击方式，哈希只能证明内容与某个来源一致，不能证明来源本身可信。把 registry 固定到可信地址、核对维护者信息，是哈希之外的补充。

dsh plugin 的 GitHub 源码与 tarball 校验

源码安装要固定提交哈希，tarball 安装要在传输前后各算一次哈希。

从 GitHub 安装时，分支名会随时间移动，今天装的和下周装的可能不是同一份代码。写清提交哈希，才能保证每次安装拿到相同内容。发布标签也要核对，标签指向的提交和你记录的提交应当一致。

源码安装还可能触发构建脚本。仓库里的 prepare、postinstall 之类脚本会在安装阶段执行，这既是便利也是风险。安装前扫一眼脚本内容，确认它没有访问不该访问的路径或网络地址。

tarball 适合离线与内网场景，但传输过程本身可能损坏文件。发布端算一次哈希，传输到目标机器后再算一次，两次一致才继续安装。校验值要来自可信渠道，比如发布页或内部清单，而不是和包放在同一个目录里的文本文件。

三种来源的锚点不同，但思路一致：先确定你信任的是什么，再用它去比对实际拿到的东西。信任版本号、信任分支名、信任文件名，本质上都是把判断交给了不可靠的线索。把这句话记住，比背下每一条命令更有用。

校验失败时 DeepSeek Harness 用户先怀疑什么

校验失败先怀疑传输和缓存，再怀疑来源被替换，最后才怀疑工具本身。

最常见的原因是下载不完整。网络中断、代理截断、磁盘写满都会让文件哈希对不上，重新下载一次往往就恢复正常。连续两次失败才值得继续往下查，因为偶发损坏的概率远高于恶意替换。

第二种原因是缓存里留着旧文件。客户端可能复用之前的下载结果，或者镜像返回了过期内容。清掉缓存再装，能排除这一类干扰。如果清理后仍然失败，再去看 registry 返回的元数据是否和预期一致。

第三种原因是来源确实变了。包被重新发布、标签被移动、维护者更换，都会让哈希变化。这时候不要急着绕过校验，先确认变化是否有公开说明。没有说明的哈希变化，应当按高风险事件处理。

工具本身出问题的概率最低，但也不能完全排除。旧版本客户端可能不支持新的哈希算法，或者对某些 registry 的返回格式解析有误。升级工具后再试一次，是排除这一层的最快方式。

DSH插件 的最小校验清单

来源、版本、哈希和发布者，四项至少核对三项，才值得把包装进日常环境。

校验不需要很重的流程，关键是每次都用同一套顺序。先确认安装来源是 npm、GitHub 还是 tarball，再确认版本是精确值而不是浮动范围。接着找对应的哈希或提交，最后核对发布者与条目信息是否一致。

这套顺序的价值在于可追溯。装完之后如果出问题，你能说清楚当时装的是哪个版本、来自哪里、哈希是多少。发布者与版本信息也可以到 DSH Plugin Hub 的条目页对照。没有这些记录，排查只能靠猜，也很难判断是不是同一次发布引入的问题。

下面这份清单可以贴在发布流程里，按顺序执行即可。它不要求额外的工具，手工核对也能完成。真正重要的是每次都走完，而不是在赶进度时跳过其中几步。

1. 确认安装来源，记录 registry 地址或仓库路径。
2. 固定精确版本，不使用 latest 或宽泛的范围。
3. 获取可信哈希或提交号，写进安装记录。
4. 下载后本地重算哈希，与来源比对。
5. 核对包名、发布者与插件条目是否一致。
6. 检查安装脚本，确认没有异常的网络或文件访问。
7. 安装完成后复跑一次校验，确认写入内容未变。

DeepSeek插件 的私有源与哈希清单

私有源没有公开哈希时，需要由发布流程自己生成并维护一份清单。

内部 registry 往往不提供 npm 官方那样的完整性字段，或者字段由代理生成、可信度有限。这种情况下，发布流水线应当在打包后计算哈希，把包名、版本和哈希写进内部清单。安装前拿清单比对，才能形成闭环。

清单本身也要有可信的传递方式。放在和包同一个目录、用同一个账号可写，等于没有校验。更稳妥的做法是让清单走独立的发布记录或制品库，并对写入权限做限制。

私有源的价值是可控，而不是免检。来源可控只降低了外部替换的风险，内部误发布、版本覆盖和构建不一致仍然存在。把哈希清单和发布记录结合使用，才能真正回答「这个包是从哪来的」。

来源：npm package.json 文档、npm pack 文档、deepseek-harness 仓库。