<div dir="auto">Here is an issue¬†<div dir="auto"><a href="https://github.com/easybuilders/easybuild-easyconfigs/issues/5151">https://github.com/easybuilders/easybuild-easyconfigs/issues/5151</a> with a lot of other referenced issues, about the one time I remember this happening. Folks in the bazel community reference this issue a lot since the default behavior of folks is to use the generate tarball URL and pin those shas in their builds.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 23, 2021 at 8:22 AM Arthur Gautier <<a href="mailto:baloo@superbaloo.net">baloo@superbaloo.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Oct 23, 2021 at 9:52 AM Martin Monperrus<br>
<<a href="mailto:martin.monperrus@gnieh.org" target="_blank">martin.monperrus@gnieh.org</a>> wrote:<br>
><br>
> Dear all,<br>
><br>
> FYI, Github's autogenerated release tarballs are not deterministic (see discussion on keybase, and Bitcoin-core release warning).<br>
><br>
> Does anybody have good connections at Github to get this fixed?<br>
><br>
> Best regards,<br>
><br>
<br>
I believe this is one of the reasons the kernel releases only sign the<br>
tar itself and not the compressed version (also makes it future-proof<br>
as they can switch to a new compression algorithm).<br>
<br>
The tar itself looks to be stable, NixOS checks for every asset of its<br>
build and compares the hash of the extracted tar. As far as I know,<br>
they seem to be stable.<br>
<br>
Best,<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Keith Smiley<br></div>