From: micah anderson <micah@riseup.net>
To: Carl Worth <cworth@cworth.org>, "Jeffrey C. Ollie" <jeff@ocjtech.us>,
	Not Much Mail <notmuch@notmuchmail.org>
In-Reply-To: <87zl67rwxi.fsf@yoom.home.cworth.org>
References: <1259378883-9181-1-git-send-email-jeff@ocjtech.us>
	<87zl67rwxi.fsf@yoom.home.cworth.org>
Date: Fri, 08 Jan 2010 15:43:52 -0500
Message-ID: <871vi0ba46.fsf@lillypad.riseup.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
Subject: Re: [notmuch] [PATCH] Use libgcrypt for hashing.
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Nov 2009 22:22:01 -0800, Carl Worth <cworth@cworth.org> wrote:
> 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.
>=20
> 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.
>=20
> So I don't see it as important at all to try to remove this code.

Its good that this is not a burden to maintain for the notmuch project,
even better that Mikhail, the libsha1 maintainer, is currently active in
this project and has volunteered to maintain the in-tree copy.=20

However, the problem that has been raised is about the code-maintenance
burden that distributions face. In fact, this is not an unique problem
to notmuch, if it was it wouldn't be such a big deal. The reality is
that the more projects which cargo-cult around 'convenience copies' of
code, the more of a burden is placed on the distributors.

In some ways, the notmuch project and the role of distributors are at
cross-purposes on this issue, each side has an argument that makes sense
From=20their individual perspectives.

> > 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.
>=20
> 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).

This makes the most sense, and resolves the issue in a way that both
sides of the issue benefit!

> 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?

I think from a distribution point-of-view, if you are providing a
mechanism to link against libgcrypt, while still maintaining this
embedded code-copy for convenience's-sake, actually removing libsha1.c
is not so necessary. It does mean an exception must be noted on the
distribution side that indicates that although this code exists, its not
being used, but that is a negligible burden.

micah

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJLR5kJAAoJEIy/mjIoYaeQ/jsQAIH0k3/le6Rm9tFarHPma7BO
lRmz//oAFqPL/6lyb4C2vFMEBO0c3IK7TJc42NGxzkXg/uXQ0CnakHxA3hp+sBoW
dvjSJTUReakGKzl/m0SMDs7lFc/hkOTMsPlp0tu7d1JCUSgJcnVQ3asom3u7Yb35
gE8gTP+D3vu/NBT1/fG7mCYUBYcqZCk7gRJghLdpcK/XsZyi1LN7Wrqvc5vk1DWE
JWBCnI0jIBn0vvHY0F1SP22qbincrzQY8XO+cKD8q7fe6oVrN6aRZxeLIxPhgzhw
yYRzxMXvyJb537JnhTheOLF7pjaP6Y6bc61bGQPvzpXLF9OYBjlRmClpyg68uXY9
OZ+MC1I6y5nH1wPyqgJf9dVbv4BzPlVrZQo1kjw9HhyONGT5PlVvDoZtsxwoxmt9
4s7H74pmPTgpohNGOe5u0HsQHWv2++qHyBH7k1gbTM5Iz9Sgpdv7tQRd/ERgLdRl
Z8FcHkO6c02oCQSGZCRYV/BqvZS/pRRG9aGmC2US9sWHHLQScq0Z+PJuuc2ld6rr
6JwBxCwOR8vuFG2jqe3NjEeOHLQ74KAZNVTfuehv7rEXD/McUaSnFPajQiY57mNR
gAATyqyW99oFxDNVElyBxpt5Vxu6Cxx7RSwPCPTqLdWvUZ7CuIFya1MS9U+1h0Cu
NT+Bw6fSAjZEtZb14tYk
=DqQc
-----END PGP SIGNATURE-----
--=-=-=--