{"id":106631,"date":"2023-02-03T18:48:10","date_gmt":"2023-02-03T16:48:10","guid":{"rendered":"https:\/\/prohoster.info\/?p=106631"},"modified":"2023-02-03T21:50:32","modified_gmt":"2023-02-03T19:50:32","slug":"sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","title":{"rendered":"Build system failures due to changes in archive checksums on GitHub","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
GitHub has changed the method of generating automatically created archives in .tar.gz and .tgz formats on release pages, which has led to changes in their checksums and widespread failures in automated build systems that verify the integrity of the downloaded archives from GitHub against previously saved checksums, such as those placed in package metadata or build scripts. <\/p>\n
Starting with the release of version 2.38, Git's toolkit has included a built-in implementation of gzip by default, allowing for unified support for this compression method across different operating systems and improving archive creation performance. GitHub adopted the change after updating the git version in its infrastructure. The problem arose because the compressed archives generated by the built-in gzip implementation based on zlib differ binary-wise from the archives created by the gzip utility, leading to differing checksums for archives generated by different git versions when executing the 'git archive' command. <\/p>\n
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. <\/p>\n
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. <\/p>\n
Git developers have not yet reached a resolution and are merely discussing possible actions. Options considered include reverting to the default use of the gzip utility, adding a --stable flag to maintain compatibility with old archives, binding the built-in implementation to a specific archive format, using the gzip utility for old commits and the built-in implementation for commits starting from a certain date, and ensuring format stability only for uncompressed archives. <\/p>\n
The complexity of making a decision is explained by the fact that reverting to an external utility call does not fully resolve the checksum immutability issue, 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 restores the old behavior by default (calling the external gzip utility) and uses the built-in implementation when the gzip utility is absent from the system. The patches also add a note in the documentation stating that the stability of 'git archive' output is not guaranteed and the format may change in the future. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"