Вопрос по git – Есть ли способ «автоматически подписать» коммиты в Git с помощью ключа GPG?

180

Есть ли простой способ заставить Git всегда подписывать каждый созданный коммит или тэг?

Я попробовал это с чем-то вроде:

alias commit = commit -S

Но это не помогло.

Я не хочу устанавливать другую программу, чтобы это произошло. Это выполнимо с легкостью?

Просто дополнительный вопрос, возможно, коммиты не должны быть подписаны, только теги, которые я никогда не создаю, так как я отправляю отдельные коммиты для проекта, такого как Homebrew и т. Д.

Просто для информации: переписать все коммиты, которые нужно нажать, чтобы подписать их:git filter-branch -f --commit-filter 'git commit-tree -S "[email protected]"' [email protected]{u}..HEAD (Я не имею в виду, что вы должны использовать это). Vi.
Причина, по которой ваш псевдоним сработал, заключается в том, что вы не можете использовать псевдоним для уже существующей команды. (Связанный: Stackoverflow.com / вопросы / 5875275 / мерзавец фиксации V-по-умолчанию / Stackoverflow.com вопросы / 2500586 / ... / Stackoverflow.com вопросы / 1278296 / ...) Dan D.

Ваш Ответ

5   ответов
230

-S все время, чтобы убедиться, что ваши коммиты подписаны, есть предложение (ветка 'pu 'на данный момент, декабрь 2013, так что нет никакой гарантии, что он попадет в git-релиз), чтобы добавить конфигурацию, которая позаботится об этой опции для вас.
Обновление мая 2014: он есть в Git 2.0 (после того, как повторно в этой серии патчей)

Видетьcommit 2af2ef3 по Николас Вигье (боклм):

Добавитьcommit.gpgsign возможность подписать все коммиты

Если вы хотите, чтобы GPG подписал все ваши коммиты, вы должны добавить-S вариант все время.
Thecommit.gpgsignараметр @ config позволяет автоматически подписывать все коммиты.

commit.gpgsign

Логическое значение, указывающее, должны ли подписываться все коммиты.
Использование этой опции при выполнении таких операций, как rebase, может привести к подписанию большого количества коммитов. Может быть удобно использовать агент, чтобы не вводить парольную фразу GPG несколько раз.

Конфигурация обычно устанавливается для репо (вам не нужно подписывать свои частные экспериментальные локальные репо):

cd /path/to/repo/needing/gpg/signature
git config commit.gpgsign true

Ты бы сочетал это сuser.signingKey используется как глобальная настройка (уникальный ключ используется для всех репо, где вы хотите подписать коммит)

git config --global user.signingkey F2C7AB29

user.signingKey был представлен в git 1.5.0 (январь 2007 г.) сcommit d67778e:

Не должно быть требования, чтобы я использовал ту же форму моего имени в моем git-хранилище и мой ключ gpg.
Кроме того, у меня может быть несколько ключей в моей связке ключей, и я могу захотеть использовать тот, который не совпадает с адресом, который я использую в сообщениях фиксации.

Этот патч добавляет запись конфигурации "user.signingKey ", который, если он присутствует, будет передан переключателю" -u "для gpg, позволяя переопределить ключ подписи тега.

Это обеспечивается с помощьюcommit aba9119 (git 1.5.3.2), чтобы поймать случай, когда пользователь неправильно настроилuser.signingKey в их.git/config или просто не имеет секретных ключей на своей связке ключей.

Заметки

Условно, с git 2.4.0 март 2015, этоsigningKey, неsigningkey, хотяgit config ключи не чувствительны к регистру. Это будет иметь значение, только если вы делаетеgit config --get-regexp, которыйявляетс чувствителен к регистру, иначе это только соглашение о читаемости; Если ты хочешьервер @git для проверки подписи для каждого push, вам нужен Git 2.2+ (октябрь 2014) как минимум commit b945901), какgit push --signed не смог рассмотретьuser.signingKey config value;git 2.9 (июнь 2016) будет использоватьuser.signingKey чтобы подписать аннотацию Теги а также коммиты:commit 61c2fe0.
Это действительно круто. Есть ли простой способ на github сделать что-то вроде git description без необходимости загрузки репо? user1115652
Тебе не нужно подписывать свои частные экспериментальные репозитории ... но почему бы и нет? Andy Hayden
137
git config --global user.signingKey 9E08524833CB3038FDE385C54C0AFCCFED5CDE14
git config --global commit.gpgSign true

ключа. Помнить: Никогда не стоит использовать короткий идентификатор.

ОБНОВИТЬ За новый Git Edict, все ключи конфигурации должны быть в camelCase.

Ты просто скопировал и вставил это из VonC ответ? Robbie Averill
No. Как вы можете видеть в истории издания, кто-то добавил мой пример в свой ответ. ED5CDE14 - мой личный ключ. Без проблем Felipe
Это может помочь пользователям Linux: чтобы заставить его работать в некоторых случаях (например, в Vim, используя ключ, хранящийся на смарт-карте, требующей ввода PIN-кода), мне пришлось отредактировать~/.gnupg/gpg-agent.conf и добавитьpinentry-program /usr/bin/pinentry-,gtk-2 (следуя этому руководству Wiki.archlinux.org / index.php / GnuPG # pinentry ) iakovos Gurulian
Как ты находишь свой ключ для подписи? также, плохо ли иметь только 1 GPG-ключ для всех моих репозиториев git? потому что я бы предпочел не иметь дело с 4-мя дифференциальными клавишами в довольно связанных проектах. MarcusJ
Bizarre. Завтра я верну изменения, поскольку они выглядят плохо для ва Robbie Averill
47

Этоявляетс возможны подписать коммиты Git git commit -S). Немного обновив ответ, чтобы отразить это.

Заголовок вопроса:

Есть ли способ «автоматически подписать» коммиты в Git с помощью ключа GPG?

Короткий ответ: да, но не делай этого.

Обращаясь к опечатке в вопросе:git commit -s не подписывает коммит. Скорее отman git-commit страница:

-s, --signoff
Добавлена подпись коммиттера в конце сообщения журнала фиксации.

Это дает вывод журнала, подобный следующему:


± $ git log                                                                                 [0:43:31]
commit 155deeaef1896c63519320c7cbaf4691355143f5
Author: User Name 
Date:   Mon Apr 16 00:43:27 2012 +0200

    Added .gitignore

    Signed-off-by: User Name 

Отметьте бит "Подписано: ..."; который был сгенерирован-s флаг наgit-commit.

Цитируя электронная поч:

"git commit" научился "-S" для GPG-подписать коммит; это можно показать с помощью опции "--show-signature" для "git log".

Так что да, вы можете подписывать коммиты. Однако я лично призываю к осторожности с этим вариантом;автоматическ подписывать коммиты почти бессмысленно, смотрите ниже:

Просто дополнительный вопрос, возможно, коммиты не должны подписываться, только теги, которые я никогда не создаю, так как я отправляю отдельные коммиты.

Правильно. Комитеты не подписаны; теги есть. Причину этого можно найти в этом сообщении по Линус Торвальдс, последний абзац которого гласит:

Подписывать каждый коммит совершенно глупо. Это просто означает, что вы автоматизируете это, и вы делаете подпись на сумму меньше. Это также не добавляет никакой реальной ценности, так как, как работает git DAG-цепочка SHA1, вам нужно толькооди подпись, чтобы все коммиты, доступные от этого, были эффективно покрыты этим. Так что подписание каждого коммита просто упускает смысл.

Я бы рекомендовал просмотреть связанное сообщение, в котором разъясняетсяЗаче автоматическое подписание коммитов - не самая лучшая идея, чем я.

Тем не мени, если вы хотите автоматически подписатьте, вы могли бы сделать это, обернувgit-tag -[s|u] в псевдониме; если вы собираетесь это сделать, вы, вероятно, захотите установить свой идентификатор ключа в~/.gitconfig или для конкретного проекта.git/config файл. Более подробную информацию об этом процессе можно увидеть в Git Community Book. Подписание тегов гораздо полезнее, чем подписание каждого коммита, который вы делаете.

Подписание одного коммита достаточно, если код никогда не меняется. Как только вы добавите больше коммитов, вам понадобится больше подписей. Подпись тега означает все, что старше, чем этот коммит. Если вам нужна детальная проверка по мере поступления коммитов, имеет смысл подписать каждый коммит. В противном случае вам придется использовать множество тегов, которые просто загромождают репо. На аутентифицированных удаленных репозиториях git вы должны давать свой пароль или ключ ssh каждый раз, когда вы нажимаете коммит, а не только когда вы нажимаете теги. Это похожая ситуация. Hans-Christoph Steiner
0.стать, 1. «достаточно подписать их все» -> Как сказать «я утверждаю, чтоэт действительно Мой diff (но не уверен насчет любых предыдущих и последующих коммитов). Я хочу поставить подпись на Мой commit, не утверждая ничего о коммитах, которые я извлек с центрального сервера / что угодно. 2. В ненадежной среде все еще должен быть надежный инструмент, чтобы узнать, кто виноват. Если сервер проверяет, что все коммиты подписаны с помощью ключа электронной почты коммиттера, сложно подделать коммит (если вы хорошо защитите свой компьютер). Vi.
Я чувствую, что Линус упускает суть. Похоже, он имеет в виду совершенно другой вариант использования подписанных коммитов, чем OP в этом потоке. (Проверка целостности всего проекта, против проверки авторства одного коммита.) Ajedi32
"Подписывать каждый коммит совершенно глупо." -> Какой лучший способ обезопасить коммиты, когда есть «крысиный» разработчик, которому нравится выдвигать коммиты с фальшивым автором и коммиттером? Если на сервере нет какой-то магии хука, он может направитьgit blame тому, кто захочет. Vi.
Этот ответ все еще устарел и противоречив - например, биты в конце, которые утверждают, что «коммиты не подписаны; теги есть.» Adam Spiers
0

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

В типичных проектах OSS это может быть не так часто, но в сценарии предприятия, когда вы время от времени касаетесь кода и не читаете всю историю, он может остаться незамеченным.

Подписание коммитов является проблемой, если они будут перебазированы или отобраны для других родителей. Но было бы хорошо, если бы измененный коммит мог указывать на «оригинальный» коммит, который фактически проверяе

@ Барри «Перебазирование - это как ложь. Его следует использовать крайне экономно »- это просто неправда. Рабочие процессы, основанные на ребазе, так же действительны, как и рабочие процессы, основанные на слиянии. Перебазировка слишком мощная, чтобы ее можно было экономно использовать. Luke
Когда вы используете это исключительно с GitHub, это не проблема, коммиты слияния не будут подписаны вами, так как GitHub не поддерживает это. Преимущество подписания каждого (не объединяющего) коммита в этой среде состоит в том, что становится очень очевидным, когда мошеннический коммит был добавлен через PR, поскольку он не будет подписан вашим ключом GPG. Arran Cudbard-Bell
«Опасно, если вы подпишете коммит или тэг (оба подпишут всю историю), что вы могли получить изменение, которое утверждает, что оно от вас» Если вы только подписываете коммит, хотя я бы не интерпретировал это как одобрение каждого коммита, достижимого от вас. Вы не обязательно заявляете, что эти прошлые изменения действительны или одобрены вами, только что вы создали коммит на основе этих изменений. (Хотя с тегом я согласен, что вы действительно подписываете все коммиты, доступные по тегу.) Ajedi32
Rebasing - это как ложь. Это должно использоваться чрезвычайно экономно. Другое дело, что фиксация с помощью подписи - это «отмена» кода, поэтому будьте уверены, что это а) не анти-CYA и б) не напрасные усилия. Barry
@ ArranCudbard-Bell Точно так же, как обновление, коммиты слияния подписываются вами, если вы установитеcommit.gpgsign верно, как подсказывает @ VonC Jay
5

вам нужно будет добавить псевдоним git для фиксации.

# git config --global alias.commit commit -S
[alias]
    commit = commit -S

Похожие вопросы