Сбои в системах сборки из-за изменения контрольных сумм архивов в 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