ljudina/aur-security-checker

# aur-check 一个用于 **AUR 软件包更新**的安全检查器。在您升级之前，它会检查 待处理更新的 `PKGBUILD` / `.install` 脚本和 AUR 元数据，并标记出 任何看起来像供应链恶意软件的内容。 AUR 软件包是任意的、未经审查的 shell 脚本，会在构建和安装时 在您的机器上运行。近期的攻击利用了被遗弃软件包的接管， 以及拼写错误的 `-bin` 软件包，这些软件包的构建脚本会从 攻击者控制的主机拉取有效载荷。`aur-check` 正是为了捕获这些行为模式而构建的。 ## ⚠ 免责声明 **这是一个信息辅助工具，而非绝对保证。** 启发式算法和 AI 分析都可能出错——引发误报，并且（更危险的是） **漏掉真正的恶意软件**。干净的结果**并**不意味着软件包是安全的。 在继续操作之前，请务必**亲自**阅读您从 AUR 安装或 升级的任何内容的 `PKGBUILD` 和 `.install` 文件。将此工具视为 触发警报的绊线以及帮助您集中注意力的解释器—— 切勿以此代替您自己的审查。您必须对自己运行的内容负责。 ## 工作原理（混合分析） 1. **启发式算法——始终运行、确定性、离线。** 规则引擎根据每个 软件包的构建脚本*及其* AUR 元数据对其进行评分。信号最强的两项检查是 **维护者变更 / 被遗弃的软件包**以及**与您上次信任的 PKGBUILD 进行 diff**—— 恶意软件通常以您已有软件包的*更改*的形式出现。新添加的风险行的权重更高。 2. **LLM——仅针对被标记的软件包。** 达到升级层级的软件包 将被发送到 LLM（通过 [LiteLLM](https://docs.litellm.ai/)），以获取关于其*意图*的 自然语言判定——从而捕获正则表达式遗漏的混淆或新逻辑， 并澄清被启发式算法过度标记的良性但不同寻常的模式。 风险层级：`ok < low < suspicious < high`。 ## 安装 需要 `pacman`、`git` 和 Python 3.11+（用于 `tomllib`）。AUR 助手 （`paru` 或 `yay`）用于列出待处理的更新；两者均受支持并 可自动检测。 ``` git clone && cd repo-check chmod +x aur-check # 可选：启用 LLM 第二阶段 python -m venv .venv && . .venv/bin/activate pip install -r requirements.txt # installs litellm ``` LLM 阶段是完全可选的——使用 `--no-llm`（或未安装 `litellm`）， 该工具将完全依靠启发式算法运行，且没有任何第三方依赖。 ### API key 提供商密钥从其标准环境变量中读取（例如 `ANTHROPIC_API_KEY`）。为了方便起见，`aur-check` 还会从当前目录 和 `~/.config/aur-check/` 自动加载 `.env` 文件——环境中 已设置的变量具有优先权，并且 `.env` 永远不会被提交（它被 git 忽略）。`.env` 示例： ``` ANTHROPIC_API_KEY=sk-ant-... ``` ## 用法 ``` ./aur-check # scan pending AUR updates (default) ./aur-check --all # scan every installed AUR package ./aur-check anydesk-bin # scan specific package(s) ./aur-check --no-llm # heuristics only ./aur-check --json # machine-readable output ./aur-check -q # suppress the live progress indicator ./aur-check --no-diff -v # hide diffs, show verbose per-package progress ``` 在扫描时，终端会显示实时进度行（`[n/N] 正在扫描 …`）—— 这非常有用，因为大部分时间都花在了从 AUR 获取每个软件包上。 它被写入 stderr，因此 stdout 上的 `--json` 输出保持整洁； 当输出被管道传输时它会自动禁用，而 `-q/--quiet` 会将其完全关闭。 它**绝不进行任何升级**——它只进行读取。当有任何 软件包达到 `fail_threshold` 层级时，退出代码为非零，因此您可以控制是否进行升级： ``` ./aur-check && yay -Sua # only upgrade if nothing high-risk was found ``` ### LLM 判定如何影响结果（平衡策略） 显示并用于退出代码的层级是应用 LLM 判定**之后**的 启发式层级： - LLM 可以**升级**——恶意 / high / critical 的判定会强制设为 `HIGH`； - LLM 可以**降级**被标记的软件包，但最多只能降至 `LOW`——它 绝不会将其完全隐藏，因此您仍然可以看到它以及其推理过程； - 缺失、出错或无法解析的判定将保持启发式层级不变。 因此，被 LLM 澄清的启发式误报（例如，供应商引用其自己的 IP）会降至 `LOW` 并停止阻止您的升级，而任何被 LLM 视为恶意的软件包都将无法通过关卡。报告会标记任何更改，例如 `LOW …（LLM 从 HIGH 降低）`。 ## 配置 可选项，位于 `~/.config/aur-check/config.toml`（参见 `config.example.toml`）。 LLM 提供商由模型字符串选择，密钥来自该 提供商的标准环境变量： ``` [llm] enabled = true model = "anthropic/claude-sonnet-4-5" # -> ANTHROPIC_API_KEY # model = "openai/gpt-4o" # -> OPENAI_API_KEY # model = "gemini/gemini-1.5-pro" # -> GEMINI_API_KEY # model = "ollama/llama3" # 本地，无需 key [scan] escalate_threshold = "suspicious" # min tier sent to the LLM fail_threshold = "high" # exit non-zero at/above this tier ``` ## 标记内容 **构建脚本**（`PKGBUILD`、`*.install`）：将远程下载通过管道传递给 shell；对下载内容执行 `eval`；在 install 钩子内进行网络活动；持久化 （cron / shell-rc / autostart / ssh keys）；从原始 IP 或 paste/file-drop 主机获取；内联编码的 blob；`${IFS}` / `\x` 混淆；在 构建过程中使用 `sudo`；等等。 **元数据**（AUR RPC）：自上次扫描以来维护者发生更改；被遗弃的软件包； 极近期提交；社区信任度低。 启发式算法倾向于召回率（宁可过度标记），这就是为什么存在 LLM 第二阶段的 原因——用于解释和裁决。将 `aur-check` 视为绊线和 解释器，而**不是**替代您自己阅读被标记的 PKGBUILD。 ## Prompts LLM 使用两个 prompt，并作为可编辑模板保存在 `prompts/` 中： - `prompts/system.md` —— 分析师角色和 JSON 输出指令。 - `prompts/user.md` —— 每个软件包的有效载荷。字段通过 纯字符串替换注入到 `{{TOKEN}}` 标记（`{{PACKAGE}}`、`{{PKGBUILD}}`、`{{DIFF}}`、…）处，因此充满 `$`/`{`/`}` 的 PKGBUILD 内容将 原样嵌入，绝不会遭到破坏。 随意调整它们，或者通过配置中的 `[llm] prompts_dir` 指向您自己的副本。 ## State 缓存在 `~/.cache/aur-check/` 下：上次扫描的每个 PKGBUILD 的副本（用于 diff）以及每个软件包已知的最后维护者（用于变更检测）。 首次运行会建立此基准；变更检测从第二次运行开始生效。 ## 测试 ``` python -m unittest discover -s tests ``` ## 贡献 / 扩展 有关架构、项目不变量和常见更改（新增启发式规则、元数据信号、LLM 提供商、输出 格式）的方法，请参阅 [AGENTS.md](AGENTS.md)。它是为 AI 编程代理编写的， 但也适用于人类贡献者。 ## 许可证 [MIT](LICENSE) © 2026 Marko Jovanovic (ljudina@gmail.com)

标签：Arch Linux, AUR, DLL 劫持, DNS 反向解析, 云安全监控, 大语言模型, 网络信息收集, 逆向工具, 配置审计, 静态分析