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