识别克隆插件主要是个核对工作。热门 DSH 插件的副本很少去改代码，因为插件克隆的目的是借走信任，而不是写软件，所以仿冒插件在页面上往往看着都对，差别藏在元数据里。下面说怎么在一个克隆插件跑起来之前发现它：从名称、作者、发布记录和安装脚本四处核对，以及当你已经信任的清单里出现一个改名插件包时该怎么办。
克隆会复制什么，又会留下什么
克隆不是重写，是重新上传。而能跨过重新上传幸存下来的部分，恰好就是值得查的部分。
- README 和描述。整段照抄，连错别字一起，这是你能拿到的最快线索。
- 代码。通常一模一样，所以比对源码没有大家以为的那么有用。
- 安装脚本。有时会加东西，真正的风险就在这里。
- 带不过来的：作者、提交历史、发布节奏、issue 区。这四样挂在仓库上，不挂在文件上。
这个不对称为整套方法提供了依据：去比对克隆搬不走的那几项。
识别克隆插件的四处核对
按顺序做。任何一处对不上，都值得再看仔细；两处同时对不上，就值得跳过这个插件。
| 核对项 | 看哪里 | 克隆的信号 |
|---|---|---|
| 名称 | 插件页以及它的仓库或包名 | 熟悉的名字多了一个后缀、换了分隔符，或者出现一个你不认识的 scope |
| 作者 | 把 owner 字段和原始仓库对照 | 账号是最近才建的，或者除了这个插件什么都没发布过 |
| 发布记录 | 首次发布日期和版本数量 | 首次发布的时间晚于原版走红，而且只有一个版本 |
| 安装脚本 | 详情页上被扫描过的安装步骤 | 原版根本不带安装脚本，这个副本却带 |
仿冒插件和正经 fork 的区别
不是每个副本都有恶意，把 fork 一律当成攻击会制造大量噪音。下面四条区分在实践中站得住。
- fork 会说明。它的 README 会写出上游项目并链回去。
- fork 会改东西。一个 diff、一个新功能、一个锁定的依赖。克隆发布的是相同的文件。
- fork 用自己的名字，或者一眼能看出的变体。仿冒插件直接拿走名字，只挪一个连字符。
- fork 的历史你可以读。克隆只有一个提交，日期在上周。
fork 想要的是这次改动带来的认可，克隆想要的是原版已经攒下的安装量。
改名插件包已经装上了怎么办
难办的不是决定装不装，而是发现你已经在跑的东西是个副本。四步，按顺序。
- 别慌着卸载。先把版本、安装时间和来源记下来，因为万一它真的有恶意，你要用的正是这些。
- 把安装脚本和原版对照。如果副本自己加了一段，那就按事故处理，而不是按清理处理。
- 查这个插件能碰到什么。凭据、网络访问、写文件，这三样才是要紧的。
- 换回原版，然后盯着分数。索引对两个都评分，两者之间的差距通常是你能拿到的最清楚的一份总结。
让克隆进不了团队的清单
靠个人谨慎只能管一次，清单才能让这件事重复发生。
- 每条插件都记下作者，不只是名字。克隆改的是名字，留的是你认得的那个词。
- 每月复查一次清单，不要只在安装那一刻查。装的时候没问题的插件，之后也可能被改名。
- 盯等级变动，不只是盯低分。副本的分数通常比它模仿的原版更低。
- 新申请统一个人过。多数仿冒插件能进来，是因为没有人被指定去看。
完整索引在 dshquality.com，每个分数背后的四根支柱写在 /blog/dsh-quality-score-decoded。相关阅读：/blog/plugin-supply-chain-security-team-enforcement 讲副本是怎么到你的机器上的，/blog/how-to-avoid-risky-dsh-plugins 讲评估这一步，/blog/tag-baiting-problem 讲那些让克隆看起来很官方的命名手法。所有文章都在 /blog。
常见问题
- 克隆能通过代码审查吗？能，因为它通常就是同一份代码。信号在元数据、作者和发布记录里，不在 diff 里。
- 分数低就能证明是克隆吗？不能。克隆往往因为没有历史、没有维护而分数更低，但光是分数低只意味着该再看一眼。
- 我发布的插件被别人克隆了怎么办？在副本上开 issue，通过注册源举报，并在自己的 README 里链回原版。原版把自己标清楚之后，多数副本就消失了。
- 没有安装脚本的克隆也要在意吗？程度轻一些，但仍然要在意。今天不带安装脚本的副本，可以在后面的版本里加一段恶意的，这正是发布记录要排在信任决定之前的原因。