Je ne vois pas où est le problème de recalculer toutes les sommes de contrôle. C'est ce que fait Git à chaque fois qu'on clone un dépôt afin justement de vérifier qu'aucune version n'a été altérée.
Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.
Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.
Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.
Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.
Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.
Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.
Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.
Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.
Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.