GitHub 改变了在发布页面上自动生成“.tar.gz”和“.tgz”档案的方式，这导致其校验和发生变化，并导致自动构建系统（该系统将从 GitHub 下载的档案与之前的档案进行检查以确认完整性）发生大规模故障。 . 存储的校验和，例如，放置在包元数据或构建脚本中。
从版本 2.38 开始，Git 工具包默认包含 gzip 的内置实现，这使得跨操作系统统一对此压缩方法的支持并提高存档创建性能成为可能。 GitHub 在更新其基础设施中的 git 版本后发现了这一变化。 该问题是由于内置的基于 zlib 的 gzip 实现生成的压缩档案是二进制的，与 gzip 实用程序创建的档案不同，这导致在执行以下命令时，不同版本的 git 创建的档案的校验和不同。 “git 存档”命令。
因此，在 GitHub 中更新 git 后，发布页面上开始显示略有不同的存档，该存档未通过使用旧校验和的验证。 这个问题体现在各种构建系统、持续集成系统和从源代码构建包的工具中。 例如，大约 5800 个 FreeBSD 端口的汇编被破坏，其源代码是从 GitHub 下载的。
为了回应有关这些故障的最初投诉，GitHub 最初提到了这样一个事实：档案的永久校验和从未得到保证。 在发现需要进行大量工作来更新各个生态系统中的元数据以恢复受影响的构建系统的功能后，GitHub 代表改变了主意，恢复了更改并返回了生成档案的旧方法。
Git 开发人员尚未做出决定，只是讨论可能的行动。 考虑的选项包括恢复使用默认的 gzip 实用程序； 添加“--stable”标志以保持与旧档案的兼容性； 将内置实现链接到单独的存档格式； 对旧提交使用 gzip 实用程序，对从特定日期开始的提交使用内联实现； 仅保证未压缩档案的格式稳定性。
做出决定的困难在于，回滚到对外部实用程序的调用并不能完全解决校验和不变性的问题，因为外部 gzip 程序的更改也可能导致存档格式的更改。 目前，已提出一组补丁供审查，默认情况下返回旧行为（调用外部 gzip 实用程序），并在系统中没有 gzip 实用程序的情况下使用内置实现。 这些补丁还在文档中添加了一个提示，即无法保证“git archive”输出的稳定性，并且格式将来可能会发生变化。
来源： opennet.ru