GitHub has modified the method of generating automatically created Ā«.tar.gzĀ» and Ā«.tgzĀ» archives on release pages, resulting in changes to their checksums and widespread failures in automated build systems that verify the integrity of downloaded archives from GitHub against previously saved checksums, such as those stored in package metadata or build scripts.
Starting from version 2.38, Git's toolset includes a built-in implementation of gzip by default, which standardizes support for this compression method across different operating systems and improves the performance of archive creation. GitHub adopted this change following the git version update in its infrastructure. The issue arose because the compressed archives generated by the built-in gzip implementation based on zlib are binary different from the archives created by the gzip utility, leading to checksum differences for archives created by different git versions when executing the Ā«git archiveĀ» command.
As a result, after the git update on GitHub, slightly different archives began to be delivered on release pages that do not pass checks with the old checksums. This issue manifested in various build systems, continuous integration systems, and tools for building packages from source code. For instance, the build of about 5800 FreeBSD ports, whose source code was retrieved from GitHub, was disrupted.
In response to the initial complaints about these failures, GitHub representatives initially stated that permanent checksums for archives were never guaranteed. After it was demonstrated that restoring the functionality of the affected build systems would require substantial work to update metadata across various ecosystems, GitHub representatives changed their stance, canceled the modification, and reverted to the old archive generation method.
Git developers have yet to reach a decision and are only discussing possible actions. Options considered include reverting to the default use of the gzip utility; adding a "āstable" flag to maintain compatibility with older archives; binding the built-in implementation to a separate archive format; using the gzip utility for old commits and the built-in implementation for commits starting from a certain date; guaranteeing format stability only for uncompressed archives.
The difficulty in making a decision is explained by the fact that reverting to calling an external utility does not fully resolve the issue of the immutability of checksums, as changes in the external gzip program could also lead to changes in the archive format. Currently, a set of patches has been proposed for review that returns the old behavior (calling the external gzip utility) by default and uses the built-in implementation when the gzip utility is not present on the system. The patches also add documentation stating that the output stability of "git archive" is not guaranteed and the format may change in the future.
Source: opennet.ru
