У новіших версіях gitможна підписувати окремі коміти (крім тегів) ключем PGP:

git commit -m "some message" -S

І ви можете показати ці підписи у виведенні git logз --show-signatureопцією:

$ 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 <lars@seas.harvard.edu>"
Author: Lars Kellogg-Stedman <lars@seas.harvard.edu>
Date:   Fri Jun 28 14:28:41 2013 -0400

    this is a test

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

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

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

Див. Коміт e18443e , коміт aeff29d , коміт ca194d5 , коміт 434060e , коміт 8e98e5f , коміт a4cc18f , коміт d66aeff (21 червня 2015 р.) Брайан М. Карлсон ( bk2204) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 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спільного verify-tagресурсу.

git 2.9 (червень 2016) оновіть документ git merge :

Див. Коміт 05a5869 (13 травня 2016 р.) Келлера Фукса (``) .
Допоміг: Хуніо С Хамано ( gitster) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комісії be6ec17 , 17 травня 2016 р.)}

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

Переконайтеся, що коміт підказки бічної гілки, що об’єднується, підписаний дійсним ключем, тобто ключем, що має дійсний ідентифікатор користувача: у типовій моделі довіри це означає, що ключ підписання підписаний надійним ключем.
Якщо коміт підказки бічної гілки не підписаний дійсним ключем, злиття переривається .

Оновити Git 2.10 (Q3 2016)

Див. Коміт b624a3e (16 серпня 2016 р.) Лінуса Торвальдса ( torvalds) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 83d9eb0 , 19 серпня 2016)}

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

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

Оригінал Linus був перебазований, щоб застосувати його до треку обслуговування на випадок, якщо застряглі в минулому двійкові розподільники захочуть перенести його до своєї попередньої кодової бази.

Git 2.11+ (Q4 2016) буде навіть точнішим.

Див. Коміт 661a180 (12 жовтня 2016 р.) Майкла Дж. Грубера ( mjg) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 56d268b , 26 жовтня 2016 р.)}

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

Відповідно до gpg2doc/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 у " --format=<placeholders>" вихідному форматі .

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

Додавання --formatдо git tag -vвимкнення звуку за замовчуванням результату перевірки GPG і замість цього друкує відформатований об’єкт тегу.
Це дозволяє абонентам перехресно перевіряти ім'я тегу з посилань / тегів з ім'ям тегу із заголовка об'єкта тегу під час перевірки GPG.

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

Див. Коміт 7f8ca20 , коміт ca779e8 (10 грудня 2017 р.) Ганс Джеррі Іллікайнен (``) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 0433d53 , 28 грудня 2017)}

merge: додати опцію конфігурації для verifySignatures

git merge --verify-signatures може використовуватися для перевірки того, що коміт наконечника гілки, що об’єднується, підписаний належним чином, але громіздко потрібно кожен раз це вказувати.

Додайте параметр конфігурації, який включає цю поведінку за замовчуванням, який можна замінити --no-verify-signatures.

Сторінка git mergeконфігурації тепер читає:

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 із CMS через " gpgsm" замість " openpgpчерез" " gnupg".

Див. Коміт 4e5dc9c (09 серпня 2018 р.) Хуніо С Хамано ( gitster) .
Допоміг: Войтех Мислівець ( VojtechMyslivec) , Брайан М. Карлсон ( bk2204) та Джефф Кінг ( peff) .
^{(Об’єднано Junio ​​C Hamano - gitster- у коміті 4d34122 , 20 серпня 2018)}

gpg-interface: розповсюдження статусу виходу із gpgзворотного зв'язку до абонентів

Коли уніфікована підтримка API gpg-інтерфейсу для кодових шляхів перевірки підписів для підписаних тегів та підписаних комітів у середині 2015 року, близько v2.6.0-rc0 ~ 114, ми випадково послабили перевірку підписів GPG.

До цієї зміни підписані коміти перевірялися шляхом пошуку " G" підпису ood від GPG, ігноруючи статус виходу " gpg --verify" процесу, тоді як підписані теги перевірялися простим передаванням статусу виходу "gpg --verify"".

Уніфікований код, який ми маємо, ігнорує статус виходу " gpg --verify" і повертає успішну перевірку, коли підпис відповідає неіснуючому ключу, незалежно від довіри, покладеної на ключ (тобто на додаток до " G" інших, ми приймаємо " U" недовірені).

Зробіть ці команди сигналом про збій із їх статусом виходу, коли " gpg --verify" (або спеціальна команда, вказана gpg.programзмінною конфігурації " ").
Це по суті змінює їхню поведінку назад, несумісним способом, щоб відхилити підписи, зроблені за допомогою ненадійних ключів, навіть якщо вони "" перевіряють правильно, оскільки саме так gpg --verifyповодиться " ".

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

Ми могли б виключити Uпідтримку з " " недовіри з цього резервного коду, але це мало б зробити дві несумісні зміни в одному коміті, тому давайте уникати цього поки.
Подальша зміна може зробити це за бажанням.

ключ потрібно довіряти / підписувати перед будь-яким шифруванням

Що стосується довіри, є прогрес:
з Git 2.26 (Q1 2020) gpg.minTrustLevelбула введена змінна конфігурації, яка повідомляє різним кодовим шляхам перевірки підпису необхідний мінімальний рівень довіри.

Див. Коміт 54887b4 (27 грудня 2019 р.) Ганса Джеррі Іллікайнена ( illikainen) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 11ad30b , 30 січня 2020)}

gpg-interface: додайте minTrustLevel як варіант конфігурації

^{Підписав: Ганс Джеррі Іллікайнен}

Раніше перевірка підпису для злиття і висувних операцій перевіряється , якщо ключ був трастовим-рівень або TRUST_NEVERабо TRUST_UNDEFINEDв verify_merge_signature().

Якщо це було так, процес die()'d.

Інші шляхи коду, які здійснювали перевірку підпису, повністю покладались на код повернення від check_commit_signature().

І підписи, зроблені хорошим ключем, незалежно від рівня його довіри, вважалися дійсними check_commit_signature().

Ця різниця в поведінці може змусити користувачів помилково припустити, що рівень довіри ключа в їхньому ключнику завжди враховується Git, навіть для операцій, де цього немає (наприклад, під час verify-commitабо verify-tag) .

Це працювало шляхом gpg-interface.cзбереження результату від статусу ключа / підпису та найнижчого з двох рівнів довіри в resultелементі signature_checkструктури (останній з цих рядків стану, який було виявлено, було записано result).

Вони задокументовані в GPG відповідно до підрозділу General status codesта Key related, відповідно.

Документація GPG говорить про наступне щодо TRUST_ statusкодів :

---

Це кілька подібних кодів стану:

- TRUST_UNDEFINED <error_token>
- TRUST_NEVER     <error_token>
- TRUST_MARGINAL  [0  [<validation_model>]]
- TRUST_FULLY     [0  [<validation_model>]]
- TRUST_ULTIMATE  [0  [<validation_model>]]

Для хороших підписів виділяється один із цих рядків стану, що вказує на дійсність ключа, що використовується для створення підпису.
Значення маркерів помилок наразі видає лише gpgsm.

---

Я тлумачу, що рівень довіри концептуально відрізняється від дійсності ключа та / або підпису.

Здається, це також було припущенням старого коду, check_signature()коли результат " G'(як у GOODSIG) та" U"(як у TRUST_NEVERабо TRUST_UNDEFINED)обох вважався успіхом.

Ці два випадки , коли в результаті « U» мали особливе значення було в verify_merge_signature()(де це призвело gitдо die()) і format_commit_one()(там , де це вплинуло на вихід %G?специфікатор формату).

Я вважаю, що має сенс переробляти обробку TRUST_ statusрядків таким чином, щоб користувачі могли налаштувати мінімальний рівень довіри, який застосовується у всьому світі, замість того, щоб окремі частини git(наприклад, злиття) виконували це самостійно (за винятком пільгового періоду зі зворотною сумісністю).

Я також вважаю, що має сенс не зберігати рівень довіри в тому ж елементі структури, що і статус ключа / підпису.

Хоча наявність TRUST_ statusкоду означає, що підпис хороший (див. Перший абзац у включеному фрагменті вище), наскільки я можу зрозуміти, порядок рядків стану з GPG не є чітко визначеним; таким чином, здавалося б правдоподібним, що рівень довіри міг бути перезаписаний зі статусом ключ / підпис, якби вони зберігалися в одному і тому ж члені signature_checkструктури.

Цей патч вводить нову опцію конфігурації: gpg.minTrustLevel.

Він консолідує перевірку на рівні довіри gpg-interface.cта додає нового trust_levelчлена до signature_checkструктури.

Зворотна сумісність підтримується шляхом введення особливого випадку, verify_merge_signature()таким чином, що якщо не налаштовано користувачем налаштовується gpg.minTrustLevel, то стара поведінка відхилення TRUST_UNDEFINEDта TRUST_NEVERзастосовується.

Якщо, з іншого боку, gpg.minTrustLevelвстановлено, то це значення замінює стару поведінку.

Аналогічно, %G?специфікатор формату буде продовжувати показувати 'U ' для підписів, зроблених за допомогою ключа, який має рівень довіри TRUST_UNDEFINEDабо TRUST_NEVER,навіть якщо Uсимвол ' ' більше не існує в resultелементі signature_checkструктури.

Новий специфікатор формату, %GTтакож вводиться для користувачів, які хочуть показати всі можливі рівні довіри до підпису.

Іншим підходом було б просто відмовитись від вимоги до рівня довіри verify_merge_signature().

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

Однак, вимагаючи мінімального рівня довіри для підписання ключів, схоже, існує реальний випадок використання.

Наприклад, система збірки, що використовується проектом Qubes OS, в даний час аналізує вихідний результат із тегу verify, щоб затвердити мінімальний рівень довіри для ключів, що використовуються для підписання тегів git .

git config gpgСторінка людини тепер включає в себе:

gpg.minTrustLevel:

Визначає мінімальний рівень довіри для перевірки підпису.
Якщо цей параметр не встановлено, то для перевірки підпису для операцій злиття потрібен ключ, що має принаймні marginalдовіру.
Для інших операцій, які виконують перевірку підпису, потрібен ключ, що має принаймні undefinedдовіру.
Встановлення цього параметра замінює необхідний рівень довіри для всіх операцій. Підтримувані значення в порядку зростання значущості:

• undefined
• never
• marginal
• fully
• ultimate

З Git 2.26 (Q1 2020) , " git show" та інші надали ім'я об'єкта в необробленому форматі у своєму виведенні помилки, яке було виправлено, додавши його у шістнадцятковій формі.

show_one_mergetag: надрукувати не-батьківський файл у шістнадцятковій формі.

Коли тег злиття називає не-батьківського, що може статися після неглибокого клонування, його хеш раніше друкувався як вихідні дані.
Натомість надрукуйте його у шістнадцятковій формі.

Перевірено за git -C shallow log --graph --show-signature -n1 plain-shallowпісляgit clone --depth 1 --no-local . shallow

З Git 2.27 (Q2 2020), код інтерфейсу з GnuPG був змінений.

Див. Коміт 6794898 , коміт f1e3df3 (04 березня 2020 р.) Ганса Джеррі Іллікайнена ( illikainen) .
^{(Об’єднано Хуніо С Хамано - gitster- у комітеті fa82be9 , 27 березня 2020 р.)}

gpg-interface: віддайте перевагу check_signature()для перевірки GPG

^{Підписав: Ганс Джеррі Іллікайнен}

Цей коміт рефакторує використання за verify_signed_buffer()межами gpg-interface.cдля використання check_signature()замість цього.

Вона також перетворюється verify_signed_buffer()на локально-файлову функцію, оскільки тепер вона викликається лише внутрішнім користувачемcheck_signature() .

Раніше існували дві глобально визначені функції, що використовуються в різних частинах Git для здійснення перевірки підписів GPG: verify_signed_buffer()і check_signature().

Зараз check_signature()використовується лише .

verify_signed_buffer()Функція не захистить від дублюючих підписів , як описано Міхал Гірському .

Натомість він забезпечує лише помилковий код виходу з GPG та наявність принаймні одного GOODSIGполя стану.

Це контрастує з тим, check_signature()що повертає помилку, якщо зустрічається більше одного підпису.

Нижчий ступінь перевірки робить verify_signed_buffer()проблематичним використання, якщо абоненти не розбирають і не перевіряють різні частини повідомлення про стан GPG самі.

І обробка цих повідомлень здається завданням, на яке слід зарезервувати gpg-interface.cфункцію check_signature().

Крім того, використання програми verify_signed_buffer()ускладнює впровадження нової функціональності, яка покладається на вміст рядків стану GPG.

Тепер усі операції, які виконують перевірку підпису, мають єдину точку входу gpg-interface.c.

Це полегшує розповсюдження змінених або додаткових функціональних можливостей у перевірці підписів GPG у всіх частинах Git, не маючи непарних регістрів, які не виконують однаковий ступінь перевірки .

Побіжна перевірка кодексу говорить про те, що такого прямого методу не існує.

Усі тести у джерелі git покладаються на grepпінг вихідних даних git show(див. Тести t / t7510-signed-commit.sh ).

Ви можете налаштувати результати, використовуючи щось на зразок того, --pretty "%H %G?%"щоб полегшити синтаксичний аналіз.

Здається, ви можете попросити git mergeперевірити підпис, але знову ж таки, його тести покладаються grep(див. T / t7612-merge-verify-signatures.sh ). Здається, недійсний підпис призведе git mergeдо виходу з поганим підписом, тому ви могли б сьогодні обійти це, зробивши десь тестове злиття та викинувши це злиття, але це здається гіршим, ніж просто викликати grep.