Ответ 1

На всякий случай кто-то приходит на эту страницу через поисковую систему, как и я: новые инструменты были доступны в течение двух лет с момента публикации вопроса: теперь для этой задачи есть команды git: git verify-commit и git verify-tag можно использовать для проверки коммитов и тегов соответственно.

Ответ 2

Примечание: до git 2.5, git verify-commit и git verify-tag отображается только сообщение для чтения.
Если вы хотите автоматизировать проверку, git 2.6+ (Q3 2015) добавляет другой результат.

См. commit e18443e, зафиксировать aeff29d, commit ca194d5, commit 434060e, commit 8e98e5f, зафиксировать a4cc18f, commit d66aeff (21 июня 2015 г.) brian m. carlson (bk2204).
^{(слияние Junio ​​C Hamano - gitster - в commit ba12cb2, 03 августа 2015 г.)}

verify-tag/verify-commit: добавить параметр для печати информации о состоянии gpg

verify-tag/verify-commit по умолчанию отображает выводимый человеком текст при стандартной ошибке.
Однако также может быть полезно получить доступ к информации о состоянии сырой gpg, которая является машиносчитываемой, позволяя автоматическую реализацию политики подписи.

Добавьте опцию --raw, чтобы verify-tag выводить информацию о состоянии gpg на стандартную ошибку, а не на человеко-читаемый формат.

Плюс:

verify-tag успешно завершается, если подпись хороша, но ключ ненадежный. verify-commit завершается неудачно.
Это расхождение в поведении является неожиданным и нежелательным.
Поскольку verify-tag существовал ранее, добавьте неудачный тест, чтобы иметь поведение verify-commit share verify-tag.

git 2.9 (июнь 2016 г.) обновите git файл слияния:

См. commit 05a5869 (13 мая 2016 г.) Keller Fuchs ( ``).
Помощник: Юнио С Хамано (gitster).
^{(слияние Юнио С Хамано - gitster - в commit be6ec17, 17 мая 2016 года)}

--verify-signatures:
--no-verify-signatures:

Убедитесь, что фиксация наконечника объединенной ветки подписана с допустимым ключом, то есть ключ, который имеет действительный uid: в модели доверия по умолчанию это означает, что ключ подписи был подписан доверенным ключ.
Если фиксация наконечника боковой ветки не подписана с действительным ключом, слияние отменяется.

Обновление git 2.10 (Q3 2016)

См. commit b624a3e (16 августа 2016 г.) Линус Торвальдс (torvalds).
^{(объединено Junio ​​C Hamano - gitster - в commit 83d9eb0, 19 августа 2016 года)}

gpg-interface: предпочитает "длинный" вывод формата ключа при проверке подписей pgp

"git log --show-signature" и другие команды, отображающие статус проверки подписи PGP, теперь показывают более длинный ключ-идентификатор, поскольку 32-разрядный ключ-идентификатор - это последний век.

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

git 2.11+ (Q4 2016) будет даже более точным.

См. commit 661a180 (12 октября 2016 г.) Michael J Грубер (mjg).
^{(слияние Junio ​​C Hamano - gitster - в commit 56d268b, 26 октября 2016 г.}

Состояние проверки GPG, указанное в спецификаторе "%G?" довольно большого размера, недостаточно богато для дифференциации подписи, сделанной с помощью ключа с истекшим сроком действия, подписи, сделанной отмененным ключом и т.д.
Назначены новые выходные буквы, чтобы выразить их.

Согласно gpg2 doc/DETAILS:

Для каждой сигнатуры будет выходить только один из кодов GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG или ERRSIG.

git pretty-format документация теперь включает в себя:

• '%G?': показать
  • "G" для хорошей (действительной) подписи,
  • "B" для плохой подписи,
  • "U" для хорошей подписи с неизвестной достоверностью,
  • "X" для хорошей сигнатуры, срок действия которой истек,
  • "Y" для хорошей подписи, сделанной истекшим ключом,
  • "R" для хорошей подписи, сделанной отмененным ключом,
  • "E", если подпись не может быть проверена (например, отсутствующий ключ) и "N" для отсутствия подписи

git 2.12 (Q1 2017) "git tag" и "git verify-tag" научились ставить статус проверки GPG в формат вывода < <243 > .

См. commit 4fea72f, commit 02c5433, commit ff3c8c8 (17 января 2017 г.) Сантьяго Торрес (SantiagoTorres).
См. commit 07d347c, совершить 2111aa7, совершить 94240b9 (17 января 2017 г.) Лукас Пухрингер (` `).
^{(объединено Junio ​​C Hamano - gitster - в совершить 237bdd9, 31 января 2017 года)}

Добавление --format в git tag -v отключает вывод по умолчанию GPG проверка и вместо этого печатает отформатированный объект тега.
Это позволяет абонентам перекрестно проверять тэг от refs/tags с помощью тэг из заголовка объекта тега при проверке GPG.

git 2.16 (Q1 2018) позволит еще более автоматизировать проверку подписи фиксации с переменной конфигурации merge.verifySignatures.

См. commit 7f8ca20, совершить ca779e8 ( 10 декабря 2017 года) Ханс Джерри Илликайнен (` `).
^{(объединено Junio ​​C Hamano - gitster - в commit 0433d53, 28 декабря 2017 г.}

merge: добавьте опцию конфигурации для verifySignatures

git merge --verify-signatures может использоваться для проверки того, что фиксация наконечника присоединенной ветки правильно подписана, но она громоздка для должны указывать это каждый раз.

Добавить параметр конфигурации, который по умолчанию включает это поведение, которое может быть отменено с помощью --no-verify-signatures.

git merge команда config теперь читает:

merge.verifySignatures:

Если значение true, это эквивалентно опции командной строки --verify-signatures.

Ответ 3

Беглый осмотр кода предполагает, что такого прямого метода нет.

Все тесты в источнике git полагаются на grep ping вывод git show (см. t/t7510-signed-commit.sh для тесты).

Вы можете настроить вывод, используя что-то вроде --pretty "%H %G?%", чтобы упростить синтаксический анализ.

Кажется, вы можете попросить git merge проверить подпись, но опять же, ее тесты полагаются на grep (см. t/t7612-merge-verify-signatures.sh), Это похоже на недопустимую подпись, приведет к тому, что git merge завершится с плохой подписью, поэтому вы могли бы сегодня взломать это, выполнив тестовое слияние где-нибудь и выкинув это слияние, но это кажется хуже, чем просто вызов grep.