Проверка подписанных git-коммитов?


С более новыми версиями git можно подписывать отдельные коммиты (в дополнение к тегам) с помощью ключа PGP:

git commit -m "some message" -S

а вы можете показать эти подписи в выводе git log С :

$ git log --show-signature
commit 93bd0a7529ef347f8dbca7efde43f7e99ab89515
gpg: Signature made Fri 28 Jun 2013 02:28:41 PM EDT using RSA key ID AC1964A8
gpg: Good signature from "Lars Kellogg-Stedman <[email protected]>"
Author: Lars Kellogg-Stedman <[email protected]>
Date:   Fri Jun 28 14:28:41 2013 -0400

    this is a test

но есть ли способ программно проверить подпись на данном коммите, кроме как путем grepping вывода git log? Я ищу эквивалент фиксации git tag -v -- что-то, что обеспечит код выхода, указывающий была ли действительная подпись на данном коммите или нет.

3   57  

3 ответа:

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

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

посмотреть commit e18443e,commit aeff29d,commit ca194d5,совершить 434060e,commit 8e98e5f, commit a4cc18f, commit d66aeff (21 июня 2015) by Брайан м. Карлсон (bk2204).
(слитый Junio C Hamano--gitster-- на commit ba12cb2, 03 авг 2015)

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

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

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

плюсы:

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


git 2.9 (июнь 2016) обновление git merge doc:

посмотреть совершить 05a5869 (13 мая 2016) by Келлер Фукс (`).
Помог-by:Junio C Hamano (gitster).
(слитый Junio C Hamano--gitster-- на совершить be6ec17, 17 мая 2016 года)

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

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


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

посмотреть commit b624a3e (16 авг 2016) by Линус Торвальдс (torvalds).
(слитый Junio C Hamano--gitster-- на совершить 83d9eb0, 19 авг 2016)

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

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

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


Git 2.11+ (Q4 2016) будет еще точнее.

посмотреть совершить 661a180 (12 окт 2016) by Michael J Gruber (mjg).
(слитый Junio C Hamano -- gitster-- на совершить 56d268b, 26 окт 2016)

состояние проверки GPG, показанное в "%G?" pretty format specifier не был достаточно богат, чтобы отличить подпись, сделанную истекшим ключом, подпись, сделанную отозванным ключом, и т. д.
новые выходные буквы были назначены, чтобы выразить их.

по данным gpg2 это doc/DETAILS:

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

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

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

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

посмотреть commit 4fea72f,commit 02c5433,commit ff3c8c8 (17 Jan 2017) by Сантьяго Торрес (SantiagoTorres).
Смотрите commit 07d347c,совершить 2111aa7,совершить 94240b9 (17 Jan 2017) by Lukas Puehringer (`).
(слитый Junio C Hamano -- gitster-- на commit 237bdd9, 31 янв 2017)

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


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

посмотреть commit 7f8ca20,commit ca779e8 (10 дек 2017) by Hans Jerry Illikainen (`).
(слитый Junio C Hamano--gitster-- на commit 0433d53, 28 Дек 2017)

merge добавить параметр config для verifySignatures

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

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

The git merge config man page гласит:

merge.verifySignatures:

если true, то это эквивалентно --verify-signatures командная строка выбор.


Git 2.19 (Q3 2018) еще более полезен, так как"git verify-tag" и "git verify-commit "научились использовать статус выхода базового"gpg --verify" чтобы сигнализировать плохую или ненадежную подпись, которую они нашли.

Примечание: с Git 2.19, gpg.format это может быть установлено в "openpgp" или "x509", и gpg.<format>.program это используется для указания того, какую программу использовать для работы с форматом) разрешить X. 509 certs с CMS через "gpgsm" вместо openpgp через "gnupg".

посмотреть commit 4e5dc9c (09 Авг 2018) by Junio C Hamano (gitster).
Помог-by: Vojtech Myslivec (VojtechMyslivec),Брайан м. Карлсон (bk2204) и Джефф Кинг (peff).
(слитый Junio C Hamano--gitster-- на совершить 4d34122, 20 авг 2018)

gpg-interface: распространение статуса выхода из gpg назад к звонящим

когда GPG-интерфейс API унифицировал поддержку кодовых путей проверки подписи для подписанных тегов и подписанных коммитов в середине 2015 года примерно на v2.6.0-rc0~114, мы случайно ослабили проверку подписи GPG.

перед этим изменением подписанные коммиты были проверены путем поиска "G "подпись ood от GPG, игнорируя статус выхода"gpg --verify" процесс, в то время как подписано теги были проверены, просто передав статус выхода "gpg --verify " до конца.

единый код, который мы в настоящее время имеем, игнорирует статус выхода "gpg --verify " и возвращает успешную проверку, когда подпись соответствует неистекшему ключу независимо от доверия, помещенного на ключ (т. е. В дополнение к "G"ООД, мы принимаем "U " ntrusted ones).

сделать эти команды сигнализируют о сбое с их статусом выхода при базовом"gpg --verify" (или пользовательская команда, указанная"gpg.program " переменная конфигурации) делает так.
Это существенно изменяет их поведение обратно несовместимым образом, чтобы отклонить подписи, которые были сделаны с ненадежными ключами, даже если они правильно проверяют, как это"gpg --verify" ведет себя.

обратите внимание, что код по-прежнему переопределяет нулевой статус выхода, полученный из "gpg" (или gpg.program) если вывод не говорит, что подпись хороша или вычисляется правильно, но сделана с ненадежным ключи, чтобы поймать плохо написанную обертку вокруг"gpg" пользователь может дать нам.

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

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

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

вы можете настроить вывод через что-то вроде --pretty "%H %G?%" чтобы сделать его легко разобрать.

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