Изменения, внесенные на Github, оказались не такими, как ожидалось.
Недавно стало известно, что GitHub изменил метод генерации файлов Автоматически генерируемые «.tar.gz» и «.tgz» на страницах запуска.
Это изменение вызвало изменения контрольных сумм и массовые сбои в системах сборки автоматические, которые проверяют целостность файлов, загруженных с GitHub, по сравнению с ранее сохраненными контрольными суммами, например, помещенными в метаданные пакета или скрипты сборки.
Начиная с версии 2.38 Git, включено по умолчанию интегрированная реализация gzip, Это позволило унифицировать поддержку этого метода сжатия во всех операционных системах и повысить производительность создания файлов. GitHub принял это изменение после обновления версии git в своей инфраструктуре.
Сжатие по умолчанию для файлов Git недавно изменилось. В результате файлы, загруженные с GitHub, могут иметь разные контрольные суммы, даже если содержимое полностью не изменилось.
GitHub не гарантирует стабильность контрольных сумм для автоматически сгенерированных файлов. Они отмечены словами «Исходный код (zip)» и «Исходный код (tar.gz)» на вкладке «Версии». Если вам нужно полагаться на непротиворечивую контрольную сумму, вы можете загружать файлы непосредственно в GitHub Releases.
Они гарантированно не изменятся.
Проблема была в чем файлы сгенерированные таблетки по реализации gzip zlib build — это разные бинарники файлов, сгенерированных утилитой gzip, что приводит к разным контрольным суммам для архивов, созданных разными версиями git, при выполнении команды «git archive».
Следовательно, после обновления git на GitHub, на страницах релиза стали появляться немного другие файлы который не прошел проверку с указанными выше контрольными суммами.
Проблема проявилась в различных системах сборки, системах непрерывной интеграции и наборах инструментов для сборки пакетов из исходного кода. Например, было взломано около 5800 портов FreeBSD, исходники которых были скачаны с GitHub.
В ответ к первым жалобам на неудачи, Представители GitHub изначально отмечали, что контрольные суммы никогда не гарантируются. константы для файлов.
После того, как было показано, что для создания систем сборки, затронутых изменением, потребуется значительный объем работы для обновления метаданных в различных экосистемах, GitHub передумал, отменив изменение и вернувшись к старому методу генерации файлов.
Как и ожидалось, люди начали жаловаться. Первоначальный ответ сотрудника GitHub (и главного участника Git) Брайана М. Карлсон не совсем понял:
Я говорю, что политика никогда не была правильной, и мы никогда не гарантировали стабильные контрольные суммы для файлов, точно так же, как Git никогда этого не гарантировал. Я прошу прощения за то, что здесь что-то не работает, и в прошлом не было более четкого сообщения об этом, но наша политика не изменилась за более чем 4 года.
Git-разработчики они еще не приняли решение и только обсуждают возможные действия. Лас- Рассматриваемые варианты включают использование утилиты gzip. по умолчанию; добавление флага «–stable» для сохранения совместимости со старыми файлами; связать встроенную реализацию с отдельным форматом файла; использование утилиты gzip для старых коммитов и встроенной реализации для коммитов с определенной даты; гарантируя стабильность формата только для несжатых файлов.
Сложность решения объясняется тем, что возврат к вызову внешней утилиты не решает полностью проблему неизменности контрольной суммы, так как изменение внешней программы gzip также может вызвать изменение файла.
В настоящее время имеется набор исправлений для обзора, который возвращает поведение по умолчанию (вызов внешней утилиты gzip) и использует встроенную реализацию, когда утилита gzip отсутствует в системе. Патчи также добавляют в документацию примечание о том, что вывод «git archive» не гарантируется как стабильный и что формат может измениться в будущем.
В конце концов если вам интересно узнать об этом больше, вы можете проверить подробности в по следующей ссылке.