bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail

[Leo Famulari <leo@famulari.name>]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On Mon, Oct 02, 2017 at 04:57:38PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Leo Famulari <leo@famulari.name> skribis:
> 
> > I contacted GitHub about this issue a few weeks ago and they said that:
> >
> > 1) They do not guarantee bit-reproducibility of the snapshots they
> > generate automatically for each release tag, and they wish that people
> > would not rely on them as we do. However, since people *are* relying on
> > them, they are discussing this issue internally.
> 
> Oh?!  Then we’re in trouble.

I wonder, are there really that many affected packages? My sense is that
most GitHub-hosted projects offer their own release tarballs in addition
to the problematic auto-generated snapshots, and we tend to prefer the
upstream-provided tarballs in this case.

We'd need to survey our package sources to know what sort of reaction is
most appropriate.

In general, we should try to make Guix as resilient as possible to
unstable upstream sources, since the problem is not limited to GitHub.

> Perhaps we should start using ‘git-fetch’ more, with Software Heritage
> as a fallback content-addressed mirror?  Though again the difficulty is
> that SWH uses Git’s method to hash directory contents, so we’d end up
> having to provide both a Nix hash and a Git hash in ‘origin’.  :-/

And the Git hashes will change from SHA1 to SHA256 sooner or later, and
SHA1 hashes will become less reliable as CPUs get faster (collision
attacks), compounding the problem...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]