Étude de cas
Vérifier les octets couverts par une empreinte
Un fichier peut sembler identique dans un éditeur tout en contenant des octets différents. Les fins de ligne constituent un exemple concret : LF utilise un caractère de contrôle, tandis que CRLF en utilise deux. Une empreinte calculée sur les octets peut donc changer alors que le texte affiché paraît inchangé.
Une vérification interne du 15 octobre 2026 a comparé les entrées d’une empreinte de code avec les objets conservés dans Git. Elle a permis de distinguer la stabilité du dépôt principal de celle d’une dépendance externe, puis de corriger une conclusion trop générale sur Windows.
Comparer les fichiers réellement lus
La vérification a relevé les 34 fichiers lus pendant le calcul de l’empreinte : 31 appartenaient au candidat étudié et trois à un registre externe épinglé. Pour chaque fichier, les octets de la copie de travail ont été comparés au blob Git brut, c’est-à-dire à l’objet conservé dans le dépôt avant application des filtres de sortie.
Les 34 fichiers sur disque étaient identiques à leurs blobs. Ils utilisaient tous LF. L’empreinte reconstruite à partir des blobs était donc identique à celle calculée sur la copie de travail. Le fait que cette copie se trouve sous Windows ne suffisait pas à conclure qu’elle utilisait CRLF.
Les attributs Git définissent la sortie
Git peut convertir les fins de ligne entre l’index et le répertoire de travail. L’attribut text active la normalisation; eol=lf impose LF dans la copie de travail. Quand les attributs ne précisent pas ce comportement, les réglages comme core.autocrlf peuvent intervenir. Ces mécanismes sont décrits dans les documentations officielles de gitattributes et de git-config.
Les 31 fichiers du candidat étaient couverts par des attributs imposant LF. Les trois fichiers du registre externe n’avaient pas d’attribut de fin de ligne applicable. Leur copie utilisée pour la revue était néanmoins en LF et correspondait aux empreintes épinglées.
| Ensemble | Copie utilisée | Export avec la configuration Windows observée |
|---|---|---|
| 31 fichiers du candidat | LF, identiques aux blobs | LF, identiques aux blobs |
| 3 fichiers externes | LF, identiques aux blobs | CRLF, différents des blobs |
Établir la cause de l’écart
Deux exports ont été comparés : l’un avec la configuration Windows observée, où core.autocrlf=true, l’autre avec core.autocrlf=false. Le premier a converti les trois fichiers externes en CRLF et produit une autre empreinte. Le second a conservé les octets LF et retrouvé l’empreinte initiale. Les 31 fichiers du candidat sont restés identiques dans les deux exports.
Ce résultat localise l’écart. Il ne permet pas d’affirmer que tout checkout Windows produirait une empreinte différente ou qu’un checkout LF serait refusé. Dans la configuration examinée, les trois fichiers externes expliquent la différence observée; les attributs du candidat stabilisent les autres entrées.
Séparer une comparaison exécutée d’un refus déduit
Les trois fichiers externes exportés en CRLF ne correspondaient plus aux empreintes SHA-256 épinglées pour le registre. Le code vérifie ces empreintes avant de charger cette dépendance. Il permet donc de déduire qu’une telle copie serait refusée en amont du calcul général.
Cette dernière conclusion est une inférence à partir du code et des comparaisons d’octets. Le contrôle d’admission n’a pas été exécuté sur une copie CRLF du registre. Les exports et leurs empreintes ont été mesurés; le refus attendu a été déduit. Les présenter sous le même statut ferait perdre une limite utile de la preuve.
Définir ce que l’empreinte identifie
Avant d’utiliser une empreinte comme condition d’autorisation, il faut préciser si elle représente les blobs Git, les fichiers présents sur disque ou un artefact produit par un build. Ces trois objets peuvent être reliés, mais leur égalité doit être vérifiée dans les conditions retenues.
Une vérification exploitable identifie les fichiers réellement lus, compare leurs octets, relève les attributs applicables et explique les transformations observées. Les dépendances externes doivent être examinées avec leurs propres règles. Cette précision rend un écart d’empreinte interprétable et évite de normaliser silencieusement des fichiers après leur approbation.
Provenance de l’étude
Les résultats proviennent de l’inventaire des 34 entrées, des comparaisons disque/blob et des deux exports conservés dans la revue du 15 octobre 2026. Les règles de conversion sont documentées par Git. La stabilité établie concerne les fichiers et configurations examinés.