Сразу к делу: --skippgpcheck отключает проверку GPG-подписи исходников при сборке пакета. Это нормально, когда ты сам автор PKGBUILD и доверяешь исходникам на сто процентов. Для случайного AUR-пакета от незнакомого автора флаг опасен: ты выключаешь единственную проверку того, что скачанный архив создал именно автор, а не кто-то другой. Сначала разберись, почему подпись не прошла, и только потом решай, отключать ли проверку.
При сборке 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 говорит makepkg пропустить шаг проверки подписей целиком:
makepkg --skippgpcheck
Сборка пойдёт дальше, как будто подпись проверена и сошлась. Звучит удобно, но цена высокая.
Ты отключаешь единственную проверку происхождения исходников. Если архив подменили, ты соберёшь и установишь чужой код, даже не заметив. Во время сборки скрипты из архива выполняются от имени пользователя, а при установке пакета хуки и файлы ставятся с правами root. Злоумышленник получает исполнение кода на твоей машине. Именно так распространяют вредоносные пакеты в AUR. AUR-обёртки вроде yay и paru умеют пробрасывать флаг в makepkg, так что отключить проверку можно одной командой. Удобно, но обёртка не добавляет безопасности: она просто передаёт флаг дальше.
Ещё одна ловушка: --skippgpcheck не отменяет проверку хэшей. Если в PKGBUILD указаны sha256sums, makepkg их всё равно сверит. Но хэш подпись не заменяет. Хэш подтверждает, что файл не менялся с момента, когда его посчитали, а подпись подтверждает, что файл создал конкретный человек.
Когда makepkg ругается на неизвестный ключ, первое желание: найти ключ в интернете и импортировать. Останавливайся. Ключ из случайного источника может принадлежать злоумышленнику. Если ты импортируешь чужой ключ и он совпадёт с подписью на подменённом архиве, makepkg сочтёт проверку успешной. Ты получишь ложное чувство безопасности.
Импортируй ключи только из проверенных мест: страница релиза на официальном сайте, README в репозитории, ключевой сервер, если отпечаток ты взял с официального источника. Отпечаток сверяй внимательно, посимвольно. Сокращённые идентификаторы вроде ABCDEF12 не подходят: их можно подделать. Только полный отпечаток из сорока символов.
Есть ситуации, где флаг не опасен.
Ты сам написал PKGBUILD, сам положил исходники в source=(). Подписывать их некому и незачем: ты и есть автор. Проверка подписи тут бессмысленна, и --skippgpcheck ничего не ломает.
Многие проекты не подписывают релизные архивы вообще. Тег в git подписан, а tarball на GitHub нет. Если ты доверяешь проекту и следишь за ним давно, пропуск проверки не добавит риска. Но убедись, что скачиваешь с официального источника, а не из левого зеркала. Проверь, как проект публикует исходники: если релизы выходят только как git-теги, а архивов с подписями нет, значит, проверять нечего. В таком случае --skippgpcheck просто убирает шаг, который всё равно не сработал бы.
В chroot, контейнере или виртуалке для теста флаг безвреден. Даже если исходник окажется злым, песочница ограничит ущерб. Для экспериментов это нормальный путь.
Скачал архив, сверил хэш с официальной страницей релиза, посмотрел diff. Тогда подпись не нужна: ты уже проверил файл своими руками.
Ты не знаешь человека, не видел его других пакетов, не читал PKGBUILD. Отключать проверку подписи в такой ситуации значит собирать код вслепую. Сначала прочитай PKGBUILD, разбор того, на что смотреть, есть в статье «Безопасность AUR: проверка PKGBUILD».
Пакет собирался годами, и вдруг подпись перестала сходиться. Версия выросла, а .sig пропал или ключ сменился. Это повод остановиться и разобраться, а не добавить флаг. Внезапная смена ключа бывает легитимной, но проверять нужно вручную.
Если PKGBUILD содержит install-хуки, сервисы или правки системных файлов, риск выше. Такой код выполняется с максимальными правами, и пропуск проверки подписи здесь особенно опасен.
Почти всегда проблему можно решить без отключения проверки.
Если ключ не найден, добавь его в связку:
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 ругается, значит, проблема в связке ключей, а не в файле.
Если ты поддерживаешь PKGBUILD сам, пропиши отпечаток ключа явно:
validpgpkeys=('0123456789ABCDEF0123456789ABCDEF01234567')
Тогда makepkg примет только подпись этого ключа, а не любого из связки. Так ты защитишься от подмены ключа в будущем: даже если в связку попадёт чужой ключ, makepkg его проигнорирует.
Для архивов без подписей сверь контрольные суммы с официальной страницей релиза:
sha256sum foo-1.2.3.tar.gz
Совпадение хэша не гарантирует безопасность, если страница релиза взломана, но это лучше, чем ничего.
Ключ, которым подписан архив, отсутствует в твоей связке GnuPG. Импортируй его через gpg --recv-keys и повтори сборку. Это нормальная ситуация, а не признак атаки. Если ключ не находится на сервере, проверь, правильный ли отпечаток ты передаёшь.
Само по себе нет. Истёкший ключ значит, что автор не продлил срок действия, а не что файл подменили. Обнови ключ через gpg --refresh-keys или свяжись с автором. Опасно другое: если подпись не сходится при живом ключе.
Да. Обе AUR-обёртки передают флаг в makepkg. Но в yay и paru есть свои способы обойти проверку, и пользоваться ими стоит так же осторожно. Перед сборкой обёртка всё равно покажет тебе PKGBUILD, читай его. Установка пакетов из AUR разобрана в статье «Установка пакетов из AUR».
Сравни отпечаток ключа из вывода gpg --verify с тем, что указан на сайте проекта. Если отпечаток другой, а автор не менял ключ, это тревожный сигнал. Не собирай такой пакет, пока не разберёшься.
--skippgpcheck решает симптом, а не причину. Ошибка проверки подписи почти всегда лечится импортом ключа, его обновлением или ручной проверкой. Отключай проверку только для своих PKGBUILD и доверенных исходников, а для случайных AUR-пакетов сначала разберись, почему подпись не сошлась. Пять минут на gpg --verify дешевле, чем переустановка системы после вредоносного пакета.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии