如何验证 DSH 插件的真实性

插件名字不等于身份。装任何东西之前，先做 verify plugin authenticity：确认发布者是谁，确认你手上这个包就是他们发布的那个，再确认中间没有人掉过包。这就是 plugin verification 的大部分内容，大约五分钟。这篇先讲 publisher check，再讲包本身，然后讲那些能告诉你前两步有一处没通过的迹象。DSH plugin authenticity 本质上是把三个互相独立的来源对在一起，而 how to verify a plugin publisher 恰恰是大家因为名字看着对就跳过的那一步。

publisher check 要放在最前面

名字很便宜，发布者身份不便宜，而且它是唯一一个没法在不留痕迹的情况下被复制的东西。

• 到注册表以外的地方找这个发布者。真发布者会有仓库、站点或账号，而且存在时间早于这个插件。如果这个发布者唯一的存在痕迹就是插件页面，请把这当成一条结论，而不是一个待补的细节。
• 把发布账号的年龄和插件的年龄对一下。账号和第一个版本在同一周创建的，本身证明不了什么，但值得你再多花两分钟。
• 确认发布者是否真的拥有它声称的命名空间。看起来像抢注的命名空间、以及把已知发布者名字改掉一两个字母的写法是最常见的模式，展开写在 /blog/how-to-spot-renamed-or-cloned-dsh-plugin。
• 找一找有没有第二个版本。有历史的发布者会有旧版本可供 diff；只有一个版本、没有历史的，你无从比较。

然后检查你真正下载到的那个包

发布者和包是两个问题。同一个发布者可以有好插件和坏上传，而落到你机器上的是后者。

• 拿发布者自己公布的校验值或签名去对，不要拿注册表显示的去对。注册表是三个来源之一，不是权威。
• 安装钩子在运行之前先读一遍。钩子正是一个表面干净的包真正干活的地方，机制写在 /blog/how-install-script-scanning-works。
• 把文件清单和上一个版本 diff 一下。发布说明里完全没提的新文件，值得要一个解释。
• 看看这个包在 setup 阶段对外连了什么。首次运行就去拉第二个二进制，正是多数告警围绕的那个模式。

这些方法在哪些地方会失效

有三种情况会让上面的检查落空，值得单独点名，因为每一种的解法都不一样。

• 中间商。包装了别的发布者作品的插件，不会继承原发布者的任何检查，这正是 /blog/plugin-middleman-trust 的全部内容。
• 改名或克隆的包。代码一模一样，名字是新的，所以包本身看不出任何问题，只有发布者比对能抓到。
• 完全没有足迹的发布者。小作者确实存在，也发布好东西。当没有任何东西可核验时，退回发布历史和文档质量这两项，两者都写在 /blog/how-to-evaluate-plugin-documentation-quality。

验证不是对代码下的判决。它回答的是一个更窄的问题：这个包是不是来自它声称的那个人。

五分钟的流程

按顺序跑，任何一条不通过就停下。

• 打开注册表以外的发布者页面，确认它的存在时间早于这个插件。
• 拿发布者的发布页去对校验值或签名。
• 把安装钩子读一遍。
• 把文件清单和上一个版本 diff 一下。
• 四条里有两条对得上、且没有一条不通过，就可以装上，然后盯住第一周。

常见问题

• 高分就等于通过验证了吗？不等于。评分覆盖维护状况、文档质量、生态健康度和安装期行为，它不确认这个包是谁上传的。评分背后的评审流程在 /blog/dsh-plugin-review-process。
• 发布者完全没有任何线上存在怎么办？退回发布历史和文档。有六个版本、README 写得清楚的发布者，比只上传过一次的更输不起。
• 每个插件都要这么查吗？不用。凡是碰到凭据、CI 或生产环境的才需要。优先级怎么排在 /blog/how-to-avoid-risky-dsh-plugins。
• 注册表的徽章能替代 publisher check 吗？不能。徽章只说明注册表对自己的记录做了匹配，而这些记录是三个来源之一，不是答案。

验证只是其中一道闸门。dshquality.com 上每个插件都有评分页，写明哪些查过、哪些没查，你能直接看到自己面对的是整幅图的哪一半。评分为什么独立于开发者自报数据，写在 /blog/why-independent-plugin-scoring-beats-self-reported-ratings，我们发布的全部文章在 /blog。