From: Carl Worth <cworth@cworth.org>
To: Jeffrey Ollie <jeff@ocjtech.us>, Mikhail Gusarov <dottedmag@dottedmag.net>
In-Reply-To: <935ead450911272141g7ecf917ds1547fc95da3178aa@mail.gmail.com>
References: <1259378883-9181-1-git-send-email-jeff@ocjtech.us>
	<87ws1be35o.fsf@vertex.dottedmag>
	<935ead450911272141g7ecf917ds1547fc95da3178aa@mail.gmail.com>
Date: Fri, 27 Nov 2009 22:43:07 -0800
Message-ID: <87ws1brvyc.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: Not Much Mail <notmuch@notmuchmail.org>
Subject: Re: [notmuch] [PATCH] Use libgcrypt for hashing.
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Nov 2009 23:41:40 -0600, Jeffrey Ollie <jeff@ocjtech.us> wrote:
> That's great that you're willing to take on the task, but as I do a
> lot of work for Fedora I tend to think about these things differently.
>  It's not about a project here or there making private copies of some
> code, it's about tracking down *all* of the projects that have private
> copies of the code when something goes wrong, especially when there
> are security implications.

Hi Jeffrey,

Have you actually *looked* at the implementation of libsha1.c that we
have in notmuch? I can't say with 100% certainty that it's free of any
buffer overruns, but I can see that it's not doing any memory allocation
nor network communication. So there are entire classes of security
problems, (such as have afflicted libraries in your examples), that just
aren't present here.

And as for security compromises due to a bug in the cryptographic nature
of this function---well, notmuch isn't even *using* SHA-1 for any secure
purpose.

The actual functionality that we need here is *so* small that I am
unwilling to introduce a required dependency on any library as large as
libcrypt. I mean, look at the actual sizes we're talking about

$ size lib/notmuch.a
   text	   data	    bss	    dec	    hex	filename
   6774	      0	      0	   6774	   1a76	libsha1.o (ex lib/notmuch.a)
   2372	      0	      4	   2376	    948	message-file.o (ex lib/notmuch.a)
    756	      0	      0	    756	    2f4	messages.o (ex lib/notmuch.a)
    405	      0	      0	    405	    195	sha1.o (ex lib/notmuch.a)
    406	      0	      0	    406	    196	tags.o (ex lib/notmuch.a)
    842	      0	      0	    842	    34a	xutil.o (ex lib/notmuch.a)
  15834	    100	      1	  15935	   3e3f	database.o (ex lib/notmuch.a)
   2826	      0	      4	   2830	    b0e	index.o (ex lib/notmuch.a)
  11834	      0	      4	  11838	   2e3e	message.o (ex lib/notmuch.a)
   7042	      0	      0	   7042	   1b82	query.o (ex lib/notmuch.a)
   2553	      0	      0	   2553	    9f9	thread.o (ex lib/notmuch.a)

$ size /usr/lib/libgcrypt.so.11.5.2=20
   text	   data	    bss	    dec	    hex	filename
 466236	   8424	    748	 475408	  74110	/usr/lib/libgcrypt.so.11.5.2

You can see that libgcrypt is 7 times the size of all of libnotmuch.a
combined.

Now, if somebody wanted to maintain libsha1 inside a distribution like
Debian, say, then I'd be happy to link against that version rather than
a locally compiled version. And like I said earlier, if people would
rather link against a large cyptographic library for this one tiny
function, then we could arrange that too, but I don't think that
justifies dropping this code from notmuch and introducing a hard
dependency.

=2DCarl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLEMZ76JDdNq8qSWgRAmLdAKCbnadhkGWuPzRX/04wKJQ7A3CcLACfZ5Sh
h5zVHJHjqPWdcEloc9/6OL0=
=8CoD
-----END PGP SIGNATURE-----
--=-=-=--