Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Перед установкой пакета из AUR прочитай PKGBUILD и ответь на десять вопросов: откуда берутся исходники, совпадают ли контрольные суммы, кто мейнтейнер, что делают build() и package(), куда лезут post_install и зависимости. Если хотя бы на один вопрос ответ сомнительный, пакет лучше не ставить. Вся проверка занимает пять минут и защищает от вредоносных пакетов, которых в AUR хватает. AUR устроен так, что любой может опубликовать пакет, поэтому ответственность за безопасность лежит на тебе. Чем больше пакетов ты ставишь из AUR, тем важнее привычка читать PKGBUILD: одна ошибка перекрывает годы аккуратной работы.
PKGBUILD лежит на странице пакета в AUR, а при установке через yay или paru копируется в каталог сборки. Оба менеджера показывают PKGBUILD перед установкой: yay спрашивает, хочешь ли ты его посмотреть, paru показывает diff. Не пропускай этот шаг. Три команды дают почти всю картину:
cat PKGBUILD
makepkg -g # покажет актуальные контрольные суммы для source
grep -E "(curl|wget|bash)" PKGBUILD
Первая команда показывает весь файл, вторая сверяет суммы, третья ищет обращения к сети и запуски скриптов. Если PKGBUILD слишком длинный, начни с source, sha256sums и функций build() и package(). Остальное читается по мере необходимости. Дальше пройдись по чек-листу из десяти пунктов. На каждый вопрос отвечай честно, без скидок на «ну это же популярный пакет».
source должен указывать на официальный апстрим: репозиторий проекта на GitHub, страницу релизов или сайт программы. Сравни адрес с тем, что написано в README проекта. Если в source домен, о котором ты никогда не слышал, или адрес, не имеющий отношения к программе, это повод остановиться. Легитимный пакет почти всегда берёт исходники оттуда же, откуда их скачивает сам проект. Проверка занимает минуту: открой страницу проекта и посмотри, откуда там качают исходники.
sha256sums должны содержать реальные значения, а не SKIP. Команда makepkg -g выведет суммы для текущих исходников: если они не совпадают с тем, что в PKGBUILD, исходник менялся или подменён. SKIP допустим только для git-исходников, где содержимое меняется при каждом клонировании. Для обычных архивов SKIP означает, что целостность не проверяется вообще. Подробный разбор честных проверок есть в статье «Безопасность AUR: проверка PKGBUILD». Несовпадение суммы с makepkg -g не всегда злой умысел, иногда автор просто забыл обновить PKGBUILD, но в обоих случаях пакет требует внимания. Суммы в PKGBUILD и в makepkg -g должны совпадать один в один, без исключений.
На странице пакета в AUR видно имя мейнтейнера и дату последнего обновления. Хороший знак, когда мейнтейнер известен и у него есть история других пакетов. Свежий аккаунт с одним пакетом и без истории настораживает. Загляни в комментарии: если пользователи жалуются на проблемы, это сигнал. Пакет, который не обновлялся два года, тоже повод задуматься, особенно если программа активно развивается. Мейнтейнер может передать пакет другому человеку, и новый владелец не всегда так же аккуратен. История пакета в AUR тоже доступна: посмотри, как часто менялся PKGBUILD и кто вносил правки.
| Готовые .so, .bin и архивы с бинарниками вместо исходников настораживают, особенно когда программа простая, а бинарник огромный. curl | bash в build() или package() скачивает и выполняет код, который ты не видел. pip install внутри PKGBUILD тоже тянет код из интернета в обход проверки сумм. Собранный из исходников пакет всегда предпочтительнее, чем чёрный ящик с готовым бинарником. Если бинарник в пакете есть, а исходников нет, объяснить его происхождение автор не сможет. Правило простое: исходники должны быть исходниками. |
Сборка должна компилировать и раскладывать файлы. Если в build() есть rm -rf, перезапись чужих файлов, обращение к сети или правка системных каталогов, это лишние действия. package() должен писать только в $pkgdir, а не в настоящий корень системы. Одна лишняя строка в этих функциях может снести половину системы или подменить файлы других пакетов. Сравни build() и package() с тем, как программа собирается вручную: лишние шаги должны иметь объяснение. Если build() вызывает незнакомые скрипты, найди их в $srcdir и прочитай перед сборкой.
Скрипты установки выполняются с правами root. Если post_install правит /etc/passwd, /etc/sudoers или /boot, а тем более скачивает что-то из сети, это опасно. Легитимные .install обычно создают пользователя, обновляют кэш или перезапускают службу. Любое действие за пределами этих трёх сценариев требует объяснения, и объяснение должно быть в комментарии к пакету. Файл .install подключается в PKGBUILD через переменную install, и его содержимое читается так же легко, как и сам PKGBUILD. post_install выполняется один раз при установке, но его последствия остаются навсегда.
depends должны совпадать с реальными потребностями программы. Лишние зависимости раздувают систему, а дублированные, когда одна и та же библиотека в depends и makedepends, говорят о небрежности автора. Сверь список с официальными требованиями апстрима. Если пакет тянет за собой что-то тяжёлое без видимой причины, например базу данных или графический фреймворк, спроси себя, зачем это программе. Лишняя зависимость не так опасна, как подмена исходников, но она показатель качества пакета. Проверить зависимости легко: pactree покажет, что тянет пакет.
Флаги, отключающие проверку подписей и TLS, в PKGBUILD недопустимы. wget –no-check-certificate, pip с http-адресом, git clone без проверки подписи обходят защиту. Такие флаги означают, что автор либо небрежен, либо намеренно скрывает подмену исходников. Оба варианта достаточны, чтобы отказаться от пакета. Отключение проверки подписи в официальных пакетах Arch не встречается, и в AUR ему тоже не место. Если флаг отключения проверки появился недавно, сравни текущий PKGBUILD с прошлой версией через историю пакета.
pkgver должен соответствовать последней версии на официальной странице релизов. Отставание на год просто означает устаревший пакет, это не опасно, но неудобно. А вот pkgver, опережающий апстрим, подозрителен: версии, которой ещё нет, не существует, и пакет может оказаться подделкой. Сверь pkgver с релизами проекта за пару минут. Для git-пакетов версия часто собирается из даты коммита, и это нормально, если в source указан конкретный репозиторий проекта.
pastebin, случайные git-репозитории, личные серверы и сокращатели ссылок в source это красный флаг. Легитимные пакеты берут исходники с официальных страниц релизов или из репозиториев проекта. Если источник нельзя проверить, пакет ставить нельзя. Абнормальный адрес почти всегда означает, что автор что-то прячет. Даже если остальные девять пунктов чистые, один подозрительный источник перечёркивает всё.
Устанавливай, когда все десять ответов положительные: официальный источник, честные суммы, известный мейнтейнер, чистая сборка и адекватные зависимости. Если сомневаешься хотя бы в одном пункте, поищи альтернативу: официальный пакет в репозиториях, другой AUR-пакет с чистой историей или ручную сборку из исходников. Общая инструкция по установке из AUR есть в статье «Установка пакетов из AUR», а реальные случаи вредоносных пакетов разобраны в статье «Вредоносные AUR-пакеты 2026». Помни: пропустить проверку проще, чем потом разбираться с последствиями.
Да. Даже у популярного пакета мейнтейнер может смениться, а PKGBUILD измениться. Пять минут чтения экономят переустановку системы. Привычка проверять каждый пакет вырабатывается за пару недель и дальше занимает совсем немного времени. Особенно внимательно проверяй пакеты, которые ставятся впервые.
Для git-исходников это нормально. Для обычных архивов SKIP означает, что целостность не проверяется вообще. Такой пакет ставь только после тщательной проверки остальных пунктов чек-листа. Если сомневаешься, попробуй найти тот же пакет с честными суммами.
grep -E "(curl|wget|bash)" PKGBUILD покажет обращения к сети и запуски скриптов. Дальше смотри каждую найденную строку в контексте: что именно скачивается и куда выполняется. Добавь в grep python и pip, если пакет на Python.
Число голосов говорит о популярности, а не о безопасности. Вредоносный пакет успевает набрать голоса до того, как его заметят. Сравнение yay и paru с точки зрения безопасности есть в статье «yay vs paru: какой безопаснее». Голоса полезны как индикатор, что пакет работает, но не как гарантия чистоты. Проверяй PKGBUILD независимо от числа голосов.
Удали пакет и проверь систему: pacman -Qkk покажет повреждённые файлы, журнал и автозагрузку стоит просмотреть вручную. Методика проверки целостности описана в статье «Проверка целостности: pacman -Qkk». Если нашёл следы вмешательства, восстанови файлы из официальных пакетов через pacman -Syu.
Проверка PKGBUILD сводится к десяти вопросам: источник, суммы, мейнтейнер, бинарники, build(), post_install, зависимости, флаги безопасности, версия и адреса исходников. Если все ответы положительные, пакет можно ставить спокойно. Если хоть один сомнительный, лучше поискать альтернативу. Пять минут чтения файла перед установкой дешевле, чем переустановка системы после вредоносного пакета. Чек-лист быстро запоминается, и через месяц ты будешь прогонять его автоматически. Начни с одного пакета, и скоро проверка войдёт в привычку.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии