Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Чтобы узнать, что делает AUR-пакет, прочитай его PKGBUILD до установки. Это bash-скрипт, который makepkg выполняет от имени твоего пользователя: он скачивает исходники, собирает программу и раскладывает файлы по системе. Всё, что пакет делает, записано в этом файле, и чтение занимает пару минут. В AUR публикует пакеты любой желающий, поэтому проверка перед установкой не паранойя, а обычная гигиена. Ниже разбор: где лежит PKGBUILD, как читать его построчно и как сравнить с оригинальным апстримом.
yay и paru клонируют пакет в свой кэш перед сборкой. yay хранит копии в ~/.cache/yay/<имя-пакета>, paru в ~/.cache/paru/clone/<имя-пакета>. Каталог остаётся после установки, так что заглянуть в него можно в любой момент:
ls ~/.cache/yay/имя-пакета
ls ~/.cache/paru/clone/имя-пакета
Внутри лежат PKGBUILD, .SRCINFO и, возможно, дополнительные файлы: .install, патчи, сервисы systemd. .SRCINFO это машинное описание пакета, оно дублирует PKGBUILD в упрощённом виде, читать его не обязательно. Читай именно PKGBUILD, а не описание на сайте AUR. В описании автор рассказывает, что пакет должен делать, а в скрипте видно, что он делает на самом деле.
Кэш пригодится и при обновлениях. Перед тем как хелпер соберёт новую версию, загляни в каталог пакета и посмотри, что поменялось. Если ты чистил кэш, например через paccache, копии пропадут, и хелпер клонирует пакет заново. Тогда проверяй свежий PKGBUILD с нуля.
Если пакет ещё не установлен, скачай его без сборки:
yay -G имя-пакета
paru -G имя-пакета
Команда клонирует пакет в текущий каталог. Дальше открывай PKGBUILD и читай. Как устроен AUR и как ставить из него пакеты, разобрано в статье «Установка пакетов из AUR».
PKGBUILD состоит из переменных и функций. Читай в таком порядке: source, sha256sums, потом build() и package(), в конце depends и .install. Начни с простого просмотра:
cat PKGBUILD
Если файл длинный, не читай его целиком. Сначала пробегись глазами по source и функциям, потом углубляйся в подозрительные места.
source это список адресов, откуда makepkg скачивает исходники. Сверь домены с официальным сайтом программы. Если источник лежит на личном сервере или файлообменнике, а в комментариях никто не объясняет почему, это повод насторожиться. Легитимный пакет почти всегда берёт исходники оттуда же, откуда их скачивает сам проект.
sha256sums это контрольные суммы для каждого файла из source. makepkg сверяет скачанное с этими значениями и останавливает сборку при несовпадении. Значение SKIP для обычного архива означает, что целостность не проверяется вообще. Для git-исходников SKIP нормален, там содержимое меняется при каждом клонировании. Сверить суммы вручную можно командой makepkg -g: если вывод не совпадает с PKGBUILD, исходник менялся или подменён.
Заодно сверь переменную url и pkgver. url должен вести на живой сайт проекта, а pkgver совпадать с последним релизом. Версия, которая опережает апстрим, подозрительна: её не существует, и пакет может оказаться подделкой.
| build() компилирует программу: configure, make, cmake, cargo build. package() раскладывает собранное в $pkgdir. Всё остальное в этих функциях подозрительно: curl, wget, запуск скриптов, запись в системные каталоги, изменение прав. Строка вида curl … | bash скачивает и выполняет код, который ты не видел. Сравни build() и package() с тем, как программа собирается вручную: лишние шаги должны иметь объяснение. |
Обрати внимание на каталоги. $srcdir это временная папка сборки, $pkgdir временная папка пакета. package() должен писать только в $pkgdir, а не в настоящий корень системы. Одна строка с записью в /usr или /etc внутри package() может подменить файлы других пакетов.
Зависимости должны соответствовать программе. Пакет для скриншотов не тянет криптографические библиотеки, а простой конвертер не нуждается в сетевых модулях Python. Лишние зависимости часто маскируют вредоносную нагрузку. Сверь список с официальными требованиями апстрима. makedepends нужны только для сборки, в установленной системе их нет, поэтому лишние записи там менее опасны, но тоже говорят о небрежности автора.
Самый надёжный способ проверить пакет: сравнить его PKGBUILD с официальным. Многие проекты хранят PKGBUILD прямо в своём репозитории, а Arch держит собственные в gitlab.archlinux.org. Официальные PKGBUILD собраны в каталоге packages, там видно, как сопровождающие собирают каждую программу. Сравнение с ними полезно и для AUR-пакетов: если программа есть в официальных репозиториях, а AUR-версия собирается иначе, разберись, зачем.
Если пакет уже в кэше и обновился, посмотри, что поменялось с прошлой версии:
git diff PKGBUILD
Команда работает, потому что yay и paru клонируют пакет через git. Хелперы показывают этот diff перед сборкой при обновлении, не пропускай его. Особенно внимательным будь, если пакет долго не обновлялся, а тут вдруг вышла новая версия. Заброшенный пакет мог перейти к новому мейнтейнеру, и это нормально, но проверь, что он поменял.
Сравнение с апстримом делается так: открой официальный PKGBUILD проекта и сравни построчно с тем, что в кэше. Отличия должны быть объяснимы: правки под Arch, патчи, особенности сборки. Необъяснимые отличия это повод остановиться. Если хочешь понять, как выглядит грамотный PKGBUILD, посмотри статью «Стиль написания PKGBUILD: гайды».
Иногда в source лежат готовые бинарники вместо исходников. Проверь их до сборки:
file имя-файла
ldd имя-файла
file покажет тип файла, ldd список библиотек, которые он тянет. Подозрительно, когда бинарник огромный, а программа простая, или когда ldd показывает неожиданные библиотеки. Собранный из исходников пакет всегда предпочтительнее чёрного ящика с готовым бинарником. Если бинарник в пакете есть, а исходников нет, объяснить его происхождение автор не сможет.
Дополнительно можно прогнать strings по бинарнику и поискать подозрительные строки: адреса, команды, имена процессов. Это грубая проверка, но она иногда сразу выдаёт лишние обращения к сети. Помни: готовый бинарник в AUR это уже повод задать вопрос, даже если file и ldd выглядят чисто.
Собери список красных флагов, чтобы проверка занимала минуту:
| curl | bash или wget с последующим запуском в build() и package(). |
Один красный флаг ещё не значит, что пакет вредоносный. Иногда автору действительно нужно скачать что-то в build(), например шрифты или данные для тестов. Но каждый такой случай должен быть объяснён в комментариях или в описании пакета. Нет объяснения, не ставь.
Подробный разбор каждого признака есть в статье «Безопасность AUR: проверка PKGBUILD».
Файл .install подключается через переменную install и содержит функции pre_install, post_install, pre_remove, post_remove. Они выполняются от root при установке и удалении пакета.
post_install обычно делает одно из трёх: создаёт пользователя, обновляет кэш или перезапускает службу. Всё остальное требует объяснения. Правка /etc/hosts, добавление задач в cron, скачивание из сети от root это повод отказаться от пакета.
Прочитай .install так же внимательно, как PKGBUILD. Последствия post_install остаются в системе навсегда, даже если пакет потом удалить. systemctl enable для сервиса, который ставит сам пакет, ещё можно понять, а вот изменение /etc/sudoers или /boot без причины это уже опасно.
Не забывай и про pre_remove с post_remove. Они выполняются при удалении пакета и тоже работают от root. Вредоносный код может прятаться там: например, удалять файлы за пределами пакета или оставлять после себя скрытые процессы. Проверяй все четыре функции, а не только post_install.
Да. Даже у популярного пакета мейнтейнер может смениться, а PKGBUILD измениться. Пять минут чтения дешевле переустановки системы. Особенно внимательно проверяй пакеты, которые ставишь впервые, и те, что долго не обновлялись. Быстрый чек-лист из десяти вопросов есть в статье «Проверка PKGBUILD: 10 вопросов».
Разберись, чем именно. Правки под Arch, патчи и особенности сборки нормальны. Необъяснимые отличия, особенно в source и build(), повод отказаться от пакета. Если сомневаешься, поищи альтернативу: официальный пакет в репозиториях или другой AUR-пакет с чистой историей.
grep -E "(curl|wget|bash|python|pip)" PKGBUILD
Команда покажет обращения к сети и запуски скриптов. Дальше смотри каждую найденную строку в контексте: что именно скачивается и куда выполняется. Добавь в grep имена других интерпретаторов, если пакет написан на необычном языке.
namcap это анализатор PKGBUILD и собранных пакетов. Он проверяет ошибки, лишние зависимости и проблемы с файлами:
namcap PKGBUILD
namcap имя-пакета-версия-архитектура.pkg.tar.zst
Первый запуск до сборки, второй после. namcap не найдёт майнер, но покажет небрежность автора: забытые зависимости, лишние файлы, неправильные права. Чистый вывод namcap хороший знак, но не заменяет чтение PKGBUILD.
Проверка AUR-пакета сводится к трём шагам: прочитай PKGBUILD, сравни его с апстримом, проверь .install и бинарники. source должен указывать на официальный адрес, sha256sums быть заполнены, build() и package() делать только сборку и упаковку. Любая строка с curl, wget или запуском скрипта требует объяснения. На проверку уходит пять минут, а защищает она от майнеров и подменённых исходников. Привычка читать PKGBUILD перед установкой окупается при первом же подозрительном пакете. Начни с одного пакета, и скоро проверка войдёт в привычку.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии