Signer un commit Git

Je continue de tester les différentes possibilités offertes par l’utilisation d’un jeu de clés gpg, cette fois dans le domaine de la gestion de code avec git. L’idée consiste à signer ses commits git afin de garantir l’identité de la personne ayant réalisée les modifications.

Première étape, récupérer l’identifiant de sa clé PGP:

gpg --list-secret-keys --keyid-format LONG

Une fois en possession de l’identifiant, on met à jour la configuration git.

git config --global user.signingkey <ID-cle>

Ce qui se traduit par l’ajout suivant dans le fichier de configuration.

[user]
signingkey = 069DXXXXXX4A5F7A

Il est ensuite nécessaire d’ajouter le résultat de la commande suivante au niveau de son serveur git. Dans le cas de Github, la configuration s’effectue sur la même page que la page de configuration des clés SSH.

gpg --armor --export <ID-cle>

Passons à la signature à proprement parler. Pour signer un tag, on utilisera l’option -s.

git tag -s v1.5 -m 'my signed 1.5 tag'

Pour signer un commit, on utilisera cette fois l’option -S.

git commit -S -m 'signed commit'

Enfin, pour éviter d’avoir à ajouter en permanence l’option -s ou -S, on pourra configurer git pour toujours signer les tags et les commits.

git config --global commit.gpgsign true
git config --global tag.gpgsign true

Étant donné qu’il est possible pour n’importe quel utilisateur de réécrire l’historique d’un dépôt git et de modifier au passage les informations de l’auteur du commit, ou plus simplement, de modifier l’auteur le temps du commit, la signature des opérations git permet de s’assurer de l’identité de la personne ayant effectué l’opération et de se prémunir contre une éventuelle tentative d’usurpation d’identité (à condition que la clé ne soit pas compromise).

Modification des informations d’auteur d’un commit

Après avoir récupéré l’ensemble de mes dépôts git avec repo, je souhaitais effectuer un peu de « nettoyage » dans mes informations d’auteur de commit afin de les harmoniser. Bien entendu, cette opération n’est pas du tout neutre puisqu’elle implique une réécriture de l’historique, et dans le cas d’un changement d’email, cela concerne chaque SHA-1 des commits de l’historique (car un commit contient le SHA-1 de son parent).

Intéressons-nous à la commande de changement des informations d’auteur à proprement parler. Celle-ci est extraite de la documentation de github (si besoin, en cas d’opération successive, ajouter l’option -f avant –env-filter):

$ git filter-branch --env-filter '

OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

Avant d’être en mesure de réécrire les commits, on commence par déterminer les informations existantes à l’aide de la commande suivante (que l’on pourra par ailleurs exécuter sur tous les dépôts avec repo forall -c <commande>) :

git log | grep Author: | sort | uniq

Une fois les changements terminés, on pousse ces derniers vers le serveur:

git push --force --tags origin 'refs/heads/*'

En cas de message du type :

erreur fatale: 'origin' does not appear to be a git repository

Il convient de vérifier le remote configuré avec git remote -v, soit dans mon cas :

github  ssh://git@github.com/vvision/eslint-config (fetch)
github ssh://git@github.com/vvision/eslint-config (push)

On remplace alors origin par github dans la commande git push et le tour est joué (configuration héritée de repo).

De cette manière, l’ensemble de mes dépôts dispose désormais des informations de contact nettoyées.

Gestion des dépôts git

Au fil des années, j’ai accumulé pas loin de 70 dépôts git, certains presque vides, d’autres contenant des instructions de déploiement de service, ou encore, mes divers essais successifs pour me familiariser avec l’une ou l’autre technologie. Lors de la panne récente de mon serveur auto-hébergé, j’ai craint un moment d’avoir perdu une partie du code produit ces dernières années. Heureusement, cela ne fut pas le cas.

Bien sûr, une partie des dépôts est toujours présente dans un coin de mon disque dur, bien que n’ayant pas été l’objet de modification récente, et m’assure ainsi une sauvegarde locale de ces derniers: une n-ième duplication. Continuant le chemin du côté de ma résilience numérique, je me suis donc intéressé au moyen de conserver facilement l’ensemble de mes dépôts git en local. Pour arriver un résultat satisfaisant, je me suis donc tourné vers repo, programme écrit par Google pour gérer les dépôts Android et que j’avais eu l’occasion de découvrir durant mes études d’ingénieur.

J’ai donc ajouté un nouveau dépôt à ma liste, contenant un readme et un fichier default.xml. Le fichier default.xml suit les règles de syntaxe des fichiers manifest de repo et liste désormais l’ensemble de mes dépôts git. En voici une version simplifiée :

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="github" fetch="ssh://git@github.com/vvision" />
<default revision="master" remote="github" sync-j="4" />

<project name="eslint-config" />
<project name="manifest" path="manifest/manifest" />
<project name="prettier-config"/>
</manifest>

Quelques commentaires. Je commence par définir un remote, endroit où récupérer mes dépôts, lui donne un nom et précise l’url utilisée pour la récupération d’un dépôt. Je définis ensuite les paramètres par défaut en précisant ici que je souhaite récupérer la branche master, en utilisant la configuration du remote nommée github et en autorisant 4 jobs concurrents pour les opérations de synchronisation. Reste ensuite à définir les dépôts à récupérer, le paramètre minimum étant le nom du dépôt sur le serveur distant. À noter également la présence du paramètre path qui permet de choisir l’emplacement final du contenu du dépôt, ce qui se révèle d’une grande utilité pour grouper ses dépôts dans différents répertoires.

Une fois le fichier manifest complété et pousser dans son dépôt distant, on peut commencer la récupération de la liste de dépôts en utilisant successivement les commandes :

repo init -u git@github.com:vvision/manifest.git

Puis :

repo sync

À l’issue de l’exécution de cette deuxième commande, on dispose désormais de l’ensemble des dépôts définis dans le manifest sur le disque local et cela de manière totalement automatique. On notera en particulier la présence de l’instruction status permettant d’avoir un aperçu de l’état des dépôts et l’instruction forall permettant d’exécuter une commande sur l’ensemble des dépôts.

Sources :

[git] Retenir temporairement les infos d’authentification

Une configuration que je trouve plutôt utile, lorsque je modifie un dépôt git sur une machine où je ne souhaite pas mettre en place de clé ssh. A partir de la version 1.7.9 de janvier 2012 de Git, il est donc possible de demander la mise en cache des informations d’authentification (login, mot de passe), afin de ne pas avoir à les ressaisir en permanence.

La configuration s’effectue via la commande suivante, qui aura pour effet de conserver les infos en cache pour une durée de 15 minutes :

git config --global credential.helper cache

Si on désire augmenter la durée de cache, à une heure par exemple, on ajoute le paramètre timeout :

git config --global credential.helper "cache --timeout=3600"

Source: git-crendential-cache

Cmd #6 [Git]

Quelques commandes Git bien utiles.

 

git log -p

Permet de voir le diff introduit par chaque commit.

 

git log --name-status

Voir la liste des fichiers affectés par chaque commit avec le type de modification: ajout, modification, suppression.

 

git log --stat

Donne des infos concernant les fichiers modifiés (ex: …/src/test/resources/log4j.properties | 3 +-).

 

git stash save

Sauvegarde les modifications locales et remet le dépôt dans l’état correspondant à votre HEAD.

 

git stash pop

Applique les modifications précédemment sauvegardées.

 

Source: