• On est en train de passer un dépôt de Subversion vers Git, en vue d’abandonner le premier au profit du second (yay !).
• On est obligé de bosser sur un dépôt Subversion, mais on refuse de laisser tomber le confort quotidien de Git en local.

Git propose une passerelle au moyen de la commande git svn et de ses sous-commandes. Moyennant quelques précautions d’usage, on peut ainsi travailler avec Git en local et synchroniser vers (et depuis) le dépôt Subversion distant. C’est un sujet assez vaste et j’y reviendrai plus en détail dans un prochain billet.

Toutefois, ceux qui rencontrent déjà ces situations ont sans doute remarqué un phénomène irritant : Git ne prend pas en compte la propriété svn:ignore. En fait, il ne prend en compte que svn:executable (ce qui est déjà pas mal, vu comme elle est grave utile…).

La propriété svn:ignore est similaire au fichier .gitignore : elle permet de lister des motifs de fichiers qui ne doivent pas être versionnés. Il est donc dommage qu’on n’en bénéficie pas automatiquement sur Git, risquant ainsi de versionner par erreur des fichiers qui devraient être ignorés.

Voilà pourquoi j’ai développé un petit outil qui va automatiquement synchroniser vos svn:ignore vers vos .gitignore, à tout moment, pour votre master (c’est-à-dire votre trunk distant), sans écraser d’éventuelles infos déjà présentes dans vos .gitignore… C’est le premier d’une série probable de petits scripts du même genre, destinés à faciliter l’utilisation de Git au quotidien.

Comme mon récent outil git-basecamp, il est disponible en open-source, et documenté, sur GitHub. Je vous invite donc à jeter un œil à mon dépôt git-helpers. Notez qu’il existe aussi une quantité de dépôts nommés « git-tools » sur Github, mais aucun de ceux que j’ai regardés n’avait cette fonctionnalité (et la plupart des aides qu’ils fournissent m’ont semblé un peu basiques…).

Enjoy !

Ce billet tente de vous donner toutes les clés (ahem) pour comprendre et manipuler aisément vos identités SSH.

Après un topo rapide sur le principe des clés asymétriques, nous verrons rapidement quels algorithmes sont à favoriser, quelles tailles de clé sont acceptables, et les meilleures pratiques de protection de vos clés (tant en termes de passphrase que de gestion des droits d’accès à vos fichiers de clés).

Ces fondamentaux étant assimilés, nous pourrons vérifier si vous avez déjà des clés, comment en créer de nouvelles, et comment vous en servir efficacement et confortablement pour vos accès à des dépôts Git.

Principe des clés asymétriques

Quand vous travaillez avec des clés asymétriques, par principe, vous avez deux clés (on parle de paire de clés) : une clé publique, que vous pouvez diffuser librement, voire mettre à disposition sur un serveur de clés ; et une clé privée, qui constitue véritablement votre « identité », et ne doit jamais être diffusée : elle reste simplement présente dans votre dépôt de clés personnel.

Comme toujours en cryptographie, on peut faire deux choses avec une clé : chiffrer un contenu (l’encrypter) ou le signer (calculer une valeur unique, reposant sur le contenu concerné et sur votre clé privée, pour obtenir une valeur de signature, comme un cachet spécifique). Seule la clé « d’en face » (la publique si vous avez utilisé la privée, et inversement) permet de déchiffrer ou de vérifier la signature. Notez au passage que signer un contenu permet non seulement d’attester que vous êtes bien l’envoyeur (ou l’auteur, etc.), mais aussi que le contenu n’a pas été modifié après signature.

Une paire de clé permet donc de vous représenter vis-à-vis d’un système tiers, en lui fournissant à l’avance votre clé publique, pour ensuite communiquer avec lui à l’aide de votre clé privée ; puisque seules les clés d’une même paire peuvent se comprendre, le système distant est à même non seulement de vérifier que vous êtes bien celui (ou celle) que vous prétendez être, mais aussi que ce qu’il reçoit est bien ce que vous envoyé. Pas mal !

Si le sujet vous intéresse, vous trouverez une tonne d’infos sur Wikipedia. Mais si j’étais vous, je finirais cet article d’abord histoire de ne pas partir sur une tangente…

RSA vs. DSA

Il existe de nombreux algorithmes de chiffrement basés sur des clés asymétriques, mais les deux dominants, et de loin, son RSA et DSA, d’après les initiales de leurs auteurs respectifs. RSA est historiquement le premier, et DSA a été développé plus récemment, comme une alternative alors qu’RSA était encore breveté.

De nombreux didacticiels, articles et documentations exploitent RSA, mais vous pouvez choisir librement RSA ou DSA pour vos clés, du moment que vous utilisez une taille suffisante (voir ci-après).

Taille de clé

Une clé a une taille, exprimée en nombre de bits. Par exemple, les clés exploitées par les certificats de chiffrement des sites web utilisant la protection SSL (vous savez, ces URLs qui démarrent en https://, par exemple votre gestion de compte bancaire en ligne) sont généralement limitées, pour des raisons légales d’origine honteuse, à 256 bits. En revanche, vos propres clés ne font pas (ou plus, suivant le pays où vous vivez) l’objet d’une telle limitation.

À ce jour, une taille de 2Ko, c’est-à-dire 2048 bits (oui, 8 fois plus qu’un certificat bancaire !) est considérée raisonnablement sécurisée pour RSA, en tout cas pour un particulier. En gros, même si la toute-puissante NSA avait envie de casser votre chiffrage pour jeter un œil à ces données, il leur faudrait quelques heures pour y parvenir. Et pour qu’ils daignent vous allouer quelques heures de leur système, vous devez en gros être un très, très gros poisson.

Donc on est tranquilles.

Notez qu’en revanche une clé DSA fait obligatoirement 1024 bits (1Ko). C’est comme ça.

Passphrase

Vous avez certainement l’habitude voir le terme password, c’est-à-dire mot de passe. Et vous avez sûrement déjà rencontré des tas de systèmes, services et outils qui vous demandent de saisir un mot de passe, en lui imposant une taille minimum (ce qui est bien) et maximum (ce qui est parfaitement stupide et contre-productif). À cause de ce maximum, justement, ces systèmes insistent pour que vous mélangiez à loisir majuscules, minuscules, chiffres et symboles, et n’utilisiez pas de termes trop évidents (dates de naissances, prénoms, noms de vos animaux, mots basiques, segments de touches du clavier, etc.).

Du coup, tout le monde se retrouve forcé d’utiliser des mots de passe genre &dF@8^Xy+, qui sont tellement tordus qu’on s’empresse de les noter sur un papier, massacrant instantanément l’utilité du mot de passe en le rendant facile à découvrir en cas de besoin (surtout quand ledit papier est un Post-It™ collé sous le clavier, voire sur l’écran) (ne rigolez pas, je l’ai déjà vu) (plusieurs fois) (en fait, si ça se trouve, vous l’avez déjà fait) (gredin(e) que vous êtes).

Par contraste, une passphrase (pas d’équivalent français satisfaisant à ma connaissance, aussi essayez de le prononcer correctement, genre passfrayz) est une petite phrase, ou tout au moins un morceau de phrase, donc plusieurs mots. Et je dis bien mots, parce qu’en l’occurrence, utiliser de vrais mots et noms ne pose plus guère de problème, dès lors qu’on en a au moins 3 ou 4, surtout s’ils n’ont aucun rapport.

« Mais on m’a toujours dit que des vrais mots Saymal™ ! », me hurlez-vous avec consternation, le sourcil vengeur.

Oui, sauf dans des jolies passphrases. Pourquoi donc ? Parce que le niveau de complexité augmente de façon plus qu’exponentielle au fil des caractères, en particulier quand on commence à découper en mots. En cryptographie, on considère qu’un mot de passe, ou une passphrase, peuvent appartenir à plusieurs niveaux de sécurité, qui correspondent à la difficulté qu’on rencontre pour les casser. La recherche sur le sujet abonde est se met à jour chaque année, notamment au sein de conférences spécialisées comme la célèbre DEFCON.

Je suis assez fan de cet excellent article de Thomas Baekdal, qui illustre bien le sujet. Imaginons une passphrase qu’il faudrait des centaines d’années, voire des millénaires, dans l’état actuel de la technologie la plus avancée, pour casser par un moyen technologique. On qualifie une telle passphrase de « sécurisée à vie » (secure for life). Eh bien, pour obtenir une telle passphrase, il suffit de combiner au moins 3 mots, pas nécessairement sans rapport, pour un total d’au moins une dizaine de caractères. Voici quelques exemples de telles passphrases :

• this is fun (sérieux ! Il faudrait au moins 25 siècles…)
• j’aime les noix de cajou (le système solaire aura déjà imposé d’ici qu’on casse ça…)
• des filles à la vanille
• san pellegrino enterre badoit
• i love to boogie
• tu fais du vb dommage eliane
• entre git et svn j’ai choisi
• plutot crever qu’installer vista
• …

Vous avez immédiatement perçu l’avantage monstrueux d’une bonne passphrase, lecteurs fûtés que vous êtes : non seulement c’est sécurisé à vie, mais en plus c’est carrément plus facile à mémoriser !

Bon, vous allez me rétorquer que c’est vachement plus long à taper, et là je vous répondrais que oui, mais qu’il existe des tas d’outils de type agents SSH, trousseaux de clés et systèmes de mémorisation de mot de passe (dans votre navigateur par exemple), qui sont de manière générale une bonne idée (surtout si vous leur mettez un mot de passe maître, à taper une seule fois par session, qui les déverrouille explicitement). Puisque nous parlons ici spécifiquement de clés SSH, nous aborderons plus loin comment éviter la saisie systématique de sa passphrase.

Parce que ne vous avisez surtout pas de « résoudre » le pseudo-problème de la longueur du texte en utilisant une passphrase vide. Ce serait complètement stupide, parce que ça reviendrait à ne pas du tout protéger votre clé ! Donc assurez-vous d’utiliser une bonne passphrase bien solide, et préférez les agents SSH (que ne vous verrons plus bas, je le répète) pour vous éviter des saisies multiples.

Vérifier ce qu’on a comme clé

Bon, il est l’heure de vérifier si vous avez déjà une paire de clés du bon type (DSA)…

Sur tous les systèmes Linux et Unix, vos clés SSH sont normalement stockées dans un dossier .ssh à la racine de votre profil. Ouvrez donc un terminal et tapez la commande suivante :

ls -lAF ~/.ssh

Si vous avez un message d’erreur (genre « je ne connais pas ce dossier ») ou un listing ne contenant que des fichiers style authorized_keys, config ou known_hosts, vous n’avez pas encore de clé exploitable. Ce que vous cherchez, ce sont des fichiers qui, classiquement, s’appellent id_dsa (la clé privée) et id_dsa.pub (la clé publique). Ce sont de bêtes fichiers texte, avec un peu d’enrobage autour de votre clé représentée dans un format appelé Base64. Par exemple, sur mon portable, le listing donne ça :

$ ls -lAF ~/.ssh
total 48
-rw------- 1 tdd tdd    90 déc 11  2009 config
-rw------- 1 tdd tdd   736 aoû 23  2007 id_dsa
-rw------- 1 tdd tdd   609 aoû 23  2007 id_dsa.pub
-rw------- 1 tdd tdd   736 jul 17 09:17 id_dsa_git
-rw-r--r-- 1 tdd tdd   609 jul 17 09:17 id_dsa_git.pub
-rw------- 1 tdd tdd   668 avr  6 22:53 id_dsa_sips
-rw-r--r-- 1 tdd tdd 23696 jul 24 11:07 known_hosts

Comme vous pouvez le constater, ma clé fondamentale date un peu (23 août 2007), et j’ai une deuxième paire dédiée pour Git (id_dsa_git), ce qui n’a rien d’obligatoire, ainsi qu’une troisième, dont je n’ai ici que la clé privée, et qui me sert encore à autre chose.

Vous n’avez pas de clé DSA, ou vous en avez une dont vous ignorez la passphrase pour quelque raison que ce soit ? Ou peut-être en voulez-vous une dédiée pour Git ? Pas de souci, on va en créer une nouvelle !

Créer une clé

L’outil de prédilection pour créer des clés (et un peu tout ce qui touche à la crypto) est le système OpenSSL. C’est un ensemble de bibliothèques et outils en ligne de commande, présent sur tous les Linux et Unix (entre autres), qui constitue le standard de facto. Dommage qu’il soit si mal documenté… Ici, on peut passer par une surcouche spécialisée dans les clés SSH, au travers de l’outil en ligne de commande ssh-keygen.

Pour créer une paire de clés DSA, on procède comme suit. Je suppose ici que vous allez changer le nom par défaut vers id_dsa_ga (pour Git Attitude), mais si vous laissez le nom par défaut, il suffit de taper Entrée à la question correspondante. Évidemment, utilisez votre propre chemin.

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/tdd/.ssh/id_dsa): /Users/tdd/.ssh/id_dsa_ga
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tdd/.ssh/id_dsa_ga.
Your public key has been saved in /Users/tdd/.ssh/id_dsa_ga.pub.
The key fingerprint is:
65:31:7e:ee:49:3a:66:cd:92:7b:02:2b:bf:b3:1a:79 tdd@CodeMagic.local
The key’s randomart image is:
+--[ DSA 1024]----+
|          o      |
|         . o     |
|          + .    |
|         o o     |
|        S   o    |
|       ..  B .   |
|      o EoB =    |
|      .ooo.+.    |
|      .+++.o     |
+-----------------+

Suivant votre version de ssh-keygen, vous n’aurez pas forcément le randomart à la fin (et en vrai, on s’en fout), et la ligne qui suit « The key fingerprint is: » sera totalement spécifique à votre propre exécution de la commande. Chaque paire de clé a une empreinte unique.

Et de fait, regardez un peu vos clés toutes neuves (vous aurez naturellement des valeurs différentes de celles présentées ici, celle de la privée étant d’ailleurs tronquée par mes soins :)

$ cat ~/.ssh/id_dsa_ga
-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6ED59B013D8A361F

pB5eHHpvXxoz6i1jFzlKANv9W6SeHw664PV/1A90acR/Mw/ERQvTQKo3TaLaFhkb
…
NwhQFyxZZty2hn6xrv5UIAGTpjk+P2+waRmSno1Vg1x0epCp45kvFRv9AiXsOpt4
RgzPC5+a6kjPf8EtyozGoQ==
-----END DSA PRIVATE KEY-----
$ cat ~/.ssh/id_dsa_ga.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAJhbQcZK8lFMvpw7trbFj51Sqjd9nKBu2xkw/kvUAQlPQPaIRLOiq92fxp+jzp97xDqpwFnvU++ptUiB1nQQ8oq8l5t5QuHwfMMnSDMXhWf2235i4Lw2DtRTbxs0UQJ1l+QxO/AjlV/POcFpq6Z0PKMosi8TslqqPaqAbQtiEX2DAAAAFQDaK1EZY12itrt0lomTAOT0QATilwAAAIAK9C0YTR0T82r7TFheo/+vU6dS9KCypEjR7rEVf7MxCJLd9MQNkVTJe7XCFnYeT9oz7h8NbYHGyDQr7EZGIchtiju6EPFWuQWEAJAHq7z9s9ygoVqyWSQo0y/6riihJk5bo+Etj//OdwndlfKg0c6UGBFg8T2i6nKsbmMMEAI+XAAAAIA+bPjEeoZhwLuCp3Bv0+B4mWgGqnb2IhRSVDQNYeHIofhiSY7prVB+O1iQhrN/EJlygkaFWNaVlPmxrXa+8i+ZGWeVlAaKJdSAsDawNjOaHTi6/Cfqm7NTrLIIeOcjjxwrPLPZ3v0tP8MFjhYFdgjooYjTDzqQmpCGVSA4hXtqhg== tdd@CodeMagic.local

Notez que les clés publiques sont généralement formatées sur une seule ligne ; dans une liste de clés (par exemple le fichier ~/.ssh/authorized_keys, qui liste les clés publiques dont les titulaires peuvent accéder à votre compte via SSH), on a donc en général une clé par ligne. La fin de la clé publique est son commentaire, qui vaut par défaut « identifiant@machine », mais peut être changé.

Dernière info sur la manipulation des fichiers de clé : on peut changer la passphrase d’une clé SSH avec la ligne de commande suivante :

$ ssh-keygen -p -f ~/.ssh/le_fichier_de_cle

La commande vous demandera votre ancienne passphrase, puis la nouvelle avec une double saisie (initiale puis de confirmation). Pratique si vous aviez saisi une passphrase un peu pourrie, par exemple. En revanche, si votre clé est compromise (vous avez des raisons de penser qu’un tiers s’est approprié votre clé privée), ne changez pas la passphrase (ça ne servira à rien) : changez de clé !

Agents SSH

Un agent SSH est un outil intégré à votre système d’exploitation qui vous permet de ne saisir la passphrase d’une clé qu’une seule fois (pendant la durée de vie de l’agent, généralement limitée à votre session, entre connexion et déconnexion).

OS X intègre cette fonction dans son outil plus général de Trousseau d’Accès (Keyring) depuis Leopard (10.5). Avant cela (par exemple Tiger, la 10.4), il fallait ruser comme décrit dans cet article. La première utilisation d’une clé entraîne l’affichage d’une demande de passphrase, et la possibilité de stocker celle-ci dans le trousseau d’accès pour éviter des saisies supplémentaires durant la session.

Ubuntu et ses variantes intègrent cette fonction aux principaux gestionnaires de fenêtre (Gnome, KDE, etc.). Le workflow est similaire à celui d’OS X : la première utilisation entraîne une demande de passphrase avec persistence dans l’agent.

Pour les autres distributions Linux et gestionnaires de fenêtre, je ne sais pas trop si un agent est déjà disponible ou pas. Vous pouvez le vérifier en ouvrant un terminal puis en tapant :

$ set | grep SSH_AUTH_SOCK

Si vous ne voyez rien s’afficher, vous n’avez pas d’agent actif ; si vous voyez quelque chose (probablement du genre /var/run/….sock), alors vous en avez un.

Si vous n’avez pas d’agent actif, vous pouvez en lancer un manuellement à l’aide de la bien-nommée commande ssh-agent. Celle-ci crée un processus résident (un daemon) et affiche la série de commandes à balancer dans l’environnement (ou dans chaque terminal) pour qu’il soit au courant que l’agent existe, et donc qu’il essaie de s’en servir. Ces commandes consistent généralement juste à définir les variables d’environnement SSH_AUTH_SOCK et SSH_AGENT_PID. Du coup quand on lance un agent à la main dans le shell courant, on récupère généralement son affichage pour l’exécuter aussi sec, comme ceci :

$ eval `ssh-agent`
Agent pid 23038

Évidemment, vous verrez un autre numéro de processus (pid), mais le principe est le même.

À partir de là, à vous de tester le comportement lors de la première utilisation d’une clé SSH : si vous voyez une interception globale vous demandant de saisir la passphrase et proposant de la stocker dans l’agent, tout baigne. Si ce n’est pas le cas, vous allez devoir ajouter la passphrase à l’agent manuellement, en utilisant la commande ssh-add. Dans ce cas, soit vous avez une seule clé, et vous n’avez pas besoin de la préciser, soit vous en avez plusieurs et il faut indiquer laquelle :

$ ssh-add ~/.ssh/id_dsa_ga
Enter passphrase for /Users/tdd/.ssh/id_dsa_ga:
Identity added: /Users/tdd/.ssh/id_dsa_ga (/Users/tdd/.ssh/id_dsa_ga)

Après ça, la passphrase est automatiquement exploitée pendant toute la durée de vie de l’agent.

Ce type de manip’ est notamment utile quand on se connecte sur un serveur de production où on va faire une série de git pull, git submodule update, etc. et où on veut éviter de taper sa passphrase une tonne de fois. On commence par configurer l’agent, ajouter sa clé, et hop ! On est prêt à rouler.

Enfin, pour ce qui est de Windows, avec msysGit spécifiquement, vous trouverez quelques instructions pour lancer automatiquement ssh-agent sur cette documentation chez GitHub.

Publier sa clé publique ?

Les clés asymétriques ne sont pas seulement utiles pour SSH et les systèmes se greffant par-dessus. Elles sont aussi, par exemple, le moyen privilégié pour (dé)crypter ou signer numériquement (ou les deux) les e-mails. Je rêve du jour où tout le monde saura utiliser correctement le medium e-mail : pas de pièces jointes énormes ou débiles, pas de liste d’e-mails destinataires visible par tout le monde, pas de HTML pourri rempli de Comic Sans MS… et l’habitude de signer les e-mails importants. Ce dernier point, notamment, ouvrira le chemin des e-mails comme moyen valide de communication à valeur légale, par exemple avec votre banquier, votre notaire, votre avocat, etc.

Si le sujet vous intéresse, jetez par exemple un œil au client de messagerie Thunderbird et à son extension Enigmail, basée sur l’outil libre GnuPG (naturellement, il existe d’autres possibilités techniques autour d’Apple Mail, de GMail et j’en passe).

Dans un tel contexte, il est important de pouvoir facilement récupérer la clé publique de quelqu’un, soit parce qu’on veut lui envoyer un contenu confidentiel (on va donc le chiffrer avec la clé publique du destinataire, dont seule la clé privée pourra déchiffrer), soit parce qu’on a reçu un e-mail signé numériquement de cette personne (grâce à sa clé privée), et qu’on veut vérifier que ça vient bien d’elle, et que le contenu n’a pas été altéré (ce qu’on peut faire uniquement à l’aide de sa clé publique).

Bien entendu, la personne en question peut nous avoir, au préalable, transmis sa clé publique. Encore faut-il pouvoir faire confiance au mécanisme qui a fait cette transmission (il existe des moyens, dont l’empreinte de la clé, mais ce n’est pas le sujet de cet article). Un autre moyen plus général est, pour la personne, de publier sa clé publique aux yeux de tous. Pour cela, il existe des serveurs de clés. La plupart sont gratuits, et les plus connus sont répertoriés par les principaux systèmes exploitant des clés. En voici quelques-uns :

• keyserver.pgp.com
• pgpkeys.mit.edu
• pgp.webtru.st/

Et Git dans tout ça ?

La plupart des hébergements de dépôt Git reposent sur des clés SSH publiques pour identifier les personnes ayant un accès aux dépôts. Lorsque vous accédez à un dépôt authentifié, que ce soit en protocole git://… ou git@…, le système SSH sous-jacent va passer en revue vos clés privées au regard des clés publiques qu’il connaît, et s’il trouve une correspondance, vous demander la passphrase (à moins qu’un agent ne la lui fournisse tout seul) puis engager la suite des opérations.

Dans le cadre des ateliers Git Attitude, lorsque nous étudions l’interaction avec des dépôts distants, j’ai besoin de disposer de clés publiques dont vous avez l’homologue privée, afin de configurer vos accès au serveur Gitosis que nous utilisons. Vous recevez dans vos convocations une demande pour me fournir cette clé à l’avance, avec un lien vers cet article si vous vous sentez déboussolés

J’espère que cet article vous a été utile, et vous a permis de mieux comprendre les clés SSH et leurs meilleures pratiques d’utilisation. Si vous avez des questions, commentaires ou corrections, les commentaires sont là pour ça !

Quoi ?! Vous n’utilisez pas Basecamp ! Mais c’est pas bien, ça ! Allez donc voir comme c’est top.

L’idée est d’analyser vos messages de commit à la recherche d’un petit tag spécifique sur la fin, qui va permettre à un script post-commit de déterminer le temps de travail, l’éventuelle tâche spécifique associée, et de loguer le temps qui va bien. C’est super pratique et je m’en sers déjà sur plusieurs projets, toute la journée.

Ça se passe ici, et y’a une doc détaillée. Enjoy !

Récent… c’est-à-dire ?

À l’heure où j’écris ceci, la dernière version stable de Git est la 1.7.2.1. La plupart des systèmes pré-packagés sont encore sur la précédente, la 1.7.1.1 (qui est très récente aussi), mais ça va vite se mettre à jour…

Concrètement, les différences avec des versions plus anciennes (jusqu’à 1.5.0, qui a introduit les derniers changements en date de structure du dépôt) sont quelque peu mineures et focalisées sur des détails d’options et de raffinement dans les décorations des logs, l’exécution d’outils externes (on pense notamment aux outils de diff), quelques fonctionnalités de confort, etc.

En termes de compatibilité sur le dépôt et d’opérations courantes, tout Git au moins 1.5.0 saura manipuler un dépôt plus récent, par exemple (ce qui peut avoir son importance si, par exemple, vous déployez sur un hébergement mutualisé dont les versions seraient un peu rances).

Je vous recommande d’avoir au moins une 1.6.6, mais compiler le code source sur votre plate-forme reste la meilleure façon d’avoir une version à jour, optimisée pour votre situation et dotée de tout le dernier confort proposé, notamment pour les usages avancés.

Un mot sur la doc

Git est un outil extrêmement puissant et riche, avec ses quelque 75 commandes de haut niveau (dites « porcelain ») et près de 60 commandes de bas niveau, à usage surtout interne (dites « plumbing »). Même les commandes principales, utiles pratiquement au quotidien, qui sont à peu près 20, recèlent une puissance insoupçonnée ; à ce titre, leur documentation est un atout précieux.

En effet, je trouve que les auteurs et mainteneurs de Git ont fait un boulot exceptionnel sur la documentation des commandes, à laquelle on peut accéder soit en tapant git help COMMANDE soit, lorsqu’on a la commande man, avec un man git-COMMANDE (les deux sont équivalents mais je préfère personnellement la première syntaxe).

Cependant, les méthodes d’installation par source ou par paquets ne l’installeront pas toujours par défaut : il vous appartient d’installer les bons paquets auxiliaires (typiquement git-doc) ou d’appeler les bonnes commandes de compilation et d’installation. Nous y reviendrons.

Installer Git sur OSX

Sur OSX, je ne saurais trop vous recommander de passer par l’installeur binaire hébergé sur Google Code, le projet git-osx-installer. Il est calé (là tout de suite) sur la 1.7.2 et installe les docs au passage, donc aucune raison de se priver ! Tout est installé dans /usr/local/git par défaut.

C’est de loin l’option la plus simple : compiler à partir des sources sur OSX exige une kyrielle de pré-requis qui peuvent être pénibles à obtenir, qu’on passe par Macports, Fink, Homebrew ou d’autres voies…

Installer Git sur Linux

Approche 1 : utiliser des paquets

Il existe généralement plusieurs paquets se répartissant les fonctionnalités et documentations de Git, paquets aux noms raisonnablement explicites, typiquement git comme « paquet chapeau » (paquet virtuel entraînant l’installation des autres), git-core (la quasi-totalité des commandes), git-doc, git-gui, gitk et gitweb (interfaces graphiques et frontal web de navigation de dépôt), git-svn et git-cvs (passerelles avec d’autres SCM)…

Sur Ubuntu et ses dérivés, les paquets sont assez récents (1.7.0 sur Lucid Lynx à l’heure où j’écris ceci) ; il est toutefois possible d’avoir des versions très à jour en passant par un PPA (Personal Package Archive, dépôt Ubuntu officieux maintenu par une entité quelconque, un particulier par exemple), le plus connu dans le cas qui nous occupe étant celui d’Andrey Voronov, qui propose des paquets tout frais (donc 1.7.2) pour Ubuntu 8.04 (Hardy Heron) et 10.04 (Lucid Lynx). Si vous avez une 9.x, vous pouvez tester ces dépôts quand même, utiliser le paquet fourni (Git 1.6.0 en 9.04, Git 1.6.3 en 9.10) ou compiler la source.

Debian dispose de paquets raisonnablement récents, avec la 1.7.1 (si vous êtes en stable/lenny, vous aurez cependant besoin des dépôts « backports »).

Pour les distributions basées RPM, telles que Red Hat, SuSE et Mandriva, le site officiel de Git maintient des paquets RPM très à jour. Gentoo a un paquet dev-vcs/git en unstable, et comme c’est Gentoo, on est basés sur sources donc assez récent (1.7.2 semble-t-il). ArchLinux est, comme souvent, très à jour avec un paquet git en 1.7.2.1 qui n’a que peu de dépendances.

Enfin, sachez qu’on peut avoir un Git récent sur Solaris en passant par Sun Freeware.

Approche 2 : compiler le code source

Commencez par récupérer l’archive du code source complet (préfixe git-) au format de votre choix. Par exemple pour la 1.7.2.1, l’une des deux suivantes :

• http://www.kernel.org/pub/software/scm/git/git-1.7.2.1.tar.bz2
• http://www.kernel.org/pub/software/scm/git/git-1.7.2.1.tar.gz

D’une distribution à l’autre, les dépendances ne seront pas toujours les mêmes. Bon, vous allez faire une compil’, il vous faut donc naturellement build-essential, le paquet universel des distributions Linux pour pouvoir compiler des trucs. Je sais aussi qu’il vous faut généralement au moins Curl, Perl et Expat, mais si vous voulez les docs (et vous les voulez, faites-moi confiance…) vous aurez sans doute aussi besoin des paquets pour TCL/TK, xmlto et AsciiDoc. Sur une Debian/Ubuntu, ça donne une installation de paquets qui va durer un petit moment :

$ apt-get install -q -y build-essential libcurl4-openssl-dev curl perl expat tk asciidoc docbook2x xmlto

Allez donc prendre un café… Quand ce sera fini, c’est en revanche enfantin. Décompressez votre archive quelque part (par exemple dans /tmp/sources), allez dans le répertoire ainsi créé, puis :

$ ./configure
…
$ make all man
…
$ sudo make install install-man
…

La clé ici est de bien penser à préciser les cibles man à la compilation (par défaut on n’a que all) et install-man ensuite. Si vous aimez utiliser l’outil de consultations de docs info, vous pouvez ajouter les cibles info et install-info, respectivement.

Une petite vérif’ ?

$ git --version
git version 1.7.2.1

Bravo !

Installer Git sur Windows

Bon, déjà, soyons clair : ça sera largement moins bien que sur Linux ou OSX. Vous n’aurez pas les docs (pas de façon intégrée en tout cas), l’accès en ligne de commande (donc à toutes les commandes) n’est pas 100% automatique, et j’en passe. Mais bon.

Règle numéro 1 : tu ne te baseras par sur Cygwin. Car tu n’as pas une heure à perdre par commande, et la sous-couche Cygwin est horriblement lente en générale, et pour Git en particulier. Ouste !

Cela nous laisse les optionss suivantes :

• msysgit (également appelé « Git for Windows »). Cet outil propose un installeur exécutable hébergé sur Google Code, qui est assez bien maintenu (il est actuellement en 1.7.1). Il propose une interface graphique pour les opérations usuelles.
• SmartGit. C’est un enrobage Java, donc multi-plateformes en fait, autour de Git. On le trouve chez Syntevo, qui nous a déjà filé SmartSVN. Ça fournit une interface graphique pour les non-experts, notamment les non-développeurs, mais on n’y trouve, fatalement, aucune commande avancée. Pratique par exemple si vous voulez que vos graphistes / designers versionnent leurs fichiers au même titre que les développeurs. La version actuelle est la 1.5.4, je ne sais pas à quel Git ça correspond mais elle est sortie à peu près au moment de Git 1.7.1.1…

Complétion et prompt

Git fournit, dans son archive de code source (sa tarball), un script de complétion Bash tout simplement génial.

Il permet de compléter les commandes en profondeur (commandes, sous-commandes, arguments appropriés, y compris pour les aliases configurés dans Git), et fournit de surcroît la fonction de personnalisation avancée du prompt que j’avais déjà présentée dans Le prompt Bash qui change la vie avec Git (inutile donc de le garder dans votre fichier d’initialisation, ça ferait doublon pour rien).

D’ailleurs sa version ne cesse de s’améliorer (on a désormais une variable qui indique dans le prompt si on est en avance ou en retard par rapport à l’upstream, par exemple, et l’initialisation—qui a lieu la première fois d’une session qu’on arrive dans un dépôt—est de plus en plus rapide).

Que du bonheur ! Si vous ne voulez pas vous galérer à récupérer l’archive, la décompresser et piocher le bon fichier, faites donc juste la commande qui suit :

curl https://github.com/git/git/raw/master/contrib/completion/git-completion.bash -o ~/.git-completion

Ensuite, dans votre .bashrc (Linux) ou .profile (OSX), retirez si besoin vos fonctions de prompt existantes, et terminez en chargeant le script de complétion Git et en personnalisant votre prompt (ici avec plein de jolies couleurs) :

source ~/.git-completion
export GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWSTASHSTATE=1 GIT_PS1_SHOWUNTRACKEDFILES=1
export PS1='\[\033[35m\u@\h:\033[36m\W\[\033[0m\033[33m$(__git_ps1 " (%s)")\033[0m\$ '

Démonstration :

tdd@CodeMagic:~$ cd /tmp
tdd@CodeMagic:tmp$ git clone git://github.com/tdd/sprockets-rails.git
tdd@CodeMagic:tmp$ cd sprockets-rails
tdd@CodeMagic:sprockets-rails (master)$ echo 'toto' > toto
tdd@CodeMagic:sprockets-rails (master %)$ git add toto
tdd@CodeMagic:sprockets-rails (master +)$ echo 'tutu' >> toto
tdd@CodeMagic:sprockets-rails (master *+)$ git stash
tdd@CodeMagic:sprockets-rails (master $)$ git stash pop
tdd@CodeMagic:sprockets-rails (master *)$ git reset --hard HEAD
tdd@CodeMagic:sprockets-rails (master)$ git <TAB><TAB>
add                 commit              instaweb            revert
am                  config              lg                  rm
annotate            describe            log                 send-email
apply               diff                merge               shortlog
archive             difftool            mergetool           show
bisect              fetch               mv                  show-branch
blame               filter-branch       name-rev            st
branch              format-patch        notes               stage
bundle              fp                  pull                stash
checkout            fsck                push                status
cherry              gc                  rebase              submodule
cherry-pick         get-tar-commit-id   relink              svn
ci                  grep                remote              tag
citool              gui                 repack              whatchanged
clean               help                replace
clone               imap-send           request-pull
co                  init                reset
tdd@CodeMagic:sprockets-rails (master)$ git merge <TAB><TAB>
HEAD            master          origin/HEAD     origin/master
tdd@CodeMagic:sprockets-rails (master)$ git merge origin/master --<TAB><TAB>
--commit      --ff-only     --no-commit   --no-log      --no-stat     --stat
--ff          --log         --no-ff       --no-squash   --squash      --strategy
…

Whoooohooooo !

Conclusion

Comme vous pouvez le voir, installer un Git récent n’a rien de sorcier, et disposer d’un Git complet, avec documentation intégrée, et doté d’une complétion et d’un prompt idoines, change tout simplement la vie… Alors bonne gestion de versions !

• disposer d’un backup distant de son travail,
• mettre son travail à la disposition d’autrui,
• collaborer avec d’autres sur un projet.

Hébergement public ou privé ?

Lorsque le projet est libre, ou qu’en tout cas son contenu est public, le plus simple consiste à exploiter un bon service d’hébergement Git qui serait gratuit pour les dépôts publics. Dans ce domaine, l’acteur désormais incontournable (et particulièrement bien foutu) est le célèbre GitHub.

En revanche, pour les dépôts privés, soit on reste sur GitHub, mais dès lors, c’est payant (pas cher ceci dit : à partir de $9/mois, ce qui permet de bénéficier de l’infrastructure massive du service, notamment en termes de fiabilité de stockage). Soit on crée son propre hébergement Git, ce qui a notamment l’intérêt éventuel de le rendre interne à sa société (et donc, potentiellement, très rapide d’accès sur un réseau local performant).

Ce billet vise à explorer en détail l’option technique favorite pour héberger son propre serveur Git : Gitosis.

Quand on connaît la procédure, récupérer, installer et configurer Git, qu’on soit sur OSX ou Linux, est l’affaire de 10 à 15 minutes. En lisant ce billet et les explications, ce sera naturellement un peu plus long. Mais ça reste rapide et facile !

Principes de fonctionnement de Gitosis

Comme GitHub, Gitosis base sa gestion d’accès sur le protocole SSH et des clés asymétriques.

Chaque utilisateur reconnu par le système est identifié au moyen d’une paire de clés asymétriques dont le serveur connaît la partie publique : côté client, il faut donc disposer de la clé privée correspondante dans son « portefeuille de clés » SSH. Un même utilisateur logique dans Gitosis peut être associé à un nombre quelconque de clés (par exemple une depuis sa machine au boulot, une depuis son laptop, une par compte sur un serveur où du code est déployé…).

C’est à mon sens une excellente façon de procéder. En effet, révoquer l’accès peut se faire de façon très granulaire si on utilise une clé par couple Utilisateur + Machine : il devient alors possible de révoquer les accès depuis une machine quelconque, ou pour un utilisateur à travers toutes les machines, ou pour un cas Utilisateur + Machine précis.

Un autre aspect de Gitosis que j’aime particulièrement est que toute sa configuration est dans un… dépôt Git, ce qui fait qu’on la met à jour avec un git push. C’est délicieusement récursif, j’adore !

Installer le serveur

Allez, c’est parti, on va se coller un p’tit Gitosis perso.

Récupérer les dépendances éventuelles

Déjà, il vous faut Git. Mais si vous lisez ce blog, je suppose que vous l’avez déjà…

Il faut aussi Python et son module setup-tools. Sur OSX on a déjà l’équivalent, mais sur un Linux il faudra installer le paquet correspondant. Par exemple, sur Debian/Ubuntu :

$ apt-get install python-setuptools

À partir de là, on récupère Gitosis depuis son dépôt et procéder à l’installation :

cd /tmp
git clone git://eagain.net/gitosis.git
cd gitosis
sudo python setup.py install

Cette installation nous fournit une série de binaires (programmes) pour Gitosis, au premier rang desquels gitosis-serve, qui va servir de « shell » à l’utilisateur système git que nous allons créer. Ce binaire fournit toutes les fonctions du serveur Git, ainsi que le mécanisme d’authentification, de gestion des droits, etc.

Créer et configurer l’utilisateur « git »

Vous avez sans doute déjà remarqué que les URLs « lecture-écriture » d’un dépôt distant Git sont généralement de la forme git@le-serveur.tld:le-depot.git (ou plus rarement ssh://git@le-serveur.tld:le-depot.git, ce qui revient au même). La convention veut en effet qu’on configure un utilisateur système git sur le serveur, seul moyen d’accéder au serveur Git.

Cet utilisateur n’a pas de mot de passe, mais au lieu de fournir un shell classique (ce qui, vu le manque de mot de passe frontal, serait assez dangereux…), il exécute uniquement votre serveur Git, lequel se charge alors de l’authentification.

En revanche, le home directory (répertoire personnel) de ce compte constituera le dossier racine de vos dépôts Git sur le serveur. Du coup, plutôt que d’utiliser la convention usuelle (/home/login sur Linux, /Users/login sur OSX), on aura tendance à préciser un dossier plus conforme à ce type d’usage, typiquement /var/lib/git. Vous pouvez en fait mettre ce que vous voulez, mais je précise le raisonnement ici histoire que vous ne soyez pas surpris dans les lignes de commande qui vont suivre.

Il nous faut donc configurer cet utilisateur. C’est là que la procédure diverge entre les Linux (qui ont tous les binaires système adduser et/ou useradd) et OSX (dont la gestion des utilisateurs repose directement sur son mécanisme d’annuaire, c’est-à-dire sa couche LDAP).

Commençons par la version Linux. Selon la commande que vous voulez employer, les options ne sont pas exactement les mêmes. Voici les deux variantes :

sudo adduser --system --shell /bin/sh --gecos 'git version control' \
  --group --disabled-password --home /var/lib/git git

ou

sudo useradd --system --shell /bin/sh --comment 'git version control' \
  --user-group --home-dir /var/lib/git git

Passons rapidement en revue la signification de ces arguments :

• —system précise qu’il s’agit d’un utilisateur système : entre autres choses, son home directory ne sera pas initialisé avec les squelettes (fichiers initiaux d’un compte, présents en général dans /etc/skel).
• —shell précise le shell par défaut de l’utilisateur. Vu que l’accès SSH sur ce compte ne l’exploitera pas, ce n’est pas une source de danger, en revanche il peut être pratique de disposer d’un shell pour une authentification locale (avec su ou sudo -s) histoire de triturer le compte sous son identité directe en cas de besoin majeur.
• --gecos ou --comment fournissent le descriptif utilisateur qui sera associé dans l’annuaire des comptes locaux.
• --group ou --user-group spécifie que le seul groupe qui doit être associé à l’utilisateur est son groupe propre : il ne fera partie d’aucun des groupes utilisateurs par défaut qui pourraient être configurés sur le système, et n’aura donc pas d’accès indû à certains programmes ou emplacements du système de fichiers.
• —disabled-password indique que le compte n’a pas de mot de passe associé (vu qu’il n’est pas conçu pour faire l’objet d’une authentification). Dans useradd, qui n’est pas une commande interactive, le simple fait de ne pas passer de mot de passe dans les arguments a le même effet.
• --home ou --home-dir fournit le home directory du compte.
• On termine avec le nom du compte : git

La commande crée automatiquement le home directory et lui affecte les bons propriétaire et groupe. Ce ne sera pas le cas sous OSX, où on se contente de manipuler l’annuaire, ce qui n’impacte jamais le reste du système de fichiers. Voyons justement comment procéder :

sudo dscl . create groups/git gid 405
sudo dscl . create users/git uid 405
sudo dscl . create users/git NFSHomeDirectory /var/lib/git
sudo dscl . create users/git gid 405
sudo dscl . create users/git UserShell /bin/bash
sudo dscl . create users/git Password '*'
sudo mkdir /var/lib/git
sudo chown git:git /var/lib/git

Le binaire dscl (Directory Services Command Line) est l’interface en ligne de commande fournie par OSX pour manipuler son annuaire interne. Il nous faut d’abord créer le groupe, puis l’utilisateur à proprement parler. Attention, vous ne pouvez pas regrouper les dscl . create dans une seule et même commande, comme on pourrait être tenté de le déduire de la documentation pour cette commande : il est impératif que chaque couple clé+valeur ait sa propre commande.

Notez comme on termine en créant explicitement le home directory et en calant son propriétaire et son groupe.

Sur un OSX classique, les identifiants groupe et utilisateur 405 sont normalement libres. Vous pouvez toutefois le vérifier en amont avec les commandes suivantes, et si besoin prendre d’autres IDs qui, eux, seraient libres (ils n’ont pas besoin d’être identiques, mais c’est plus conventionnel) :

dscl . list groups gid
dscl . list users uid

Un petit détour au pays des clés…

Il nous faut à présenter définir comment cet utilisateur va se comporter en cas de connexion SSH utilisant son compte. Le boulot correspondant, ainsi que l’initialisation finale de Gitosis, sont fait par la même commande. Celle-ci a toutefois besoin de votre clé publique SSH afin de vous autoriser, notamment, à manipuler le serveur et le compte Git à votre guise.

Peut-être n’avez-vous pas de clé pour le moment ? Vérifiez avec la commande suivante :

ls -la ~/.ssh

Si vous voyez que le répertoire n’existe pas, ou que vous n’y voyez pas de paire de fichiers id_dsa/id_dsa.pub (ou id_rsa/id_rsa.pub), vous n’avez pas encore de clé. Et d’ailleurs, même si vous en avez déjà une, vous voulez peut-être en créer une seconde, spécifique pour votre exploitation de Git.

Pour générer une paire de clés asymétriques, on utilise la commande ssh-keygen. Je vous conseille d’exploiter l’algorithme DSA plutôt que le RSA, utilisé par défaut, qui est un peu moins sécurisé. Le chemin proposé par défaut pour votre clé sera ~/.ssh/id_dsa ; si vous avez déjà une telle clé mais en voulez une supplémentaire, pensez à changer le nom vers quelque chose de plus spécifique (par exemple ~/.ssh/id_dsa_git) pour ne pas écraser la clé existante.

Voici ce que ça donne sur mon OSX Snow Leopard :

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/tdd/.ssh/id_dsa): /Users/tdd/.ssh/id_dsa_git
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tdd/.ssh/id_dsa_git.
Your public key has been saved in /Users/tdd/.ssh/id_dsa_git.pub.
The key fingerprint is:
9d:ab:3c:56:ef:ad:06:e1:da:13:d5:1f:74:4e:a9:46 tdd@CodeMagic.local
The key's randomart image is:
+--[ DSA 1024]----+
|                .|
|             E oo|
|            ..oo.|
|         ....o...|
|        S.oo.  ..|
|          =.    .|
|         +.+     |
|       .+.o o.   |
|       .o. +o..  |
+-----------------+

(Naturellement, vous n’aurez pas la même empreinte (fingerprint) et donc pas le même randomart ; c’est normal, le contraire serait d’ailleurs inquiétant.)

Utilisez ce que vous voulez comme passphrase pour la clé, mais évitez un truc bateau, encore plus du vide. Inutile de rendre votre clé utilisable par tout le monde…

Une fois la génération terminée, vous devriez voir deux nouvelles clés, la privée et la publique (celle dont le nom finit en .pub) dans votre dossier SSH :

$ ls -l ~/.ssh
total 48
-rw-------   1 tdd tdd    90 déc 11  2009 config
-rw-------   1 tdd tdd   736 aoû 23  2007 id_dsa
-rw-------   1 tdd tdd   609 aoû 23  2007 id_dsa.pub
-rw-------   1 tdd tdd   736 jul 17 09:17 id_dsa_git
-rw-r--r--   1 tdd tdd   609 jul 17 09:17 id_dsa_git.pub
-rw-------   1 tdd tdd   668 avr  6 22:53 id_dsa_sips
-rw-r--r--   1 tdd tdd 23286 jul 16 12:20 known_hosts

Installer Gitosis à proprement parler

OK, cette parenthèse refermée, nous pouvons lancer la commande d’initialisation de Gitosis :

sudo -H -u git gitosis-init < ~/.ssh/id_dsa_git.pub

(Si vous voulez utiliser une autre clé publique, ajustez simplement le chemin indiqué)

L’option -H s’assure que la commande gitosis-init (installée tout à l’heure par notre python setup.py install) s’exécutera depuis le home directory de l’utilisateur indiqué par -u git, et non depuis le répertoire courant.

La commande gitosis-init requiert sur son entrée standard la clé publique de l’utilisateur susceptible de triturer le compte manuellement.

Sur OSX, il va aussi nous falloir contourner un problème de PATH (liste des endroits où le système cherche les binaires qu’on lui demande d’exécuter), en ajoutant la commande suivante :

sudo su git; echo "export PATH=$(git --exec-path):$PATH" > ~/.bashrc; exit

De cette façon, on est certain que l’utilisateur git, pour exécuter ses binaires, aura bien tous les bons chemins sous la main. Encore une fois, pas besoin de ça sous Linux : juste OSX.

Ultime étape de l’installation : activer le post-update hook de Gitosis afin que toute mise à jour de configuration soit bien prise en compte :

sudo chmod u+x /var/lib/git/repositories/gitosis-admin.git/hooks/post-update

Les serveurs Git proposent en effet tous un mécanisme de hooks (points d’ancrage) qui permet de faire exécuter au serveur une ou plusieurs tâches, de façon automatique, à divers moments. Le post-update hook, équivalent du commit hook de Subversion, est le plus employé, puisqu’il se déclenche après toute mise à jour d’un dépôt sur le serveur, et permet donc, par exemple, de déclencher la suite de tests dans le cadre d’une démarche d’intégration continue, ou encore de signaler le push sur divers canaux (e-mail, messagerie instantanée, IRC…).

Dans le cadre de Gitosis, le post-update hook du dépôt de configuration (gitosis-admin) s’emploie à refléter les changements du dépôt dans la configuration concrète du serveur (notamment en ce qui concerne les utilisateurs, leurs clés, et les dépôts reconnus).

Ce qui nous fait une excellente transition vers la section suivante…

Configurer Gitosis… avec Git

Eh oui, Gitosis se configure en accédant au dépôt pré-installé gitosis-admin. On le récupère comme suit :

# cd où ça vous semble bien, puis…
git clone git@localhost:gitosis-admin.git
cd gitosis-admin

(Si vous avez installé Gitosis sur une autre machine que celle où vous faites le git clone, remplacez localhost par le nom ou l’IP du serveur).

Le dépôt est constitué principalement de deux choses :

• Un fichier de configuration gitosis.conf, qui définit les dépôts, comptes utilisateurs, groupes d’utilisateurs et droits d’accès aux dépôts.
• Un répertoire keydir/ contenant, pour chaque nom d’utilisateur présent dans gitosis.conf, un fichier avec le même nom et l’extension .pub, qui liste les clés publiques associées à cet utilisateur.

Définir les utilisateurs

Le fichier de configuration gitosis.conf a une syntaxe très simple, similaire aux bons vieux fichiers .ini. Voici le début de mon gitosis.conf pour la première session des Ateliers Git Attitude :

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = tdd

[group git-attitude]
writable = prems
members = tdd xavier olivier hugo maurice nicolas kaelig francois mickael jonathan thierry

Notez qu’on peut aussi fournir un accès en lecture seule dans un groupe, en utilisant la clé readonly au lieu de la clé writable. Toutefois, on passe quand même par le protocole SSH, pas par un accès anonyme de type git:// voire http://. Pour ces types d’accès, le mieux est d’utiliser git-daemon, qui est fourni avec Git lui-même. J’en parlerai un de ces jours…

Il existe de multiples façons de définir les dépôts, groupes, utilisateurs et droits. Ma préférence personnelle va au choix qu’on retrouve ci-dessus :

• Définir un [group] par « groupe de projets » (le nom du groupe est sans importance mais doit être unique)
• Y placer le ou les noms des dépôts accessibles en lecture/écriture dans la clé writable
• Y placer le ou les noms des dépôts accessibles en lecture dans la clé readonly
• Y placer le ou les noms des utilisateurs concernés dans la clé members

Il existe d’autres manières de procéder, mais quoi qu’on fasse, les noms des utilisateurs sont à votre convenance. En effet, ils ne seront jamais utilisés par l’extérieur (notamment dans les URLs de dépôts distants), ce sont des « noms logiques » internes à Gitosis. La seule contrainte, c’est que le fichier recensant les clés publiques associées à un utilisateur soit nommé keydir/nom-logique-utilisateur.pub.

Ainsi, mon dossier keydir/ a l’aspect suivant :

$ ls -l keydir/
total 40
-rw-r--r-- 1 tdd tdd 610 jul 10 18:28 francois.pub
-rw-r--r-- 1 tdd tdd 618 jul 10 18:30 hugo.pub
-rw-r--r-- 1 tdd tdd 433 jul 10 18:28 jonathan.pub
-rw-r--r-- 1 tdd tdd 609 jul 10 18:28 kaelig.pub
-rw-r--r-- 1 tdd tdd 422 jul 10 18:29 maurice.pub
-rw-r--r-- 1 tdd tdd 604 jul 10 18:27 mickael.pub
-rw-r--r-- 1 tdd tdd 606 jul 10 18:30 nicolas.pub
-rw-r--r-- 1 tdd tdd 603 jul 10 18:29 olivier.pub
-rw-r--r-- 1 tdd tdd 609 jul  7 23:29 tdd.pub
-rw-r--r-- 1 tdd tdd 609 jul 10 18:30 thierry.pub

Chaque fichier recense la ou les clés publiques associées au compte, à raison d’une par ligne. Par exemple, keydir/tdd.pub contient la clé publique de mon compte sur mon laptop (je l’ai découpée ici en plusieurs lignes pour qu’elle soit lisible d’entrée sur le blog, mais encore une fois, en temps normal tout serait sur une seule ligne) :

ssh-dss AAAAB3NzaC1kc3MAAACBALsvVpQOjngftILkQYHMiztcmPq9jHJbmsM
rBiAuxG/6tLhd8n1q8tEP5D8dwcXI6KjsWZxJNfv2rW9f5wz+Pc9Ahxo+Ru9gCv
oFV3a5igMLdaWq/eaNCDn9HtZyBxHf6uXMtPekKroLqTn6lxTKHnve1HcVUgxqr
4cNBiUkEZyjAAAAFQC2ypQSwpy5+XNqHj4lesk39FXsnwAAAIAkqehiHDbd9x0H
cfRIwIGt1hwxUIIzljMfJPsvanI7VgP7e8LveP+ZI8ZE9/swlS9dmYDJlxJ12dI
w93fC7dpi6OWSZy2Bcr1JMNXqR1MSyt2LlcUk7G2hVvN3ThfC0D02Un/lUI/uYH
ciFjVTKttMG92aXy/y1EV/rUwdiW1NaQAAAIBWKFrXAu5hiheDuyL9m1LXPiU9K
ruoQ4AJXBaAKMY45R4rKckJPir4nha8z1lVtXt7MhWbLMendS2pZzkMS5xImxym
bK5i9SQgoXUjawvNiDUvgh0mHUkONkAkS8xl+NAPnUKxSj4l3cszvLhiPlp9m6U
30dMomUHe+M9CIgZrZg== tdd@CodeMagic.local

Si vous utilisez une clé RSA, vous aurez quelque chose d’un peu plus court, et démarrant par ssh-rsa au lieu de ssh-dss, comme c’est par exemple le case de Mauriz :

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7XwkkW4nDqT1r668SFgTfadtOuI
afNhe7dTRllM76rIfsjEc07nQovQLTU9t24whQr3HS0sEzPJ6Sz+F1SbjtfTCul
iNNinmcizswDJbXcwr6Pe6kDeb+ulB2tnmQ76janpWDpxYFZdYxqFqggHSc+Un+
ubenlENTUOB+sy7PVRn54lfe0Pjlk5HsmCLNNA81VV6O82/77XYTR+7VYMPEmj8
J4GYmpYiuNG5bM7aUnXPxJ73fG0eQXtCsZ9fGCah9eaxubfTQ8UvO+t+2aKc0a0
+unaFEvEndo/17uGIhVdZhIQzop9ygsi/hGQDp8IDLgxDGPhYuO/N8ozjWrPOYw
== mauricesvay@Macbook-Pro-de-Maurice.local

Définir des dépôts

Les dépôts sont définis par la simple présence de leur nom dans une clé readonly ou writable. Toutefois, un dépôt qui ne serait présent dans aucun writable ne pourra être rempli par personne et, du coup, ne servirait pas à grand chose…

Test : votre premier dépôt sur Gitosis

OK, calons ensemble le nécessaire à votre premier dépôt distant.

Paramétrer Gitosis

Primo, définissons l’accès. Supposons que votre nom d’utilisateur au sein de Gitosis sera the-boss, et votre dépôt hot-project. Ajoutez les éléments suivants à votre gitosis.conf :

[group my-projects]
writable = hot-project
members = the-boss

Ensuite, puisque Gitosis ne connaît pas encore votre compte, copiez votre clé publique au bon endroit et ajoutez-la dans l’index :

cp ~/.ssh/id_dsa_git.pub keydir/the-boss.pub
git add keydir/the-boss.pub

Il ne vous reste plus qu’à faire un commit puis un push vers Gitosis :

$ git commit -am "Ajout dépôt hot-project et utilisateur the-boss"
[master e46c687] Ajout dépôt hot-project et utilisateur the-boss
2 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 keydir/the-boss.git
$ git push
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 984 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)
To git@localhost:gitosis-admin.git
 ac757b7..e46c687  master -> master

Le post-update hook fait alors son travail, et votre configuration SSH pour l’utilisateur git est mise à jour. En effet, si vous êtes curieux, vous pouvez jetez un œil au fichier .ssh/authorized_keys de ce compte, et vous y verrez votre utilisateur the-boss et ses réglages dédiés (j’ai ajouté quelques passages à la ligne, et tronqué la clé publique, pour la lisibilité de cet article) :

$ sudo cat /var/lib/git/.ssh/authorized_keys
### autogenerated by gitosis, DO NOT EDIT
command="gitosis-serve the-boss",no-port-forwarding,
no-X11-forwarding,no-agent-forwarding,no-pty
ssh-dss AAAAB3NzaC1kc3MAAACBALs…gZrZg== tdd@CodeMagic.local

C’est grâce à ces lignes que Gitosis sait automatiquement, sur la base des clés privées dont vous disposez et qui correspondent à ses clés publiques recensées, quel utilisateur logique vous êtes et quels traitements SSH vous autoriser. La main passe immédiatement à gitosis-serve (dans un contexte très contrôlé), qui exploite la configuration Gitosis pour les droits d’accès.

Tester le dépôt

Comme toujours avec un dépôt distant, il existe deux cas de figure :

• Vous avez déjà des travaux locaux, qu’il s’agit alors d’envoyer sur le dépôt distant. Dans ce cas, nous allons simplement ajouter un remote et faire un premier push explicite (ainsi qu’une configuration pour pouvoir, par la suite, utiliser des pulls implicites).
• Vous n’avez pas encore de travaux locaux, auquel cas le plus simple est de démarrer avec un clone histoire de paramétrer d’un seul coup le remote, le push et le pull.

Voyons déjà le second cas, qui est le plus simple.

Rien dans les poches : on démarre avec git clone

Il vous suffit en effet de vous placer dans le dossier parent de votre futur dossier projet, et de faire un git clone, exactement comme si vous récupériez un projet existant ; la seule différence, c’est que là, le projet sera vide :

# cd où ça vous semble bien, puis…
$ git clone git@localhost:hot-project.git
Initialized empty Git repository in /Users/tdd/tmp/hot-project/.git/
Initialized empty Git repository in /private/var/lib/git/repositories/hot-project.git/
warning: You appear to have cloned an empty repository.

Notez les deux dernières lignes…

« Initialized empty Git repository in /private/var/lib/git/repositories/hot-project.git/ » (le chemin initial ne sera pas forcément le même, ça dépend du home directory que vous aurez donné à l’utilisateur système git, et sur OSX /var est en fait /private/var) indique que le serveur distant a bien connaissance de ce projet mais n’avait pas encore la moindre donnée pour lui : il a donc initialisé le dépôt distant (pour les curieux, il a juste créé le dossier et y a fait un git init --bare).

Sur la dernière ligne, avec « warning: You appear to have cloned an empty repository. », Git vous prévient que vous venez de cloner un dépôt vide, ce qui n’est pas en soi un problème mais reste une situation suffisamment atypique pour être signalée.

L’avantage de cette méthode, lorsque vous n’avez encore aucun travail local existant, est qu’elle configure d’entrée de jeu le remote et les éléments nécessaires pour faire des git push et git pull implicites (c’est-à-dire n’ayant pas besoin de préciser le remote et la branche). Pour vous en convaincre, jetez un œil à la configuration du projet ainsi clôné :

$ cat hot-project/.git/config
# (ou, pour un autre format, git config -f hot-project/.git/config --list)
[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
[remote "origin"]
  fetch = +refs/heads/*:refs/remotes/origin/*
  url = git@localhost:hot-project.git
[branch "master"]
  remote = origin
  merge = refs/heads/master

Notez la section [remote “origin”], qui définit le remote, et [branch “master”], qui définit la configuration distante de la branche master locale. Grâce à cette dernière section notamment, nous n’avons pas besoin de préciser quel remote et quelle branche distante exploiter pour un push ou un pull : on dit que la branche locale master est configurée pour tracker la branche distante origin/master.

Déjà du boulot en local : remote + push initial explicite + tracking

Bon, ça, c’était le cas simple. Imaginons maintenant que vous aviez déjà du boulot en cours. Simulons ça avec un dépôt local créé vite fait :

$ cd /tmp
$ mkdir existing-hot-project
$ cd existing-hot-project
$ git init
Initialized empty Git repository in /private/tmp/existing-hot-project/.git/
$ echo 'toto' > toto
$ git add toto
$ git commit -am "Du boulot local existant"
[master (root-commit) dbcb4c7] Du boulot local existant
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 toto

Il nous faut maintenant définir notre premier (et généralement notre seul) remote explicitement. Nous allons garder le nom conventionnel pour le remote principal : origin.

$ git remote add origin git@localhost:hot-project.git

À présent, il faut faire un premier push. Faute d’info de tracking résultant d’un clone ou d’une configuration manuelle, nous devons préciser le remote et la branche distante. Il n’y a pas de raison ici (et la plupart du temps) de nommer la distante autrement que la locale, donc on l’appellera aussi master.

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 229 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@localhost:hot-project.git
* [new branch]      master -> master

On y est presque (et manifestement Gitosis marche très bien). En effet, le tracking n’est pas défini automatiquement par notre push explicite tel que nous l’avons fait :

$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:

  [branch "master"]
  remote = <nickname>
  merge = <remote-ref>

  [remote "<nickname>"]
  url = <url>
  fetch = <refspec>

See git-config(1) for details.

Une première approche consisterait à ajouter la configuration correspondante à la main :

$ git config --add branch.master.remote origin
$ git config --add branch.master.merge refs/heads/master
$ git pull
Already up-to-date.

Je vous montre ça pour des pushes que vous pourriez déjà avoir fait, et où ces réglages pourraient s’avérer utiles. Mais en fait, la meilleure manière dans ces cas-là est d’ajouter une petite option au push explicite : -u (ou sa version longue, --set-upstream). Cette option va réaliser nos configurations pour nous. Essayons en virant le remote et en le rajoutant :

$ git remote rm origin
$ git remote add origin git@localhost:hot-project.git
$ git push origin master -u
Branch master set up to track remote branch master from origin.
Everything up-to-date
$ git pull
Already up-to-date.

Bon, vu qu’on avait déjà fait un push de notre travail local tout-à-l’heure, naturellement au nouveau push, « Everything up-to-date ». En revanche, notez le message « Branch master set up to track remote branch master from origin. », qui montre bien que Git a configuré pour nous le tracking entre branches locale et distante. Et de fait, un pull implicite juste après trouve ses petits.

En conclusion

Voilà, je crois que vous avez désormais toutes les billes pour mettre en place votre propre hébergement Git (et peut-être avez-vous appris au passage une ou deux choses sur la gestion des dépôts distants).

Il est vrai que nous n’avons pas vu comment installer un serveur Git sous Windows, mais au risque de troller, un serveur sous Windows… Soyons sérieux deux minutes ! Plus pragmatiquement, cela est principalement dû au fait que les serveurs Git reposent fortement sur SSH et des configurations avancées d’utilisateurs, toutes choses qui sont ardues à transposer sous Windows, et quand bien même on y arriverait finalement, seraient fortement ralenties par la nécessaire couche intermédiaire basée Cygwin. Sans parler des problématiques de correspondance d’attributs, de gestion de casse MAJ/min et d’horodatage des fichiers entre les univers Linux, OSX et Windows. Du coup, rendez-vous service et si vous hébergez du Git, faites-le sur Linux ou OSX. D’où ce billet.

Les commentaires sont ouverts, aussi n’hésitez pas à me faire part de vos retours, questions et suggestions.

Bon hébergement Git à tous !

Celui-ci repose sur une série de fonctions Bash dont la plus « high-level » est appelée à chaque prompt. Elle permet de voir immédiatement :

• Dans quelle branche on est
• Si on a des modifs en working tree
• Si on a des modifs en stage
• Si on a des fichiers untracked
• Si on a du stash

Toutes choses fort utiles au moment de faire son commit, histoire de ne rien oublier…

Voici le code source avec quelques commentaires. Vous pouvez aussi aller piocher le Gist directement.

Notez les variables qui configurent ce qui est affiché :

• GIT_PS1_SHOWDIRTYSTATE fait remonter les modifs en working tree (symbole *) et en stage (symbole +)
• GIT_PS1_SHOWUNTRACKED_FILES fait remonter les fichiers non présents dans l’index (non pris en compte jusqu’à ajout explicite) (symbole %)
• GIT_PS1_SHOWSTASHSTATE indique qu’on a des trucs dans le stash (symbole $)

Ça ralentit un tout petit peu le premier prompt de votre session dans un dépôt non trivial, le temps pour les commandes Git internes de construire les caches d’accès à l’index et à l’historique… Ensuite c’est instantané.

Je ne pourrais pas vivre sans !

Enjoy!