GitHub autogenerated tarballs not considered stable

Question

GitHub autogenerated tarballs not considered stable

palmskog opened this issue a year ago · comments

Due to GitHub changing compression approach on Jan 30, 2023, every auto-generated GitHub hosted tarball now has a different checksum. The archive content is the same.

The following is GitHub's message to anyone affected by this, like us:

GitHub doesn't guarantee the stability of checksums for automatically generated archives. If you need to rely on a consistent checksum, you may upload archives directly to GitHub Releases.

So it seems we have to both (1) ensure checksums are refreshed for all GitHub tarballs in the archive and (2) ensure that only stable archives are used in packages going forward...

Karl Palmskog · Answer 1 · Tue Jan 31 2023 06:23:36 GMT+0800 (China Standard Time)

If anyone is looking for a workaround, the following may be used:

opam install <package> --no-checksums

@erikmd maybe we can use this by default in the Coq Docker? Unless checksums get rolled back (unlikely) this will take the whole OCaml and Coq ecosystem some time to work around.

Karl Palmskog · Answer 2 · Tue Jan 31 2023 06:38:22 GMT+0800 (China Standard Time)

GitHub may be in the process of reverting the change:

We're sorry for the breakage, we're reverting the change, and we'll communicate better about such changes in the future (including timelines).

Karl Palmskog · Answer 3 · Tue Jan 31 2023 16:35:38 GMT+0800 (China Standard Time)

From what I can tell, GitHub has now rolled back the tarball checksum changes. But the central problem remains in the long term: autogenerated GitHub tarballs are probably not trustworthy for preservation of code in the OCaml and Coq ecosystem.

Lasse Blaauwbroek · Answer 4 · Tue Feb 21 2023 04:32:57 GMT+0800 (China Standard Time)

I just saw that an official request for feedback on this problem was opened: community/community#46034
Could be a good idea to add Coq's or OCaml's usecase there.

Lasse Blaauwbroek · Answer 5 · Fri Feb 24 2023 04:09:49 GMT+0800 (China Standard Time)

https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/

Yves Bertot · Answer 6 · Fri Feb 24 2023 17:29:27 GMT+0800 (China Standard Time)

What I understand from reeding this link is that the problem needs to be handled by opam. A solution that comes to mind is to hash, not on the compressed archive, but on the uncompressed one (or any result given by a chosen filter).

Enrico Tassi · Answer 7 · Sat Feb 25 2023 04:53:10 GMT+0800 (China Standard Time)

Opam could hash the uncompressed, and be future proof. But we have a lot of packages which declare the hash of the compressed archive. For these we would need some automation to update the hash, once opam understands the new hashing schema.