Re: [notmuch] [PATCH] Use libgcrypt for hashing.
authorCarl Worth <cworth@cworth.org>
Sat, 28 Nov 2009 06:43:07 +0000 (22:43 +1600)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:35:46 +0000 (09:35 -0800)
8f/437b1e61b92bc27dec4711f7b52f75d349d284 [new file with mode: 0644]

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