一次普通更新，为什么需要额外检查
打开终端，运行 yay，看一眼待升级列表，按下确认——这是很多 Arch 用户熟悉的日常。昨天还正常使用的 AUR 包，今天换了维护者，更新里多了一个安装脚本；包名没变，版本号看起来也很普通，但脚本已经开始下载并执行另一份代码。你以为自己只是在升级播放器，实际上却可能把恶意程序一起带进了系统。
这样的风险已经在 AUR 中实际出现：
- 2026 年 5 月，
plex-media-player被恶意接管。 5 月 27 日，用户报告这个无人维护的 AUR 包被当天注册的新账号接管，并加入了在安装后调用 npm 安装crypto-javascript的脚本。Arch 包维护者随后确认，被拉取的 npm 包在preinstall二进制中含有恶意软件，并清除了恶意提交、删除了三个相关仿冒包。一次播放器更新，就这样被接上了另一条恶意软件下载链。见 aur-general 的报告与处理记录。 - 2026 年 6 至 7 月，AUR 连续出现恶意接管与更新。 Arch 在 6 月 12 日的官方公告中确认出现大量恶意包接管和更新，提醒用户检查每次更新中的 PKGBUILD 和安装脚本变化。到了 7 月 30 日，DevOps 团队又因大量恶意接管及后续提交，宣布临时关闭包接管功能。
这些事件直接触及 AUR 用户的日常：以前用过的包，不代表下一次更新仍然可信。 AUR 提供的是用户提交的构建配方，配方和安装脚本本身就能执行代码；检查需要发生在执行之前。官方包则有签名验证这道保障，但签名同样不能回答新加的代码会做什么。逐次核对配方、源码和产物的变化很有必要，却也很难靠人手在每次升级时完整做完。
所以我做了 safe-syu：在 Arch Linux 的官方包升级和 AUR 构建中，把“这次到底改了什么、哪些地方还没检查、最后装进去的是不是审过的那份”整理成可复核的证据，在执行构建配方或安装软件之前留出检查机会。项目以 MIT 协议开源，结合规则检查和可配置的 AI 审阅后端生成报告，再把最终安装绑定到实际审过的软件包。内置审阅启动器使用需要单独安装和认证的 Codex CLI，选中的打包文件和源码会发送到配置的后端。上述事件是项目动机的例子，不代表 safe-syu 已验证能够检出这些攻击；安装脚本进一步下载的全部内容也不在完整审计范围内。
safe-syu、pacman、yay 和 AUR 分别做什么
理解 safe-syu 的位置，可以先把“软件从哪里来”和“谁负责安装”分开看：
| 名称 | 在流程中的职责 |
|---|---|
| pacman | 从配置的软件仓库获取包，安装、升级、卸载，并维护本机的包数据库 |
| AUR | 存放社区提交的 PKGBUILD 等构建配方，描述下载来源和打包步骤 |
| makepkg | 执行构建配方，把源码或上游二进制制作成可安装的软件包 |
| yay | 帮用户获取 AUR 配方、调用 makepkg 构建，并协调 pacman 安装 |
| safe-syu | 在执行配方与安装产物之前加入审计，确认后通过 libalpm 安装审过的软件包 |
例如，安装一个 AUR 播放器时，yay 先取得配方，makepkg 按配方下载、构建和打包，最后才进入安装阶段。构建配方本身就能执行命令，因此检查不能只放在最后安装时。 safe-syu 会在 makepkg 执行前设置审阅关卡，并在构建完成后检查实际生成的包。
单独执行 pacman -Syu 会升级配置仓库中的软件包，不会调用 yay 或查询 AUR。已经通过 AUR 安装的软件仍由 pacman 记录和管理，但获取新版 AUR 配方并重新构建，通常需要 yay 等助手。safe-syu 使用 pacman 底层的 libalpm 完成安装；pacman、makepkg 和可选的 yay 仍需保留。
对用户来说，配置完成后，可以把 safe-syu upgrade 作为日常升级已安装软件的统一入口，由它协调官方包和 AUR 两条流程。它目前专注于审计与升级，搜索、新装、卸载及故障修复仍需结合 yay、pacman 等工具。它也不会在后台自动接管所有包管理操作：直接运行 pacman -Syu 不会经过 safe-syu，直接调用 makepkg 或使用未接入的 AUR 助手也能绕过检查。
两条审计流程，分别守住执行和安装入口
官方仓库这条流程会在隔离的数据库快照中解析升级，验证包签名，对比精确版本的构建配方、安装脚本、服务和其他敏感文件，并对支持的上游源码输入生成差异证据。还可以选择做可复现构建，检查重建产物是否与官方包一致。
审计之后还需要解决一个问题：最后安装的必须是刚才审过的那份。确认安装时，工具会重新核对产物与系统状态，再通过 libalpm 提交冻结并加锁的事务，避免审阅之后又临时换包或下载其他依赖。报告与包文件之间有明确的绑定关系，审阅结果才有对应的安装对象。
AUR 这条流程通过可选的 yay 集成，在执行 PKGBUILD 前调用 aurscan 审阅配方，构建完成后再单独检查生成的软件包。配方和产物审阅都必须成功且返回 OK，可疑结果或执行失败都会停止流程。构建需要的官方依赖也会进入官方包审计，而不是在安装时绕过检查补齐。
两条流程可以概括为下图。官方包的部分风险或覆盖缺口允许用户明确接受后继续，恶意判定会阻断；AUR 的两次审阅都必须成功返回 OK。图中的“允许继续”只表示满足工具的检查条件。
flowchart TD subgraph official["官方仓库软件包"] O1["隔离数据库快照<br/>解析升级与依赖"] --> O2["验证包签名<br/>审阅配方、敏感文件与源码差异<br/>可选：可复现构建"] O2 --> O3{"报告是否允许继续？<br/>部分风险需明确接受"} O3 -->|否| OX["停止官方包流程"] O3 -->|是| O4["核对产物、终端确认<br/>加锁后复验系统与冻结事务"] O4 --> O5["复验通过后安装官方包<br/>提交期间禁止下载"] end subgraph aur["AUR：可选 yay 集成"] A1["执行 PKGBUILD 前<br/>审阅构建配方"] --> A2{"成功返回 OK？"} A2 -->|否| AX["停止 AUR 流程"] A2 -->|是| A3["依赖就绪后以普通用户构建<br/>记录配方与产物绑定关系"] A3 --> A4["单独审阅生成的软件包"] A4 --> A5{"成功返回 OK？"} A5 -->|否| AX A5 -->|是| A6["核对记录与产物、明确确认<br/>通过检查后安装 AUR 包<br/>安装器不下载缺失依赖"] end A1 -.->|需要的官方依赖也进入审计| O1
日常升级，可以只记住一个入口
开始使用前，需要按项目文档安装 safe-syu 及依赖、配置并认证审阅后端。使用 AUR 流程还需安装支持版本的 yay 和 aurscan，然后以普通用户启用集成并检查环境：
safe-syu integrate yay
safe-syu doctor如果只使用官方包流程，可以先用 safe-syu doctor --official-only 检查对应依赖，无需启用 yay 集成。完成准备并熟悉报告后，日常升级可以按范围选择：
| 升级范围 | 命令 |
|---|---|
| 官方包和 AUR 包 | safe-syu upgrade |
| 仅官方包 | safe-syu upgrade --repo-only |
| 仅 AUR 包 | safe-syu upgrade --aur-only |
统一升级时，官方阶段成功后才开始 AUR 更新；过程中仍需阅读报告并按提示确认，各安装阶段可能分别要求确认。如果 AUR 构建还需要额外的官方依赖，这些请求也会进入官方包审计。这里的“一个入口”指协调升级步骤，不是无人值守地自动批准所有变更。
首次试用时，可以先把官方包的检查和安装分开：
safe-syu audit
safe-syu show
safe-syu verify这三个命令分别生成审计报告、展示结果、核对产物与事务一致性，都不会安装升级包。读完报告并决定安装后，再运行 safe-syu apply。例如，报告指出下载域名变化或新增 systemd 服务时，可以先检查对应证据，再决定是否继续，而不是看到版本号变大就直接确认。
日常搜索、安装新软件、卸载和故障修复仍需结合原有工具，也需要确认所走路径是否经过审计。yay 集成不透明兼容所有参数，不支持的操作会明确停止。具体配置和命令边界见使用指南。
当前边界与试用范围
当前项目仍处于早期实验阶段，兼容范围限定为 Arch Linux x86_64、Python 3.14+ 和 libalpm ABI 16 等受支持配置。AI 审阅和可复现构建都不能证明软件安全，AUR 构建也不是在恶意软件沙箱中执行；工具不提供原子回滚，尚未完成独立安全审查和干净机器全流程验收。适合熟悉 Arch 的用户先在可丢弃环境中生成报告、检查证据，再考虑实际安装。
如果你也关心滚动更新中的供应链风险，可以看看 GitHub 仓库、使用指南和安全模型。欢迎试用，也欢迎通过 Issue 反馈兼容性问题和审计流程中的不足。