Archives du mot-clé Git

Signer ses commits Git et trans­fé­rer son gpg-agent sur un serveur distant

GPG, c’est bien. C’est encore ce qu’on a trouvé de mieux pour que tout un chacun puisse s’as­su­rer de l’au­then­ti­cité d’un message (non-modi­fi­ca­tion de celui-ci et que son auteur est bien celui annoncé) et chif­frer ses messages.

OK, c’est pas un exemple d’er­go­no­mie, OK, c’est pas ma mère qui va s’en servir sciem­ment tous les jours (sous le manteau, si, puisque les paquets de sa Debian sont signés avec GPG). Mais d’un autre côté, ma mère ne risque pas non plus (et je dirais même encore moins) de se payer un certi­fi­cat X509 pour signer ses mails. Ne parlons pas de mon père, à côté de lui, ma mère fait figure de hax0r.

Bon, d’ac­cord, c’est un bon gros truc de geek. OSEF, c’est cool quand même, c’était pour dire que c’était robuste et que tout le monde peut l’uti­li­ser sans bourse délier.

Que vous le sachiez (dans la colle) ou pas, on peut signer ses commits git avec GPG, histoire d’ajou­ter encore une couche de sécu­rité aux modi­fi­ca­tions qu’on apporte à un logi­ciel. Des forges comme Gitlab permettent d’ajou­ter une clé GPG à son profil permet­tant ainsi de véri­fier les signa­tures des commits d’un projet. Voyez sur ce commit le joli petit bouton « Veri­fied ».

Ceci n’est pas un cours sur GPG, on va donc consi­dé­rer que vous avez déjà une clé GPG.

Signer ses commits Git

Rien de plus simple. Il faut tout d’abord décla­rer à Git quelle clé doit être utili­sée pour signer ses commits (chan­gez l’em­preinte, ça c’est la mienne ) :

git config --global user.signingkey EA868E12D0257E3C

Main­te­nant, soit vous ajou­tez -S quand vous commit­tez :

git commit -S

Soit vous confi­gu­rez Git pour signer tous vos commits :

git config --global commit.gpgsign true

Voilà, c’est bon. Pour véri­fier un commit :

git verify-commit cce09ca

C’est bien beau, mais ça m’ar­rive de déve­lop­per direc­te­ment sur des serveurs, et surtout, je déve­loppe géné­ra­le­ment dans une machine virtuelle sur mon PC. Je ne vais certai­ne­ment pas aller copier ma clé privée sur les-dits serveurs ou dans la machine virtuelle ! C’est là qu’in­ter­vient le trans­fert du gpg-agent sur le serveur distant.

Ceci n’est toujours pas un cours sur GPG, on va donc consi­dé­rer que vous avez déjà un gpg-agent fonc­tion­nel sur votre ordi­na­teur.

Trans­fé­rer son gpg-agent sur un serveur distant

ATTENTION On ne trans­fère son agent gpg que sur une machine dans laquelle on a confiance, et dont on sait que les personnes y ayant accès ne s’amu­se­ront pas à utili­ser votre agent (rien de plus simple si on a un accès root à la machine). Cela vaut aussi pour l’agent ssh !

Premiè­re­ment, on va dire à l’agent de créer un socket supplé­men­taire en mettant dans ~/.gnupg/gpg-agent.conf (rempla­cez <user> par votre login) :

extra-socket /home/<user>/.gnupg/S.gpg-agent.extra

Ce socket a des restric­tions que n’a pas le socket habi­tuel (ne me deman­dez pas lesquelles) mais surtout, le logi­ciel qui vous deman­dera votre mot de passe (pinen­try de son petit nom géné­rique) vous présen­tera la demande de mot de passe diffé­rem­ment d’ha­bi­tude. Moi, il m’a dit en gros « Cette demande provient d’une machine distante », ce qui permet de repé­rer d’où vient la demande (déjà pas de votre machine pour déchif­frer un mail par exemple) et de réflé­chir à si c’est bien vous qui avez fait une action deman­dant la clé GPG.

On redé­marre l’agent pour prendre en compte la nouvelle confi­gu­ra­tion :

gpg-connect-agent /bye

Ensuite, il va falloir modi­fier sa confi­gu­ra­tion SSH. Comme un bon adminSys est fainéant, vous avez bien sûr utilisé concierge pour gérer votre fichier ~/.ssh/config. Il suffit d’ajou­ter dans le bloc de confi­gu­ra­tion du serveur souhaité la ligne (rempla­cez uid par votre uid (id pour le connaître) et <user> par votre login):

RemoteForward /run/user/<uid>/gnupg/S.gpg-agent /home/<user>/.gnupg/S.gpg-agent.extra

Enfin, il faut ajou­ter ceci dans le /etc/ssh/sshd_config du serveur distant (et redé­mar­rer son dæmon ssh après) :

StreamLocalBindUnlink yes

C’est fini ! Vous pouvez main­te­nant utili­ser votre clé GPG sur un serveur distant en vous y connec­tant en SSH, sans copier votre clé sur le serveur

Connec­tez-vous en SSH et testez avec

echo "test" | gpg2 --clearsign

Si, lorsque vous tentez de signer un commit sur votre serveur distant, cela échoue, assu­rez-vous que git utilise bien gpg2 :

git config --global gpg.program gpg2

Merci à Thomas Citha­rel pour avoir mis la signa­ture GPG des commits sur le tapis d’une discus­sion, ce qui m’a poussé à me pencher sur le trans­fert de l’agent GPG.

Crédit image d’en-tête de ce billet : logo de GnuPG, licence GPL, récu­péré sur Wiki­me­dia Commons

Me soutenir sur Tipeee Me soutenir sur Liberapay

Bye bye Redmine !

Jusque-là, j’avais un redmine qui me servait de forge logi­cielle person­nelle et je me méfiais de Github (j’ai du mal à faire confiance aux entre­prises – regar­dez le ramdam avec la ferme­ture de Google Reader).

Mais un mongueur de Perl m’a dit au FOSDEM connaître un peu les gens derrière Github car il les a rencon­trés au cours de je ne sais plus quelle confé­rence. En gros, ce sont 5 gus dans un garage (pour reprendre l’ex­pres­sion consa­crée). Et ça, ça me plaît.

Je m’étais créé un compte Github il y a déjà un certain temps, sans vrai­ment m’en servir, jusqu’à mon impli­ca­tion dans liquid­prompt. Et là j’ai décou­vert comme github simpli­fie la ques­tion de la parti­ci­pa­tion à un projet. C’est juste tout simple. Tu forkes, tu modi­fies, tu commites, tu cliques sur pull-request, et c’est au(x) proprié­taire(s) de faire le reste. Plus les discus­sions éven­tuelles avec les autres déve­lop­peurs.

Cette simpli­cité de parti­ci­pa­tion encou­rage vrai­ment les contri­bu­tions et ça, pour des projets libres, ben c’est juste cool. Sans comp­ter qu’on peut, grâce à Github, avoir des retours de personnes qu’on n’at­ten­dait pas. Genre un des déve­lop­peurs prin­ci­paux d’Ether­pad lite qui est venu me causer sur la page Github de mon projet Ether­padAd­min. Si j’avais laissé mon projet unique­ment sur mon redmine, il n’en aurait jamais entendu parlé.

Mon serveur étant un peu malmené par tout ce que je mets dessus et le serveur thin qui sert mon redmine étant un peu gour­mand (très gour­mand, si on regarde l’uti­lité réelle de mon redmine), j’ai décidé de stop­per mon redmine et de mirro­rer mes dépôts git de mon gito­lite vers github. Bah oui, je garde quand même un gito­lite, faut pas abuser non plus, je vais pas tout confier à un service que je ne maîtrise pas, sans comp­ter que ça me permet d’avoir des dépôts privés).

Pour le lien entre mon gito­lite et github, j’ai utilisé un hook tout bête mais bien pensé : https://github.com/mira­cle2k/gito­lite-simple-mirror

Non, je n’aban­donne pas mon indé­pen­dance (puisque j’ai toujours mes dépôts chez moi avant de les pous­ser sur github), je profite juste d’un bon service qui apporte une vraie plus-value… et je soulage mon serveur qui en a bien besoin ! :D

NB : les anciens liens poin­tant vers le redmine sont redi­ri­gés vers ma page Github ou direc­te­ment sur la page du projet si c’était un lien vers un projet en parti­cu­lier.

Me soutenir sur Tipeee Me soutenir sur Liberapay