dev · · 21:02 · 2 min de citit
Planul Git 3.0 de a folosi SHA-256 implicit, criticat de Scott Chacon
Scott Chacon susține că planul Git de a trece implicit la SHA-256 pentru noi repository-uri în versiunea 3.0 este o greșeală costisitoare care va afecta instrumentele și referințele existente. Deși Git recunoaște slăbiciunile SHA-1, proiectul afirmă că tranziția va avea loc doar când ecosistemul va fi pregătit, fără o dată de lansare fixă.
Scott Chacon a ridicat semne de întrebare cu privire la tranziția propusă de Git către utilizarea SHA-256 ca hash implicit pentru noi repository-uri în Git 3.0, considerând-o o greșeală costisitoare și semnificativă. Argumentul său principal este că, deși algoritmul curent, SHA-1, este cunoscut ca fiind criptografic slab, nu a fost demonstrată nicio coliziune practică în multitudinea de repository-uri Git existente. Problema majoră a adoptării implicite a SHA-256, conform lui Chacon, este că aceasta va invalida toate hash-urile SHA-1 existente, făcând nefuncționale URL-urile, referințele de commit în sisteme de urmărire a bug-urilor și alte instrumente care se bazează pe ID-ul SHA-1 de 40 de caractere. El subliniază că multe implementări de biblioteci Git nu suportă în prezent complet SHA-256, amplificând potențialul de perturbare.
Chacon propune o abordare alternativă: verificarea integrității fără a modifica convenția fundamentală de denumire a obiectelor. El sugerează încorporarea checksum-urilor SHA-256 în obiecte semnate, alături de numele SHA-1 existente. Această metodă ar permite o verificare mai puternică a hash-ului fără a fragmenta ecosistemul. Testele sale demonstrează că procesarea hash-ului pentru structuri de directoare mari este fezabilă din punct de vedere computațional, o structură de 35GB durând aproximativ 5 secunde. El citează `git-evtag` din 2015 ca dovadă anterioară pentru acest concept. Documentația proiectului Git recunoaște vulnerabilitățile criptografice ale SHA-1, menționând evenimente precum atacurile SHAppening și SHAttered, și a identificat SHA-256 ca succesor încă de la sfârșitul anului 2018. Cu toate acestea, proiectul s-a angajat să amâne comutarea implicită până când întregul ecosistem, inclusiv bibliotecile, platformele de găzduire și aplicațiile terțe, va fi complet pregătit.
Designul de tranziție a funcției hash a proiectului Git vizează interoperabilitatea, permițând repository-urilor să migreze în ritmul propriu și menținând tabele de translatare bidirecționale între obiectele SHA-1 și SHA-256 în timpul tranziției. Operațiunile de rețea precum push și fetch sunt concepute pentru a converti obiectele. Cu toate acestea, rămân limitări, în special în ceea ce privește clonările superficiale și alternativele între repository-uri care utilizează formate de hash diferite. Pentru dezvoltatori, impactul imediat este minim, deoarece Git 3.0 nu are o dată de lansare, iar repository-urile existente vor rămâne SHA-1. Recomandările cheie sunt testarea instrumentelor actuale pe repository-uri SHA-256, auditarea oricăror sisteme care presupun un ID de 40 de caractere și luarea în considerare a alternativei lui Chacon cu checksum-uri semnate, dacă verificarea integrității este preocuparea principală, în loc să se aștepte un număr de versiune legat de pregătirea ecosistemului.
$ sursa --originală
dev.to
Rezumat realizat de Sudofeed pe baza articolului original. Drepturile asupra conținutului aparțin sursei originale.