MIME-Version: 1.0
In-Reply-To: <87ws1brvyc.fsf@yoom.home.cworth.org>
References: <1259378883-9181-1-git-send-email-jeff@ocjtech.us>
	<87ws1be35o.fsf@vertex.dottedmag>
	<935ead450911272141g7ecf917ds1547fc95da3178aa@mail.gmail.com>
	<87ws1brvyc.fsf@yoom.home.cworth.org>
Date: Sat, 28 Nov 2009 01:38:34 -0600
Message-ID: <935ead450911272338y2c70dc9che9de20a53bdec77d@mail.gmail.com>
From: Jeffrey Ollie <jeff@ocjtech.us>
To: Carl Worth <cworth@cworth.org>
Content-Type: text/plain; charset=UTF-8
Cc: Not Much Mail <notmuch@notmuchmail.org>
Subject: Re: [notmuch] [PATCH] Use libgcrypt for hashing.
Precedence: list

On Sat, Nov 28, 2009 at 12:43 AM, Carl Worth <cworth@cworth.org> wrote:
>
> 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.

I've looked at the code, if only briefly.  But you're wrong that the
code doesn't do any "network communication" - we feed libsha1 hostile
data every time we take the hash of a message.

> 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.

>From a distributor's point of view, it doesn't matter what you use the
code for, it only matters that it has the bug and someone has to spend
the time to track down all of the copies of the code and replace the
code with a fixed version.  If the code is confined to one shared
library it's trivial to update the shared library, if the code has
been copied to N packages, it's at least N times the work to verify
that all of those packages get updated.

> 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

If libgcrypt were some obscure library that wasn't already packaged up
by your favorite distribution or took up hundreds of megabytes of RAM
and/or disk you might have a point.  But the fact is that it *doesn't
matter* how big libgcrypt is because we essentially get it for free -
I'd bet that libgcrypt is already installed on most people's systems.
As a test I tried to remove libgcrypt from my laptop - if I actually
had gone though with it I would have crippled my system because things
like the X server and the package manager depend (albeit indirectly)
on it.

> 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.

Given Debian's reputation for packaging the kitchen sink I'm surprised
that it doesn't already.  Fedora tends not to package libraries unless
there is an application that is going to make use of it...

-- 
Jeff Ollie