Сборка Git из исходников с проверкой GPG-подписи архива: пошаговое руководство

Как правильно проверить подпись исходников Git с помощью GPG

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

В чем заключается проблема?

Вы скачали архив исходного кода Git с официального сайта Kernel.org вместе с файлом подписи, но при попытке проверить подпись командой gpg --verify возникли ошибки о том, что нет соответствующего публичного ключа. При этом вы заметили две разные подписи, но не можете найти или получить подходящий публичный ключ в ключевых серверах и репозиториях.

Следующие команды демонстрируют типичную попытку проверки подписи, которая закончилась ошибкой:

$ wget https://www.kernel.org/pub/software/scm/git/git-2.51.0.tar.xz
$ wget https://www.kernel.org/pub/software/scm/git/git-2.51.0.tar.sign
$ unxz git-2.51.0.tar.xz
$ gpg --verify git-2.51.0.tar git-2.51.0.tar.sign
gpg: Signature made Wed Jun 15 10:56:46 2016 CEST
gpg:                using RSA key 61092E85B7227189
gpg: Can't check signature: No public key
gpg: Signature made Wed Feb 14 01:02:50 2007 CET
gpg:                using DSA key C0C6D9A4F3119B9A
gpg: Can't check signature: No public key
gpg: verify signatures failed: Unexpected error

Что делать?

Разбор основных ошибок и проверка подписи — варианты решения

Вариант 1. Ошибка порядка параметров в команде gpg --verify

Частая причина ошибки — неправильный порядок аргументов в команде gpg --verify. Правильный синтаксис требует, чтобы первым параметром был файл подписи, а вторым — файл с подписанными данными.

Пример правильной команды:

$ gpg --verify git-2.51.0.tar.sign git-2.51.0.tar

Если выполнить именно её, то вывод будет примерно таким:

gpg: Signature made Mon Aug 18 02:37:32 2025 CEST
gpg:                using RSA key E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB
gpg: Good signature from "Junio C Hamano <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 96E0 7AF2 5771 9559 80DA  D100 20D0 4E5A 7136 60A7
     Subkey fingerprint: E1F0 36B1 FEE7 221F C778  ECEF B0B5 E886 96AF E6CB

В этом случае GPG успешно находит и использует правильный ключ, который был добавлен в локальный хранилище ключей.

Вариант 2. Поиск и импорт правильного публичного ключа

Если ключа у вас нет, то его нужно импортировать из надёжного источника:

  • Проверка Kernel.org keyring: Иногда Kernel.org предоставляет собственный связанный ключевой набор, но в случае Git нужный ключ там может отсутствовать.
  • Импорт с ключевых серверов: Многие публичные ключи доступны на сервере ключей, например, Ubuntu keyserver. Для получения ключа используйте команду:
gpg --keyserver keyserver.ubuntu.com --recv-keys E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB

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

Важно: иногда ключ может быть обновлён или ключи меняются с новыми версиями, обращайте внимание на fingerprint (отпечаток ключа) в сообщениях GPG и сверяйте его с источниками, чтобы исключить подмену.

Вариант 3. Использование ключей из git-репозитория («git blob»)

Git и его разработчики часто хранят публичные ключи прямо в исходниках или в метаданных репозитория. Вы можете загрузить и импортировать ключ напрямую из git blob, если он совпадает с ключом, которым подписан релиз. Это особенно удобно, когда ключ не доступен на публичных серверах, но известен и проверен сообществом.

Практические рекомендации

  1. Используйте корректный синтаксис команды: gpg --verify [signature-file] [data-file]. Никогда не меняйте порядок аргументов.
  2. Импортируйте публичный ключ: получите ключ с официального ключевого сервера или из проверенного git-репозитория.
  3. Сверяйте отпечаток ключа (fingerprint) с официальной документацией или сайтами, чтобы быть уверенным, что ключ настоящий.
  4. Проверяйте предупреждения GPG: GPG может выдать предупреждения о том, что ключ не сертифицирован, но это не всегда значит, что подпись плохая — просто значит, что вы не добавили его в доверенную цепочку.
  5. При сомнениях используйте несколько источников: например, Kernel.org, git-репозиторий и публичные ключевые серверы.

Итог

Ошибка, с которой сталкиваются многие при проверке подписи Git-архивов, чаще всего связана с неверным использованием утилиты gpg, а не с отсутствием ключа. Важно помнить, что первым параметром у команды gpg --verify всегда должна идти подпись, а вторым — файл с данными. После этого, при необходимости, нужно скачать и импортировать ключ с доверенного сервера или из репозитория. Тогда проверка подписи пройдет успешно, и вы сможете быть уверены в целостности и подлинности исходников.

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *