cisco / libsrtp

Library for SRTP (Secure Realtime Transport Protocol)
Other
1.19k stars 470 forks source link

Hash of v2.4.2 tarball has changed #638

Closed lionelnicolas closed 1 year ago

lionelnicolas commented 1 year ago

When building libsrtp, we are using sha512 to check tarball archive integrity.

Today when rebuilding our project dependencies, the check failed.

These are the "old" hashes:

sha256: 3b1bcb14ebda572b04b9bdf07574a449c84cb924905414e4d94e62837d22b628
sha512: 6e4805e6d34b2050a6f68f629b0b42356b1d27f2cbaa6cc6166e56957609c3d9aa6b723dcc674e5c74180d122d27badd2f9496639ccb1e0c210b9e1f7949d0e2

But today the hashes are:

sha256: 67e3685b6621640753369a99c963bcc7e4b0edb544fd4253f7570e1a75d70456
sha512: b1363ff9907400154bc5961052682636321b7721357dd8031073aaf10debfad3ec8d9cf2c8e1fcb2077092113d17ce2ff4c6223719ef399d3057497bd26a73a0

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 and meld 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

lionelnicolas commented 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.

lionelnicolas commented 1 year ago

https://github.com/keybase/client/issues/10800#issuecomment-375831096

lionelnicolas commented 1 year ago

https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/

pabuhler commented 1 year ago

Hi, glad that this has a good explanation and good to see that ome one is actually comparing hashes :)