Git 2.10 est disponible
Avec des améliorations relatives aux commandes Git push, Git clone et le renforcement de la sécurité des clés GPG

Le , par Olivier Famien, Chroniqueur Actualités
Depuis quelques jours, la version finale de Git 2.10.0 est disponible. Dans cette nouvelle version du logiciel de gestion de versions décentralisé, il faut s’attendre à plusieurs améliorations.

De prime abord, l’on note l’ajout de nouvelles fonctionnalités permettant au client Git d’éditer un rapport détaillé lors de l’envoi des données sur le serveur distant en exécutant la commande "Git push". Il faut rappeler que dans les versions antérieures, lorsque vous exécutez cette commande, il se trouve que la barre de progression affiche un ensemble d’éléments tels que les données envoyées, celles restant à envoyer, la vitesse de transfert, etc. Toutefois, lorsque l’opération est achevée, aucun rapport n’est fait quant à ce qui se passe au niveau du serveur distant. Pour résoudre ce problème, des améliorations ont été introduites dans cette nouvelle version afin de fournir aux utilisateurs de ce programme des rapports post-opération de réception.

En plus de ce rapport détaillé introduit dans cette nouvelle version, nous avons également la fonctionnalité "keepalive" permettant d’envoyer des paquets de données sur le réseau afin de garder la connexion active même lorsque vous n’êtes pas près de votre terminal.

Il faut souligner que ces deux nouvelles fonctionnalités présentées plus haut sont en œuvre côté serveur et sont rétrocompatibles avec toutes les anciennes versions de Git. Il est donc inutile de faire une mise à niveau pour ceux qui utilisent l’application cliente, mais le fournisseur d’hébergement lui a besoin de le faire pour que vous puissiez utiliser ces fonctionnalités.

Du côté de la commande "Git clone" utilisée pour cloner les dépôts à distance, l’on a également des améliorations qui permettent d’avoir des indicateurs de progression précis lors de la vérification de la réception des données sur le serveur distant.

Au niveau de la sécurité, Git 2.10.0 apporte une nouvelle option de configuration "log.showsignature" afin de vérifier les signatures pour chaque appel fait avec la commande "Git log".

En outre, nous avons le format de sortie par défaut pour la vérification des signatures qui a changé et montre maintenant le id de clé GPG au format 64 bits, même avec les anciennes versions de GPG. Cela a été implémenté afin de résoudre le problème de fausses clés qu’il est possible de générer afin de les faire entrer en collision avec les id de clés dans un espace 32 bits.

Autres nouveautés dans cette version, Git 2.10.0 accueille maintenant les attributs permettant de barrer des mots ou de mettre des éléments en italique. En dehors d’améliorations, plusieurs autres nouveautés sont également disponibles et concernent la gestion des archives, la génération des dates après l’année 2100, la gestion des protocoles, etc.

Source : Notes de version de Git 2.10.0

Et vous ?

Que pensez-vous des nouveautés de cette nouvelle version ?

Quelles sont les améliorations que vous souhaiteriez voir dans ce programme ?

Voir aussi

Forum Git

Forum Logiciels libres open source


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de hucste hucste - Membre à l'essai https://www.developpez.com
le 05/09/2016 à 22:33
Bonsoir,

Que le projet Git améliore sa sécurité et surtout l'usage des clés GPG, en soit, c'est très bien.
Là, où je suis surpris, c'est qu'il s'arrête à l'usage des "Long ID" alors qu'il est manifeste depuis 2013, qu'il faut privilégier l'usage de l'empreinte des clés GPG, car les identifiants GPG posent problèmes ... il existe même des guides de bonnes pratiques pour utiliser de manière correcte et sécurisée les clés GPG, et certains sont carrément des références à suivre au plus près.

Après avoir "étudié" toutes ces informations correspondantes, j'avais écrit fin avril 2016 un article à ce propos nommé "Du bon usage sécurisé de GPG", transcrivant en français toutes ces recommandations disponibles bien avant en anglais.

https://debian-administration.org/users/dkg/weblog/105 <= où pourquoi ne pas utiliser les informations GPG ID mais bel et bien l'empreinte (fingerprint) GPG.

Quant aux bonnes pratiques, je laisse à chacun le soin ... de lire ... puis d'agir ! ;-)

----

Je sais que je ne suis pas un grand technicien informatique, voire informaticien du tout ... et que je m'expose très certainement en publiant cette réponse ... mais je suis très surpris que l'équipe de Git est fait ce choix.
Si les risques sont modérés, voire minimes, à utiliser les empreintes GPG, plutôt que les identifiants GPG, pourquoi ne pas faire ce choix ?!
Contacter le responsable de la rubrique Accueil