Názory k článku
Git 2.13 přidává obranu proti kolizi SHA-1

> O volbě hashovací funkce nikdy nemůže rozhodovat přispěvatel, to musí vždy udělat správce repository – jinak by to byla bezpečnostní díra

No, bezpečnostní díra samo o sobě asi ne, ale přinášelo by to komplikace. A souhlasím, že by to bylo nešťastné řešením.

Otázkou ale třeba je, jak moc automatizovaně se má přecházet. Nechat vše pod starou hashovací funkcí zní jako riziko, že spousta projektů nemigruje. Automatický převod na novou hashovací funkci zase zavání problémy s kompatibilitou, zejména pokud různí vývojáři budou mít různé verze Gitu… Není úplně sranda skloubit kompatibilitu, bezpečnost a automatický přechod.

Možná to dopadne tak, že v jedné verzi Gitu bude nová hashovací funkce pro ty, kdo si ji vyžádají, později bude automaticky pro nové repozitáře, později začne Git doporučovat přechod a po čase začne automaticky migrovat.

> staré commity budou dále dohledatelné i podle starých ID – které ale už nebudou mít funkci ID, ale jenom jakési poznámky

Takže by to fungovalo jako druhé id, jen by se preferovalo používání nového id. A vyžadovalo by to dva stromy, jeden sha1 a druhý s novou hashovací funkcí. Pokud by tu byl starý hash uložený jen jako poznámka, šlo by k libovolnému id commitu pod 40 hexaznaků vytvořit libovolný obsah repozitáře. Což by zde situaci oproti dnešku zhoršilo, dnes je potřeba vhodná kolize SHA1, což si klade jisté (nejen finanční) nároky.

> hash alg. bude určovat správce repa, co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?

To by nemusel být problém – podobná situace jako konflikt, akorát rešitelná vždy automaticky.

> chce zachovat 160 bitovou velikost hashe

Hmm, takže z id nebude jasné, jestli je nové nebo staré… Nabízí se zde downgrade attack, na druhou stranu by zde obyčejná kolize SHA1 nestačila – kolize napříč hashovacími funkcemi by nejspíš nebyla o nic jednodušší než nalezení preimage, což je oblast, kde se dnes drží nejen SHA1, ale i skoro všechny ostatní hashovací funkce, včetně MD5.

Kvůli decentralizaci si moc nedokážu představit, že hash alg. bude určovat správce repa
Pokud nebude hashovací algoritmus určovat správce repository, není potřeba nic měnit a můžeme zůstat u SHA-1. Vždyť celá ta změna se dělá kvůli tomu, že dnes by mohl nějaký zákeřný přispěvatel vytvořit dva různé commity se stejným hashem. Když necháte volbu hashovací funkce na přispěvateli, zákeřný přispěvatel si zvolí SHA-1 – a jsem tam, co dnes.

co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?
On by to ani správce repository dělat nemusel, prostě by si hash přepočítal sám. Ale jinak na tom nevidím nic divného – když někdo dává požadavek na přetažení, musí si zajistit, aby jeho požadavek navazoval na stav repository, do kterého chce commit přetáhnout. Když jsou konflikty v kódu, musí to dělat ručně – naproti tomu přeznačení commitů se udělá automaticky.

zachovat 160 bitovou velikost hashe
To je krátkozraké řešení. Délky hashovacích funkcí se postupně prodlužují, protože jak se postupně zvyšuje výpočetní výkon, dokážeme toho víc upočítat hrubou silou, i kdyby ta hashovací funkce jinak byla bezchybná. Takže za nějakou dobu se bude řešit, že 160 bitů je prostě málo entropie, ať je získáte jakkoli. Dá se to brát jako dočasný workaround – na SHA-1 už existuje postup prolomení, tak použijeme jinou hashovací funkci se stejně dlouhým výstupem. Ale trvalé řešení to není. Navíc tohle osekávání hashovacích funkcí je dost ošemetné – ty hashovací funkce na to nikdy nebyly navržené a testované, takže je to další potenciální vektor útoku. Zrovna SHA-2 mají i ořezané varianty, takže snad v tomto směru budou odolné – ale tyhle zásahy kryptologů–amatérů jsou nebezpečné.

Prozatím sha1 dostačuje
Záleží na tom, co se od gitovského repository vlastně požaduje. Já si taky myslím, že pokud někdo může v repository napáchat škody commitem s konfliktním hashem, může tam napáchat daleko větší škody commitnutím škodlivého kódu. Ale zaseknout se trvale na nebezpečné hashovací funkci je podle mne špatně. S SHA-1 je to podobné, jako s HTTPS – je zbytečné nutit uživatele neustále přemýšlet o tom, kde je „nebezpečná“ varianta dostačující a kde je potřeba použít něco bezpečného, když můžu všude používat ty bezpečné algoritmy a protokoly.

Ošetřit kolize se dá i jiným způsobem včetně podobných kontrol jako tady ve zprávičce.
To je rychlý hack, ne trvalé řešení. Pak jste pořád o krok za útočníky, na každý nový způsob vytváření kolizí musíte najít způsob jejich detekce a dodatečně je implementovat.

Co třeba podpis tagu? Neznám git přesně do detailů, ale pokud se jen podepíše commit id, mohlo by tudy jít omezeně škodit.

Je normální, že se formáty dat (souborové formáty, souborové systémy, protokoly) vyvíjejí. Může se tomu říkat třeba git2, ale vyhnout se tomu podle mne nejde (i kdyby se zůstalo u 160 bitů, objeví se později něco jiného).

Mimochodem, součástí gitového repository je i verze formátu repository, první verze byla 0, dnes se používá verze 1. Takže git na to je připraven.

máme ještě pár let čas
Záleží na tom, jestli ten problém vůbec chceme řešit. A pokud ano (já jsem pro), není důvod to odkládat a není důvod dělat to jen napůl.

Varianta, kdy tohle bude určovat správce repositáře akorát zanese neskutečný bordel do kompatibility gitu, tomu se chci vyhnout, stejně řada "správců" nechává vše výchozí.
Že o tom rozhoduje správce repozitáře jsme uváděl jako protiklad k tomu, že o použitém hashi rozhoduje přispěvatel. Tak to být nemůže, aby změna hashovací funkce měla smysl, musí o tom rozhodovat správce repozitáře. A technicky nezáleží na tom, zda to rozhodne konfigurací, nebo tím, zda použije git nebo git3.