On Sat, Nov 28, 2009 at 12:43 AM, Carl Worth <cworth at 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