Все об Arch Linux

Arch Linux будет тем, что вы из него сделаете!

Не собрался пакет: --skippgpcheck — когда это нормально

Сразу к делу: --skippgpcheck отключает проверку GPG-подписи исходников при сборке пакета. Это нормально, когда ты сам автор PKGBUILD и доверяешь исходникам на сто процентов. Для случайного AUR-пакета от незнакомого автора флаг опасен: ты выключаешь единственную проверку того, что скачанный архив создал именно автор, а не кто-то другой. Сначала разберись, почему подпись не прошла, и только потом решай, отключать ли проверку.

Зачем makepkg проверяет GPG-подписи

При сборке makepkg скачивает исходники из интернета: архивы с GitHub, GitLab, личных сайтов. Файлы едут по сети, проходят через зеркала и кэши. По дороге их может подменить кто угодно: взломанный сервер, перехват соединения, поддельное зеркало. GPG-подпись закрывает эту дыру.

Механика простая. В PKGBUILD можно объявить массив validpgpkeys=() с отпечатками ключей, которым ты доверяешь. В списке source=() рядом с архивом может лежать файл подписи с расширением .sig. Перед сборкой makepkg берёт подпись, проверяет её ключом из validpgpkeys и сверяет, что архив не менялся. Подпись подтверждает две вещи: файл создал владелец ключа, и содержимое файла дошло без изменений.

Подпись работает на доверии к ключу. Ты сам решаешь, каким ключам верить, и заносишь их отпечатки в validpgpkeys. Отпечаток это строка из сорока символов, подделать её нельзя. Если ключ в списке, makepkg принимает подписи только от него. Если список пуст, makepkg проверит подпись любым ключом из твоей связки, но это слабее: в связке могут лежать ключи, которым ты не доверяешь.

Это тот же механизм, что и у pacman при проверке пакетов из официальных репозиториев. Только там ключами заведует pacman-key, а здесь makepkg работает с обычной связкой GnuPG. Подробно про то, как устроена сборка, написано в статье «makepkg: всё, что нужно знать».

Когда возникает ошибка проверки подписи

Ошибка появляется в трёх типичных случаях.

Ключ не импортирован

makepkg не находит ключ в твоей связке. Вывод выглядит примерно так:

==> Verifying source file signatures with gpg...
    foo-1.2.3.tar.gz ... FAILED (unknown public key 0123456789ABCDEF)

Ключ просто не добавлен в GnuPG. Это самая частая причина, и лечится она импортом ключа, а не отключением проверки. Отпечаток из сообщения об ошибке подскажет, чей это ключ. Сверь его с сайтом проекта: авторы обычно публикуют отпечатки на странице релиза или в README. Только после сверки импортируй ключ. Похожая ситуация бывает и у pacman, разбор есть в статье «pacman-key: unknown public key».

Ключ истёк

Подпись сделана ключом, срок действия которого закончился. GnuPG откажется её принимать, даже если сам ключ у тебя есть. Тут помогает обновление ключа: если автор продлил срок, свежая копия ключа с сервера решит проблему. Проверить срок действия можно командой gpg --list-keys.

Подпись не совпадает

Файл повреждён, подменён или подписан другим ключом. Это самый тревожный случай. Если архив не совпадает с подписью, значит, содержимое изменилось после подписания. Иногда это просто битая загрузка, но иногда это признак атаки. Скачай архив заново: файл мог докачаться с ошибкой. Если повторная загрузка даёт ту же ошибку, сравни отпечаток ключа с официальным и проверь, не сменил ли автор ключ.

Что делает –skippgpcheck и чем это опасно

Флаг --skippgpcheck говорит makepkg пропустить шаг проверки подписей целиком:

makepkg --skippgpcheck

Сборка пойдёт дальше, как будто подпись проверена и сошлась. Звучит удобно, но цена высокая.

Ты отключаешь единственную проверку происхождения исходников. Если архив подменили, ты соберёшь и установишь чужой код, даже не заметив. Во время сборки скрипты из архива выполняются от имени пользователя, а при установке пакета хуки и файлы ставятся с правами root. Злоумышленник получает исполнение кода на твоей машине. Именно так распространяют вредоносные пакеты в AUR. AUR-обёртки вроде yay и paru умеют пробрасывать флаг в makepkg, так что отключить проверку можно одной командой. Удобно, но обёртка не добавляет безопасности: она просто передаёт флаг дальше.

Ещё одна ловушка: --skippgpcheck не отменяет проверку хэшей. Если в PKGBUILD указаны sha256sums, makepkg их всё равно сверит. Но хэш подпись не заменяет. Хэш подтверждает, что файл не менялся с момента, когда его посчитали, а подпись подтверждает, что файл создал конкретный человек.

Почему нельзя просто импортировать любой ключ

Когда makepkg ругается на неизвестный ключ, первое желание: найти ключ в интернете и импортировать. Останавливайся. Ключ из случайного источника может принадлежать злоумышленнику. Если ты импортируешь чужой ключ и он совпадёт с подписью на подменённом архиве, makepkg сочтёт проверку успешной. Ты получишь ложное чувство безопасности.

Импортируй ключи только из проверенных мест: страница релиза на официальном сайте, README в репозитории, ключевой сервер, если отпечаток ты взял с официального источника. Отпечаток сверяй внимательно, посимвольно. Сокращённые идентификаторы вроде ABCDEF12 не подходят: их можно подделать. Только полный отпечаток из сорока символов.

Когда –skippgpcheck оправдан

Есть ситуации, где флаг не опасен.

Твой собственный PKGBUILD

Ты сам написал PKGBUILD, сам положил исходники в source=(). Подписывать их некому и незачем: ты и есть автор. Проверка подписи тут бессмысленна, и --skippgpcheck ничего не ломает.

Доверенный апстрим без релизных подписей

Многие проекты не подписывают релизные архивы вообще. Тег в git подписан, а tarball на GitHub нет. Если ты доверяешь проекту и следишь за ним давно, пропуск проверки не добавит риска. Но убедись, что скачиваешь с официального источника, а не из левого зеркала. Проверь, как проект публикует исходники: если релизы выходят только как git-теги, а архивов с подписями нет, значит, проверять нечего. В таком случае --skippgpcheck просто убирает шаг, который всё равно не сработал бы.

Сборка в изолированном окружении

В chroot, контейнере или виртуалке для теста флаг безвреден. Даже если исходник окажется злым, песочница ограничит ущерб. Для экспериментов это нормальный путь.

Исходники, которые ты проверил сам

Скачал архив, сверил хэш с официальной страницей релиза, посмотрел diff. Тогда подпись не нужна: ты уже проверил файл своими руками.

Когда использовать –skippgpcheck нельзя

Случайный AUR-пакет от неизвестного автора

Ты не знаешь человека, не видел его других пакетов, не читал PKGBUILD. Отключать проверку подписи в такой ситуации значит собирать код вслепую. Сначала прочитай PKGBUILD, разбор того, на что смотреть, есть в статье «Безопасность AUR: проверка PKGBUILD».

Подозрительные обновления

Пакет собирался годами, и вдруг подпись перестала сходиться. Версия выросла, а .sig пропал или ключ сменился. Это повод остановиться и разобраться, а не добавить флаг. Внезапная смена ключа бывает легитимной, но проверять нужно вручную.

Пакеты с правами root

Если PKGBUILD содержит install-хуки, сервисы или правки системных файлов, риск выше. Такой код выполняется с максимальными правами, и пропуск проверки подписи здесь особенно опасен.

Какие есть альтернативы –skippgpcheck

Почти всегда проблему можно решить без отключения проверки.

Импортируй правильный ключ

Если ключ не найден, добавь его в связку:

gpg --recv-keys 0123456789ABCDEF

Для pacman-ключей используется pacman-key:

sudo pacman-key --recv-keys 0123456789ABCDEF
sudo pacman-key --lsign-key 0123456789ABCDEF

После импорта повтори сборку: makepkg сам найдёт ключ и проверит подпись.

Обнови ключи

Истёкший ключ часто лечится обновлением:

gpg --refresh-keys

Команда пройдётся по всем ключам в связке и подтянет свежие копии с серверов.

Проверь подпись вручную

Скачай архив и подпись, проверь их напрямую:

gpg --verify foo-1.2.3.tar.gz.sig foo-1.2.3.tar.gz

Вывод покажет, кто подписал файл и когда. Если подпись валидна, а makepkg ругается, значит, проблема в связке ключей, а не в файле.

Зафиксируй validpgpkeys в PKGBUILD

Если ты поддерживаешь PKGBUILD сам, пропиши отпечаток ключа явно:

validpgpkeys=('0123456789ABCDEF0123456789ABCDEF01234567')

Тогда makepkg примет только подпись этого ключа, а не любого из связки. Так ты защитишься от подмены ключа в будущем: даже если в связку попадёт чужой ключ, makepkg его проигнорирует.

Сравни хэши

Для архивов без подписей сверь контрольные суммы с официальной страницей релиза:

sha256sum foo-1.2.3.tar.gz

Совпадение хэша не гарантирует безопасность, если страница релиза взломана, но это лучше, чем ничего.

Частые вопросы

Почему makepkg пишет «unknown public key»?

Ключ, которым подписан архив, отсутствует в твоей связке GnuPG. Импортируй его через gpg --recv-keys и повтори сборку. Это нормальная ситуация, а не признак атаки. Если ключ не находится на сервере, проверь, правильный ли отпечаток ты передаёшь.

Ключ истёк, это опасно?

Само по себе нет. Истёкший ключ значит, что автор не продлил срок действия, а не что файл подменили. Обнови ключ через gpg --refresh-keys или свяжись с автором. Опасно другое: если подпись не сходится при живом ключе.

–skippgpcheck работает с yay и paru?

Да. Обе AUR-обёртки передают флаг в makepkg. Но в yay и paru есть свои способы обойти проверку, и пользоваться ими стоит так же осторожно. Перед сборкой обёртка всё равно покажет тебе PKGBUILD, читай его. Установка пакетов из AUR разобрана в статье «Установка пакетов из AUR».

Как понять, что подпись подменили?

Сравни отпечаток ключа из вывода gpg --verify с тем, что указан на сайте проекта. Если отпечаток другой, а автор не менял ключ, это тревожный сигнал. Не собирай такой пакет, пока не разберёшься.

Полезные ресурсы

  • Makepkg: документация по сборке пакетов и флагам makepkg.
  • GnuPG: работа с ключами и подписями.

Заключение

--skippgpcheck решает симптом, а не причину. Ошибка проверки подписи почти всегда лечится импортом ключа, его обновлением или ручной проверкой. Отключай проверку только для своих PKGBUILD и доверенных исходников, а для случайных AUR-пакетов сначала разберись, почему подпись не сошлась. Пять минут на gpg --verify дешевле, чем переустановка системы после вредоносного пакета.



Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.

Читайте также

Комментарии

Загрузка…

Откроется GitHub: создайте новый issue с вашим комментарием (кнопка «Submit new issue»). После отправки обновите эту страницу — комментарий появится ниже.

Telegram Max