[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20428: git-fetch does not always validate hash

From: Ludovic Courtès
Subject: bug#20428: git-fetch does not always validate hash
Date: Fri, 01 May 2015 22:21:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ricardo Wurmus <address@hidden> 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

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]