Сривове в системите за сборка поради промяна на контрольни суми на архиви в GitHub

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