GNU bug report logs - #20428
git-fetch does not always validate hash

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: tracker <at> debbugs.gnu.org
Subject: bug#20428: closed (git-fetch does not always validate hash)
Date: Fri, 01 May 2015 20:22:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 01 May 2015 22:21:52 +0200
with message-id <87lhh89hgf.fsf <at> gnu.org>
and subject line Re: bug#20428: git-fetch does not always validate hash
has caused the debbugs.gnu.org bug report #20428,
regarding git-fetch does not always validate hash
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
20428: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20428
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ricardo Wurmus <rekado <at> elephly.net>
To: bug-guix <at> gnu.org
Subject: git-fetch does not always validate hash
Date: Sun, 26 Apr 2015 15:13:16 +0200

I'm currently playing with the elogind package recipe and I'm
occasionally updating my clone of the elogind git repository.  Whenever
I do I update the value of "commit" in the package definition:

    (define-public elogind
      (let ((commit "18ee7abc9a"))
        (package
          (name "elogind")
          (version (string-append "219." commit))
          (source (origin
                    (method git-fetch)
                    (uri (git-reference
                          (url "http://git.elephly.net/software/elogind.git")
                          (commit commit)))
                    (sha256
                     (base32
                      "0lg8jgp9rl3wf9w2xfip87nx9zpjhm4js7x1z05744xiyfmvawp5"))))
          ;; ...
          (license license:lgpl2.1+))))

Upon rebuilding the package from a new commit I would expect the build
to fail with a hash validation error as I have not updated the hash yet.
However, the build procedure just continues.  I noticed that the git
checkout is still the very same as before I updated the value of
"commit".  I cannot seem to reliably force a new git checkout.

[Message part 3 (message/rfc822, inline)]

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 20428-done <at> debbugs.gnu.org
Subject: Re: bug#20428: git-fetch does not always validate hash
Date: Fri, 01 May 2015 22:21:52 +0200

Ricardo Wurmus <rekado <at> elephly.net> skribis:

> Upon rebuilding the package from a new commit I would expect the build
> to fail with a hash validation error as I have not updated the hash yet.
> However, the build procedure just continues.  I noticed that the git
> checkout is still the very same as before I updated the value of
> "commit".  I cannot seem to reliably force a new git checkout.

Indeed, origins compile to fixed-output derivations, meaning that these
are special derivations whose output is known in advance (rather, the
SHA256 is the output is known in advance.)  Thus, it doesn’t matter how
the derivation produces its result as long as its output has the correct
hash.

When you leave the ‘sha256’ unchanged, the daemon notices that there’s
already an item with this name and hash in the store, so it does
nothing.

This is expected behavior, though I understand this can be error-prone
here.

To avoid that, you could add a ‘file-name’ field to the origin that
includes the commit:

  (file-name (string-append name "-checkout-" commit))

Thus, if you change the commit without changing the hash, the daemon
will still want to build the origin (because of the changed name) and
will eventually complain about the hash mismatch.

Thanks,
Ludo’.

Previous Next

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