GNU bug report logs - #28659
Content-addressed mirror is not used upon invalid hash

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 28659 <at> debbugs.gnu.org
Subject: bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Date: Mon, 02 Oct 2017 17:09:39 +0200

Hello,

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

> As reported by laertus on irc[0]: guix pull on 0.13 without substitutes fails

I just checked and we do have substitutes, but I understand it doesn’t
help here.

>       guix pull
>
>     Starting download of /tmp/guix-file.3r6cH0
>     From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>      ….tar.gz                                   5.7MiB/s 00:02 | 13.6MiB transferred
>     unpacking '/gnu/store/sginfwnrcfqn1far31gmzlaffd8xlxyy-guix-latest.tar.gz'...
>
>     Starting download of /gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz
>     From https://github.com/libgit2/libgit2/archive/v0.25.1.tar.gz...
>     following redirection to `https://codeload.github.com/libgit2/libgit2/tar.gz/v0.25.1'...
>      v0.25.1                                     6.1MiB/s 00:01 | 4.1MiB transferred
>     output path `/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz' should have sha256 hash `1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s', instead has `0ywcxw1mwd56c8qc14hbx31bf198gxck3nja3laxyglv7l57qp26'

What’s sad here is that we do have the right tarball at:

  https://mirror.hydra.gnu.org/file/libgit2-0.25.1.tar.gz/sha256/1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s

The problem is that the hash check is performed by guix-daemon itself,
not by “guix perform-download”.  So when guix-daemon diagnoses a hash
mismatch, it’s too late and we cannot try again and use the
content-addressed mirror.

A crude but helpful fix would be to have perform-download compute the
hash by itself and act accordingly.  It’s crude because that means that
we’d be computing the hash twice: once in ‘guix perform-download’ and a
second time in guix-daemon.  For archives below ~20 MiB it’s probably OK
though.

Thoughts?

In the future, with the daemon written in Guile, it’s one area where we
could achieve better integration and coordination among the various
pieces.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.