Git, TLS et Debian: le bon, la brute, le truand !🔗

Ce blog fonctionne avec Ikiwiki. J'ai mis en place la gestion du contenu de ce site web dans un arbre git depuis quelque temps déjà. Avec le recul, c'est un investissement payant: je peux revenir en arrière facilement et je peux facilement cloner le dépôt pour en faire une sauvegarde. Ce dépôt est accessible en écriture à distance via HTTPS afin de me permettre de publier des articles depuis l'extérieur. Maintenant que je travaille (trop) loin de mon domicile, je ne peux plus faire autrement: je dois utiliser ce mode de publication.

L'ensemble est sécurisé par un accès HTTP via TLS et par login/password d'authentification. Dernièrement, j'ai rencontré un problème avec l'accès à mes dépôts: impossible de récupérer les données, il y avait toujours une erreur liée à la certification TLS. Ne pouvant plus rien publier sur mon blog, il fallait bien que je trouve un correctif.

Si vous avez une erreur du type:

error: gnutls_handshake() failed: A TLS packet with unexpected length was received. while accessing …
fatal: HTTP request failed

c'est que vous avez le même symptôme que moi. L'explication est assez simple. Pour gérer ses connexions réseau, Git utilise Curl (enfin sa bibliothèque). Cette dernière peut utiliser la bibliothèque gnuTLS ou bien Openssl. Sous Debian, c'est gnuTLS qui a été retenu et il se comporte de manière plus stricte sur la gestion du TLS. Dans mon cas précis, j'utilise un certificat auto-signé et c'est ce qui déclenche l'erreur TLS. Il est malheureusement impossible de la contourner, même en utilisant l'option Git http.sslverify.

Après quelques recherches, j'ai fini par mettre la main sur une correction un peu barbare mais qui a le mérite de marcher.

Il suffit de refabriquer le paquet git en lui demandant d'utiliser la bibliothèque Curl qui repose sur OpenSSL (libcurl4-openssl-dev). Dit comme ça, ça semble simple. Dans la pratique, il y a juste un petit effort à fournir:

# Installer de quoi fabriquer des paquets
apt-get install build-essential fakeroot dpkg-dev
# Un petit répertoire temporaire pour la création du paquet
mkdir ~/git-openssl
cd ~/git-openssl
# On récupère les sources du paquet Git de Debian.
apt-get source git
# On récupère les dépendances pour fabriquer le paquet Git:
apt-get build-dep git
# On installe bien sûr la bonne bibliothèque Curl
apt-get install libcurl4-openssl-dev
# On dépaquette l'archive source en vue de la compilation
dpkg-source -x git_1.7.10.4-1+wheezy1.dsc
# On se place dans le bon répertoire
cd git-1.7.10.4/
# Ensuite,  il reste à transformer toute mention de libcurl4-gnutls-dev
# en libcurl4-openssl-dev dans le fichier debian/control
emacs debian/control
# Une fois ce travail effectué, on peut lancer la fabrication du paquet.
# Attention, cette action lance également la batterie de tests unitaires
# de git: c'est donc extrèmement long, même sur une machine moderne…
dpkg-buildpackage -rfakeroot -b
# Enfin, on peut l'installer:
cd ..
dpkg -i ./git_1.7.10.4-1+wheezy1_amd64.deb

Pour que ça marche, il vous faudra disposer du dépôt APT source (deb-src). C'est une méthode un peu bourrine, mais elle a le mérite de fonctionner. Ce qui me paraît étrange, c'est qu'il n'y a aucun rapport de bugs dans le paquet Git ni dans la libcurl3-gnutls… À noter que la version de git qui est disponible dans le dépot backports de Wheezy est également affectée.

Avec le correctif proposé, je peux à nouveau accéder à mes dépôts Git en lecture et en écriture, sans aucun problème. J'ai trouvé l'astuce à l'emplacement suivant (rendons à César ce qui est à César).