Nixalon-Torasu/aevum-rrp

# Aevum RRP — OpenSSF 版 **面向系统、事件及 AI 相关证据的凭证优先溯源。** **OpenSSF 版：** 本仓库是 Aevum 技术栈的信任根、验证器和凭证引擎。工作站是打印机验证并应用的一个配置文件——而非对等的同级节点。 关于变更内容，请参阅下方的 [OpenSSF 集成](#openssf-integration)。 Aevum RRP 是一个协议及实现技术栈，用于请求、生成、传输和验证关于被观测事件的 **凭证**。其目标很简单： 本仓库是当前 **RRP 规范**、**参考实现**、**模式**、**策略**、**测试向量** 以及用于生成和验证签名发布产物的周边 **workstation / boot / packaging** 机制的公共源。 ## 存在原因 大多数软件系统只能告诉你它们 *声称* 发生了什么。极少数系统能够证明它们观测到了什么、何时观测的、受何种策略约束、以及在整个时间过程中是否保持了连续性。 Aevum RRP 的存在正是为了填补这一空白。 它面向的是这样一个世界： - 系统发出机器可验证的凭证，而非松散的日志， - 连续性至关重要， - 篡改、分叉和间断情况必须可检测， - 下游工具 —— 包括 AI 系统 —— 应当消费 **有边界的证据**，而不仅仅是文本或未经验证的状态。 ## 仓库内容 本仓库不仅仅是一个 README 和一个示例脚本。它包括： - **RRP 参考实现** - **协议/规范材料** - **模式与策略** - **测试向量与验证工具** - **bootkit / pack / workstation 支持产物** - **发布清单与签名材料** 在仓库根目录下，目前暴露的目录包括 `bootkit`、`pack`、`refimpl`、`scripts`、`systemd`、`tools` 以及支持的清单/安全文件，这使得它的范围远超一个简单的“bootstrap”仓库 :contentReference[oaicite:4]{index=4} 当前的包还包括： - `refimpl/rrp_v0_1/SPEC_RRP_v0.1.1.md` - `refimpl/rrp_v0_1/run_demo.sh` - 示例 payload - 模式文件，如 `rrp_receipt_request.schema.json` 和 `rrp_receipt_result.schema.json` - `pack/policies` 下的策略 - `pack/tests` 下的测试运行器和向量 :contentReference[oaicite:5]{index=5} :contentReference[oaicite:6]{index=6} :contentReference[oaicite:7]{index=7} ## 当前状态 **状态：** pre-1.0 / 积极 R&D 阶段 这是一个严肃的公开进行中的工作，而非成品。 已包含的内容： - 协议方向， - 参考实现， - 验证逻辑， - 模式与策略， - 发布打包结构， - 以及面向证据的工作流片段。 未声明的部分： - 完整的生产级加固， - 最终的协议稳定性， - 完整的文档覆盖， - 或完全简易的安装体验。 如果您正在寻找一个完善的消费级产品，那不是本项目。 如果您关注溯源、连续性、证明和证据边界，这个仓库是正确的起点。 ## 仓库结构 ### refimpl/ 当前 RRP 工作的参考实现，包括规范、验证器、keygen、发射器、演示运行器和测试。 ### pack/ 面向发布的打包、模式、策略、测试以及面向 workstation 的捆绑包材料。 ### bootkit/ 引导程序及与发布密钥/信任链相关的运维材料。 ### scripts/, systemd/, tools/ 运维实用程序、自动化以及验证/构建辅助工具。 ### etc/, gitops/, os/ 支持的系统配置、更新流程和安装脚手架。 ## 建议阅读顺序 1. 从仓库根目录开始，了解结构和意图。 2. 阅读 `refimpl/rrp_v0_1/` 下的 RRP 材料 3. 检查 `pack/` 下的模式和策略 4. 审查测试和向量 5. 最后再深入 workstation / boot / packaging 的细节 这个顺序可以避免您将协议与周围的设备机制混淆。 ## 这里“凭证优先”的含义 在此语境下，凭证不仅仅是一行日志。 它旨在成为一种有边界的、策略导向的、机器可验证的产物，并关联于： - 一个被观测事件， - 一个身份上下文， - 一个连续性上下文， - 以及一个验证路径。 这种区别至关重要。 日志可以被编辑、重新解读或脱离策略。 凭证则旨在保持验证边界。 ## 为何 AI 视角至关重要 这里最核心的战略角度不是“又一个日志系统”。 而是： **Aevum RRP 是承载证据的机器上下文的基础设施。** 这对 AI 很重要，因为当前的 AI 管道在溯源方面很薄弱。它们摄取文本、摘要和声明，但往往无法区分： - 观测到的事实 vs 推断出的叙述， - 完整的连续性 vs 破碎的历史， - 已验证的证据 vs 便捷的断言。 RRP 是向系统 —— 包括未来的 AI 层 —— 提供凭证的一步，这些凭证对来源、连续性和验证边界有明确的界定。 ## 安全态势 本仓库应被视为开发和研究的源代码树。 请勿假设： - 每一个历史包中的每一个产物都是发布干净的， - 每一个生成的状态文件都属于 Git， - 或每一个发布包等同于安全的运行时部署路径。 使用签名清单、验证工具和清洁的发布纪律。 将私密材料、运行时状态和生成碎片视为对公共仓库有害的内容，除非明确意图如此。 有关项目安全指南，请参阅 `SECURITY.md`。 ## 贡献 本项目仍在塑造中。 有价值的贡献是指那些能增加： - 协议清晰度， - 验证器严格性， - 模式精确度， - 策略明确性， - 可复现性， - 以及运维人员理解程度的贡献。 低价值的贡献包括表面修整、模糊的抽象以及任何削弱验证边界的内容。 如果您提交 issue 或 PR，请倾向于： - 具体的主张， - 确切的失败案例， - 可复现的向量， - 以及有边界的语言。 ## 设计立场 Aevum RRP 采取强硬立场： **如果一个声明很重要，它应该经得起验证。** 这意味着这项工作倾向于： - 明确的格式， - 连续性检查， - 严格的验证器结果， - 溯源优于叙述， - 以及证据优于感觉。 ## 路线图方向 近期方向包括： - 收紧公共协议表面， - 改进验证器语义， - 明确模式和策略边界， - 清理仓库/发布分离， - 并加强公开文档，使外人无需了解整个 Aevum 项目即可理解协议。 ## 许可证 根据 AGPL v3.0 许可。请参阅 `LICENSE`。 ## OpenSSF 集成 本版新增： | 文件 | 用途 | |---|---| | `bootkit/bin/aevum-provenance-verify` | 在任何应用操作之前验证 Sigstore 签名、in-toto 布局和 SLSA 溯源 | | `etc/aevum/registry/supply_chain_policy.json` | 允许的签名者、SLSA 基线、Rekor 要求、凭证策略 | | `refimpl/rrp_v0_1/schemas/supply_chain_receipt.schema.json` | 供应链凭证类型的模式 | `aevum-bootstrap-apply` 在任何安装步骤之前调用 `aevum-provenance-verify`。在 `locked` 模式下，溯源验证是一个硬性关卡。在 `install` 和 `maintenance` 模式下，它运行并记录日志，但不会阻断。 `aevum-bootstrap-update` 现在将 `provenance` 部分写入 `BUNDLE_MANIFEST.json`，在存在时将路径链接到 SLSA、in-toto 和 Sigstore 材料。 供应链凭证 **仅通过摘要** 引用 OpenSSF 材料 —— 指针而非载荷。综合陈述是：*"此工作站配置文件是由此经验证的供应链过程构建的，且此确切机器在连续性的此时此刻，以此确切的本地身份和状态接受并应用了它。"* ## 最后说明 本仓库之所以公开，是因为核心理念已足够成熟可以公开： **可验证凭证作为连续性、溯源和机器可读证据的一等基板。** 它尚未完成。 它也不假装已完成。 但它已不再是空谈。

标签：AI安全, Chat Copilot, Cutter, DNS 解析, OpenSSF, Zenmap, 事件溯源, 人工智能安全, 信任链, 可验证计算, 合规性, 子域名变形, 安全协议, 密码学, 手动系统调用, 数字取证, 数字收据, 数据完整性, 签名验证, 系统完整性, 网络安全, 自动化脚本, 软件供应链安全, 远程方法调用, 连续性验证, 防篡改, 隐私保护, 零信任架构