GitHub промени метода за генериране на автоматично генерираните архиви «.tar.gz» и «.tgz» на страниците с версии, което доведе до промяна на техните контролни суми и масови повреди в автоматизирани системи за сборка, които за потвърждаване на целостта извършват сверка на архивите, изтеглени от GitHub, с преди това запазени контролни суми, например, публикувани в метаданни на пакетите или в сценарии за сборка.
Започвайки от версия 2.38, в инструментариума Git по подразбиране е включена вградена реализация на gzip, която позволи унифицирането на поддръжката на този метод за компресия в различни операционни системи и повишаване на производителността при създаване на архиви. GitHub прие промяната след обновление на версията на git в своята инфраструктура. Проблемът се дължи на факта, че компресираните архиви, генерирани от вградената реализация на gzip на базата на zlib, бинарно се различават от архивите, създадени от утилитата gzip, което доведе до различие в контролните суми на архивите, създадени с различни версии на git при изпълнение на командата «git archive».
Съответно, след обновлението на git в GitHub, на страниците с версии започнаха да се предоставят леко различни архиви, които не преминават проверката по старите контролни сум и. Проблемът се прояви в различни системи за сборка, системи за непрекъсната интеграция и в инструментариуми за сборка на пакети от сорс код. Например, наруши се сборката на около 5800 порта FreeBSD, чиито сорс кодове се изтегляха от GitHub.
В отговор на първоначалните оплаквания относно възникналите проблеми, представителите на GitHub в началото посочиха, че постоянните контролни суми за архивите никога не са били гарантирани. След като стана ясно, че за възстановяване на работоспособността на системите за сборка, засегнати от промяната, ще е необходима колосална работа по обновление на метаданните в различни екосистеми, представителите на GitHub промениха мнението си, отмениха промяната и върнаха стария метод за генериране на архиви.
Разработчиците на Git все още не са намерили решение и само обсъждат възможни мерки. Бяха разгледани варианти като възстановяване на стандартната употреба на утилита gzip; добавяне на флага «—stable» за запазване на съвместимостта със стари архиви; свързване на вградената реализация с отделен формат на архива; използване на утилитата gzip за стари комити и вградената реализация за комити от определена дата нататък; гарантиране на стабилността на формата само за несжати архиви.
Сложността при вземането на решение е обяснена от факта, че възстановяването на извикването на външна утилита не решава напълно проблема с неизменността на контролни суми, тъй като измененията във външната програма gzip също могат да доведат до промяна на формата на архива. В момента за преглед е предложен набор от пачове, който възстановява стандартното поведение (извикване на външна утилита gzip) и използва вградената реализация при липса на утилита gzip в системата. Пачовете също добавят в документацията упоменаването, че стабилността на изхода „git archive“ не е гарантирана и форматът може да бъде променен в бъдеще.
Източник: opennet.ru
