Existe-t-il un moyen de «signer automatiquement» dans Git avec une clé GPG?

Existe-t-il un moyen simple de faire en sorte que Git signe toujours chaque commit ou tag créé?

Je l'ai essayé avec quelque chose comme:

alias commit = commit -S

Mais cela n'a pas fait l'affaire.

Je ne veux pas installer un programme différent pour y arriver. Est-ce faisable facilement?

Juste une question secondaire, peut-être que les commits ne devraient pas être signés, seulement les balises, que je ne crée jamais, car je soumets des commits uniques pour un projet comme Homebrew, etc.

Remarque: si vous ne voulez pas ajouter -Stout le temps pour vous assurer que vos commits sont signés, il y a une proposition (branche ' pu' pour l'instant, décembre 2013, donc aucune garantie que cela se produira dans une version git) pour ajouter un config qui s'occupera de cette option pour vous.
Mise à jour de mai 2014: elle est dans Git 2.0 (après avoir été renvoyée dans cette série de patchs )

Voir commit 2af2ef3 de Nicolas Vigier (boklm) :

Ajouter l' commit.gpgsignoption de signer tous les commits

Si vous souhaitez signer GPG tous vos commits, vous devez ajouter l' -Soption en tout temps.
L' commit.gpgsignoption config permet de signer automatiquement toutes les validations.

commit.gpgsign

Un booléen pour spécifier si toutes les validations doivent être signées GPG.
L'utilisation de cette option lors de l'exécution d'opérations telles que le rebasage peut entraîner la signature d'un grand nombre de validations. Il peut être pratique d'utiliser un agent pour éviter de taper plusieurs fois votre phrase de passe GPG.

Cette configuration est généralement définie par dépôt (vous n'avez pas besoin de signer votre dépôt expérimental local privé):

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

Vous devez combiner cela avec user.signingKeyutilisé comme paramètre global (clé unique utilisée pour tous les dépôts où vous souhaitez signer la validation)

git config --global user.signingkey F2C7AB29

user.signingKeya été introduit dans git 1.5.0 (janvier 2007) avec la validation d67778e :

Il ne devrait pas être obligatoire d'utiliser la même forme que mon nom dans mon référentiel git et ma clé gpg.
De plus, je pourrais avoir plusieurs clés dans mon trousseau de clés, et je pourrais vouloir en utiliser une qui ne correspond pas à l'adresse que j'utilise dans les messages de validation.

Ce correctif ajoute une entrée de configuration " user.signingKey" qui, si elle est présente, sera transmise au commutateur "-u" pour gpg, permettant à la clé de signature de balise d'être remplacée.

Ceci est appliqué avec commit aba9119 (git 1.5.3.2) afin d'attraper le cas où Si l'utilisateur s'est mal configuré user.signingKeydans son .git/configou n'a simplement aucune clé secrète sur son trousseau de clés.

Remarques:

• Par convention, depuis git 2.4.0 mars 2015 , ce n'est signingKeypas le cassigningkey , même si les git configclés sont insensibles à la casse. Cela n'aurait d'importance que si vous le faites git config --get-regexp, ce qui est sensible à la casse, sinon, ce n'est qu'une convention de lisibilité;
• Si vous voulez que le serveur git vérifie la signature pour chaque push , vous aurez besoin d'au moins git 2.2+ (octobre 2014) ( commit b945901 ), car il git push --signedn'a pas pris en compte la user.signingKeyvaleur de configuration;
• git 2.9 (juin 2016) utilisera user.signingKeypour forcer la signature des balises annotées ainsi que les commits: commit 61c2fe0 .

git config --global user.signingKey 9E08524833CB3038FDE385C54C0AFCCFED5CDE14
git config --global commit.gpgSign true

Remplacez 9E08524833CB3038FDE385C54C0AFCCFED5CDE14 par votre ID de clé. N'oubliez pas: ce n'est jamais une bonne idée d'utiliser l'ID court .

MISE À JOUR: Selon un nouvel édit git , toutes les clés de configuration doivent être dans camelCase.

Edit: Depuis Git version 1.7.9, il est possible de signer Git commits ( git commit -S). Mise à jour de la réponse légèrement pour refléter cela.

Le titre de la question est:

Existe-t-il un moyen de «signer automatiquement» dans Git avec une clé GPG?

Réponse courte: oui, mais ne le faites pas.

Résolution de la faute de frappe dans la question: git commit -sne signe pas le commit. Au lieu de cela, à partir de la man git-commitpage:

-s, --signoff
Ajouter une ligne signée par le committer à la fin du message du journal de validation.

Cela donne une sortie de journal similaire à la suivante:

± $ 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 

Notez le bit "signé par: ..."; qui a été généré par le -sdrapeau sur le git-commit.

Citant l' e - mail d'annonce de sortie :

• "git commit" a appris "-S" pour signer GPG le commit; cela peut être montré avec l'option "--show-signature" dans "git log".

Alors oui, vous pouvez signer des commits. Cependant, je recommande personnellement la prudence avec cette option; la signature automatique des validations est inutile, voir ci-dessous:

Juste une question secondaire, peut-être que les commits ne devraient pas être signés, seulement les balises, que je ne crée jamais, lorsque je soumets des commits uniques.

C'est correct. Les commits ne sont pas signés; les balises sont. La raison de cela peut être trouvée dans ce message de Linus Torvalds , dont le dernier paragraphe dit:

Signer chaque commit est totalement stupide. Cela signifie simplement que vous l'automatisez et que vous faites que la signature vaut moins. Cela n'ajoute pas non plus de valeur réelle, car la façon dont fonctionne la chaîne DAG git du SHA1, vous n'avez besoin que d' une seule signature pour que tous les commits accessibles à partir de celle-ci soient effectivement couverts par celle-ci. Donc, la signature de chaque commit manque tout simplement le point.

Je vous encourage à parcourir le message lié, ce qui explique pourquoi la signature automatique des validations n'est pas une meilleure idée que je ne pourrais le faire.

Cependant , si vous souhaitez signer automatiquement une balise , vous pourrez le faire en enveloppant le git-tag -[s|u]dans un alias; si vous voulez le faire, vous souhaiterez probablement configurer votre identifiant de clé dans ~/.gitconfigou le .git/configfichier spécifique au projet . Plus d'informations sur ce processus peuvent être consultées dans le livre de la communauté git . La signature des balises est infiniment plus utile que la signature de chaque validation que vous faites.

Pour que la signature automatique fonctionne avant la version 2.0 de git, vous devrez ajouter un alias git pour la validation.

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

Vous devez indiquer clairement que si vous signez un commit ou un tag, cela ne signifie pas que vous approuvez tout l'historique. En cas de commit, vous ne signez que le changement à portée de main, et en cas de tag, eh bien .. vous devez définir ce que vous voulez dire avec. Vous avez peut-être tiré un changement qui prétend qu'il vient de vous mais ne l'a pas été (parce que quelqu'un d'autre l'a poussé sur votre télécommande). Ou c'est un changement auquel vous ne voulez pas participer, mais vous venez de signer la balise.

Dans les projets OSS typiques, cela peut être moins courant, mais dans un scénario d'entreprise où vous ne touchez que de temps en temps au code et que vous ne lisez pas tout l'historique, cela peut passer inaperçu.

La signature des commits est un problème s'ils sont rebasés ou sélectionnés par d'autres parents. Mais ce serait bien si un commit modifié pouvait pointer vers le commit "original" qui vérifie réellement.