git-annex's configure step finds hashalot's /usr/sbin/sha256, /usr/sbin/sha384, and /usr/sbin/sha512 executables and mistakes them for sha256sum, sha384sum, and sha512sum and prefers them over the correct executables.  Hashalot is not compatible, but the build does not fail producing a broken git-annex executable which tries to use hashalot's programs instead of the appropriate shaXXXsum program and is non-functional.

Hashalot can be found at: <http://www.paranoiacs.org/~sluskyb/hacks/hashalot/>


What steps will reproduce the problem?

Compile with hashalot's programs in the path.


What is the expected output? What do you see instead?

Expect to see configure output:

[...]
<pre>
  checking sha1... sha1sum
  checking sha512... sha512sum
  checking sha224... sha224sum
  checking sha384... sha384sum
  checking sha256... sha256sum
</pre>
[...]


Instead I see configure output:

[...]
<pre>
  checking sha1... sha1sum
  checking sha512... sha512
  checking sha224... sha224sum
  checking sha384... sha384
  checking sha256... sha256
</pre>
[...]


What version of git-annex are you using? On what operating system?

I am using 3.20120605, but have checked out the latest GIT and confirmed the bug is still there.


Please provide any additional information below.

This is not a runtime bug, only compile time.  Uninstalling Hashalot or simply removing it from the PATH is enough to work around this bug.  The bug is, however, frustrating because at first glance there appears to be no problem.  However any functions of git-annex which use the affected SHA hash functions will fail with the resulting executable and the failure gives no clear indication of why.

I found this bug on Gentoo when I installed git-annex on a system which already had hashalot installed.  In the case of Gentoo, git-annex is compiled with hashalot's executables in the path, but normal users don't have /usr/sbin/ in their path so git-annex just fails to find the executable.  If you put hashalot in the path, then git annex still fails to work as hashalot is not a replacement for sha1sum and friends.

It may be enough to just prefer sha???sum over sha??? if they both exist.

> Grr. There is no consistency across unixes as to the names of these
> programs and now something is installing shaN commands that don't
> generate a checksum?!
> 
> Ok, fine, configure now checks that the program it finds outputs a known
> good checksum. [[done]] --[[Joey]]