「社区实验」dshlib —— DSH 插件图书馆：装前可见"可信几级、扫描过没有、多少人真在用"（呼应 #3192）

[wwumit]

dshlib —— DSH 插件图书馆（实验）：装前可见"可信几级"

dshlib 是一个社区实验：DSH 插件图书馆——收录、验证、展示 DSH 插件，每插件带 CHA2A 认证徽章 + 安全扫描状态，装前可见"谁发布的、是否被改、可信几级、扫描过没有、多少人真在用"，以及边界的诚实（可信 ≠ 无漏洞）。

图书馆：https://compliancehub.cn/store/
提交通道：https://github.com/dshlib/dshlib（Issue 模板）
开源：数据 + 验证/扫描工具全部开放

这不是一个成品，是一个实验——邀请社区一起来做。

为什么做这个实验：社区对插件安全的呼声（#1115 投毒担忧、provenance 缺失）。我们想验证一个技术框架：插件可信度能不能"可验证"而不是"靠声明"——装前看到的是证据（内容指纹、验证记录、扫描结果），不是广告词。

实验里能看到什么（每插件）：

• CHA2A 认证等级（L0-L4）：内容完整性（npm 官方哈希）→ 来源（作者）→ 发行（真实验证）→ 生态（多方独立验证）
• 作者 + 周下载量：谁维护的（GitHub 链接）、多少人真在用（npm 周下载，热度信号）
• 安全扫描状态：已扫描 ✓ / 待审查（四类规则：硬编码密钥/危险命令/数据外传/越权），每插件有独立扫描报告页（自研命中位置 + GuardDog 复核原始输出 + OSV 依赖漏洞，点开即查）
• 验证报告：每插件的证据存档（点开可查）
• 边界透明：认证 ≠ 无依赖漏洞——认证验证插件包本身（内容完整性/来源/发行/生态），依赖漏洞独立标注（OSV.dev），两者正交，不互相掩盖

怎么参与实验：

• 提交你的插件：Issue 模板（Add:）→ 自动验证 → 上架带徽章（1 个工作日内）
• 参与验证：独立复核——成为验证方（L4 交叉验证邀请）
• 提出质疑：收录标准、验证方法、展示方式，任何意见都欢迎——实验就是用来打磨的

实验的依据：

• 设计讨论：#3192 提案讨论｜CHA2A：智能体生态身份与来源认证规范——四层标识 × 分层签名 × 认证等级，欢迎去拍砖
• 依据国家标准设计：身份与验证机制依据 GB/Z 185《人工智能 智能体互联》（国标：身份码/身份管理/能力描述）构建
• 验证方法全公开（收录与验证标准页）
• 验证报告存档可查（证据链）
• 第三方复核：GuardDog 3.2.0（PyPI 官方恶意包检测）已复核 305 个——232 通过 / 73 有提示（多为 API key 处理等启发式命中，均列"待人工审"，无确认恶意）；OSV.dev 抽查 10 个插件的依赖漏洞（2 个检出已知漏洞，已标注）
• 认证等级 = 验证证据，不靠声明（CHA2A 规范，W3C 注册中）
• 数据/API 全开放（任何市场可消费）

与官方的关系：社区项目，非官方——建立在官方机制之上（dsh-plugin topic、bundle 规范），与 #2269/#3176 等互补。

[wwumit]

更新（发帖后 1 天）：

• 收录 401 → 402（新增 agent-comms 系列：智能体互联网通信治理——信任/披露/合规，CHA2A L3）
• 外部生态开始对齐 CHA2A：Optional host-owned ToolRuntime attestation and settlement anchor for external plugins #3223 ToolRuntime 结算锚点提案已确认采用 §4.7 词汇（contentIdentity/anchorId/anchorGeneration）——"装的是发布的"（注册表侧）和"跑的是被验证的"（运行时侧）词汇统一
• 我们自己的 4 个仓库 README 加了认证徽章（示例：dsh-plugin-tools）——等级图 + 动态验证（注册表一改，徽章自动同步）
  一个我们没完全想清楚的问题：
  图书馆里有真实案例：dsh-cc-tui 是 L4 生态认证（内容/来源/发行/多方验证全过），但依赖树里查出 10 个已知漏洞（OSV.dev 标注）。我们目前的立场是"认证等级 ≠ 无漏洞，两者正交"——装前两个信号都摆出来，用户自己权衡。
  但有个疑问想抛出来：

如果你在选插件，一个"高认证等级但有依赖漏洞"，和一个"认证一般但扫描全干净"，你会怎么权衡？ 是信任优先（等级高 = 发布者可信，漏洞可等修复），还是安全优先（扫描干净 = 当下无已知风险）？