Last week we received four tickets about unusual checksum mismatches for distfiles that download automatically-generated tarballs from GitHub:
https://trac.macports.org/ticket/66796 (bsdmake) https://trac.macports.org/ticket/66804 (libgit2) https://trac.macports.org/ticket/66805 (rav1e) https://trac.macports.org/ticket/66822 (cargo-c) This appears to have been caused by a problem on GitHub that was resolved: https://github.blog/2023-02-01-github-availability-report-january-2023/ > January 30 18:35 UTC (lasting 7 hours) > > We upgraded our production Git binary with a recent version from > upstream. The updates included a change to use an internal > implementation of gzip when generating archives. This resulted in subtle > changes to the contents of the “Download Source” links served by GitHub, > leading to checksum mismatches. No content was changed. > > After becoming aware of the impact to many communities, we rolled back > the compression change to restore the previous behavior. > > Similar to the above, we are still investigating the contributing > factors of this incident, and will provide a more thorough update in > next month’s report. I've closed the tickets as fixed because GitHub resolved the problem by returning to the previous compression method. However if any commits were made that updated any ports that fetch from automatically-generated GitHub tarballs during the timeframe that GitHub was using the incorrect compression method (7 hours after? before? during? 20230130T183500Z) we may have mirrored files generated with the wrong compression method, and now that the problem has been fixed users might encounter checksum mismatches if they fetch from GitHub instead of our mirror; we should identify and fix any such ports. For example, terragrunt-0.43 may have been affected when this change was committed on 20230130T223341Z: https://github.com/macports/macports-ports/commit/1100bde6eb3e1dc420a36675c39e46f821a2f41f but it has subsequently been updated to a newer version so it's no longer affected.
