On Fri, 27 Nov 2009 21:28:03 -0600, "Jeffrey C. Ollie" <jeff@ocjtech.us> wrote:
> Instead of including a private implementation of the SHA1 hash, use
> libgcrypt.  This means less code of our own to maintain and it will be
> easier to switch to a different hash function like SHA256.

I don't believe we have a significant code-maintenance burden with
libsha1.c. And as for different hash functions, the only use of sha-1 in
notmuch is as a fallback in the case of a message not including a
Message-ID header.

So I don't see it as important at all to try to remove this code.

> libgcrypt was chosen because it has a fairly simple API, it's well
> tested (it's used in gnutls and gnupg2), and it's licensed under the
> LGPL.

What might make more sense is an option to compile against an existing
library (if present) but not to introduce an error in the build if the
library is not present, (in which case just build the builtin libsha1.c
code).

But if that wouldn't solve the problem you were trying to solve, (to
actually remove libsha1.c), then maybe we don't need to do anything for
now?

-Carl