supernovae-st/nika-registry

# nika-registry [](https://github.com/supernovae-st/nika-registry/actions/workflows/verify.yml) [](https://github.com/supernovae-st/nika-spec/blob/main/registry/registry-v0.1.md) [](CATALOG.md) **共享 Nika 制品：workflows · packs · skills · agents：在这里，每个 条目都是由机器重新证明的，而不是由把关人信任的。** 每个应用市场都用点赞数、下载量或版主来回答“这安全吗？”。 而这个 registry 用**你可以自己重新运行的证明**来回答：每个条目都将其 源固定到一个完整的 commit + 一个完整的 sha256，并且 CI 会重新获取字节、 重新计算哈希，并在每个 PR 和每晚重新运行 [conformance oracle](https://github.com/supernovae-st/nika-spec)。 条目中的 `[cert]` 块仅供参考 - **证明就是 `scripts/verify.py`，而且你可以针对镜像离线运行它。** 信任存在于制品之中， 而不在这个 repo 里。 ## 安装：一条可审计的命令 ``` git clone https://github.com/supernovae-st/nika-registry && cd nika-registry python3 scripts/get.py --list # what exists python3 scripts/get.py meeting-actions # fetch → verify sha256 → local audit → done ``` `get.py` 在出现任何不匹配（哈希 · 安全公告 · 覆盖）时都会拒绝执行，并且绝不会 执行任何东西：workflow 只是存入磁盘，由**你**决定是否运行它。 这不是 `curl | sh`：你已经克隆了这个 repo，你可以先阅读这 140 行代码。 **Agents**：获取一次 [`index.json`](index.json) 即可包含每个制品的 固定版本、摘要、证书摘要和安全公告状态；[`llms.txt`](llms.txt) 以 agent 可读的形式教授消费/验证路径。 **徽章**：每个制品都有一个实时证书徽章 - `https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/supernovae-st/nika-registry/main/badges/--.json` ## 发布（一个 PR） 你的制品保留在**你的** git repo 中：registry 只存储一个指针、 一个摘要和一个证明，绝不存储副本。命名空间 = repo 所有权（Go 模型）：`registry/workflows///.toml`， 并且 CI 会拒绝发布者不拥有源 repo 的条目。 1. 让你的 workflow 通过 `nika check`（或 `conformance/runner.py validate`）。 2. 添加条目文件（复制 ENTRY_TEMPLATE.toml（或任何种子条目））。 3. 发起一个 PR：CI 会重新证明它（哈希 · oracle · 密钥 · 许可证 · 命名空间）。 ## 第一方制品的来源 `supernovae-st/*` 条目**不是**一个手动维护的列表：它们是 **规范的标准 pack 的投影**（`scripts/project_pack.py` · 在 CI 中通过 `--check` 门控）。向 [nika-spec](https://github.com/supernovae-st/nika-spec) 添加一个展示， 重新运行投影器，它就会在这里发布：registry 不能偏离这个 pack。 社区制品依然通过 PR 进行编写。 ## 契约 这个 registry 实现了 **[registry-v0.1](https://github.com/supernovae-st/nika-spec/blob/main/registry/registry-v0.1.md)**， 这是 Apache-2.0 规范中的规范性共享契约：任何人都可以运行一个 合规的 registry（组织内部、镜像、fork），并且所有客户端与它们交互的方式都是完全相同的。 ## 规则（每一条都对应一个有记录的 registry 死亡案例） | 规则 | 消除的风险 | |---|---| | 条目是**不可变的**：新版本 = 新文件 · 撤回 = 一个 [advisory](advisories/)，绝不是删除 | left-pad · rug-pulls | | **全 commit + 全 sha256 固定**：没有标签，没有分支 | tj-actions 标签重写 | | CI **重新计算获取字节的哈希** | manifest 混淆 | | CI **重新运行 oracle** | 没有其他人能抓到的类别：损坏/虚假的制品 | | **密钥形状的字符串拒绝通过门控** | n8n 共享模板凭证泄露 | | **命名空间 = 源所有权** | 依赖混淆 · typosquatting | | **零安装时执行**：条目和制品都是数据 | event-stream · Shai-Hulud · ComfyUI | 在运行任何共享 workflow 之前，请阅读其 `permits:` 和 `exec:` 块 - `nika check` 会在**花费任何 token 之前**向你展示完整的影响面（网络 · 文件系统 · 密钥 · 成本）。 这就是 Nika 的核心所在。 ## 目录 · 证书 [`CATALOG.md`](CATALOG.md) 由 ENGINE 对每个固定制品的静态分析 生成（`scripts/cert.py` · 引擎版本在 CI 中由摘要固定）：它可以执行吗？ 使用了哪些工具？有多少次 LLM 调用？成本上限是多少？ 每一行都链接到 [`certs/`](certs/) 下的一个机器证书。没有其他 workflow registry 能够生成这一列：而且你永远不需要信任它： 证书可以在本地使用 `nika check` 重新推导出来。 **“干净”并不等于“安全”。** 证书证明了影响保持在 workflow *声明* 的 permits 范围内：它无法审查被允许的程序或工具实际会做什么。一个 **无限制的授权**（`exec: true` 运行任何程序 · `*` 工具允许任何工具）在所有界面上都 标记为 **⚠**；在那里，“它能做什么”实际上就是“该类别中的任何东西”，所以在运行之前 请务必阅读 workflow。⚠ 标志着一个需要检查的授权，而不是一个不安全的判决。 ## 撤回 · 安全公告 一个被破坏或有缺陷的版本**永远不会被删除**（为了可重现性）：它 会在 [`advisories/`](advisories/) 中获得一个 advisory（受 OSV 启发），消费者 和未来的 `nika add` 会在安装时检查它。 ## 许可证 Registry 元数据：Apache-2.0。每个制品都带有自己的 `license` 字段。

标签：AI代理, Python, Python安全, 哈希校验, 无后门, 网络安全研究, 资源仓库, 软件供应链, 逆向工具