Closed lionelnicolas closed 1 year ago
Hmm forget that, I just had the same issue with https://github.com/microsoft/mimalloc where our checksum didn't matched.
And just FYI, using the two above tarballs, I've just gunzip
them, and their tar
archive has the same checksum.
#~ sha512sum *
f95533da2f9b944ba9b49f2c513e02d202d7587d97685ee9a0500d0baca6205fbcecf9c32f67e5fe8b4cb8eb188ef2b47a1be4b8a884a81bfc2d2c5653b668ee v2.4.2.current.tar
f95533da2f9b944ba9b49f2c513e02d202d7587d97685ee9a0500d0baca6205fbcecf9c32f67e5fe8b4cb8eb188ef2b47a1be4b8a884a81bfc2d2c5653b668ee v2.4.2.original.tar
So it looks like something changed on GitHub's gzip implementation.
Hi, glad that this has a good explanation and good to see that ome one is actually comparing hashes :)
When building
libsrtp
, we are usingsha512
to check tarball archive integrity.Today when rebuilding our project dependencies, the check failed.
These are the "old" hashes:
But today the hashes are:
It looks like lots of project are using those "old" hashes too:
From what I can see the v2.4.2 tag haven't been moved, and to me the tarballs provided here are generated by GitHub.
I've compared the original archive and the new one. The tarball file size is different, but according to
diff
andmeld
the content seems to be exactly the same.Do you know what could cause this ? Did you changed something recently ? (like deleted then re-created the git tag?)
If that's helpful, the last time we build
libsrtp
the check succeed. It was on 2022-01-18.My guess would be that GitHub rolled out a change on tar/gzip handling, and if that's the case, they should expect a storm of
chore: update someproject tarball hash
commits :upside_down_face:For reference, here are the two tarballs:
v2.4.2.original.tar.gz v2.4.2.current.tar.gz