possible infinite recursion in notmuch-cli

diff --git a/bb/b095848a2b2c2e6d840e813287a74b41d2ef66 b/bb/b095848a2b2c2e6d840e813287a74b41d2ef66
new file mode 100644 (file)
index 0000000..68221b9
--- /dev/null
+++ b/bb/b095848a2b2c2e6d840e813287a74b41d2ef66
@@ -0,0 +1,122 @@
+Return-Path: <dkg@fifthhorseman.net>\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 2A3E2431FAF\r
+       for <notmuch@notmuchmail.org>; Thu, 10 Oct 2013 15:51:23 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\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 iG9wR6QISDhj for <notmuch@notmuchmail.org>;\r
+       Thu, 10 Oct 2013 15:51:18 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+       by olra.theworths.org (Postfix) with ESMTP id 33CFC431FAE\r
+       for <notmuch@notmuchmail.org>; Thu, 10 Oct 2013 15:51:18 -0700 (PDT)\r
+Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98])\r
+       by che.mayfirst.org (Postfix) with ESMTPSA id CBCB6F984\r
+       for <notmuch@notmuchmail.org>; Thu, 10 Oct 2013 18:51:11 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+       id 83B85204C5; Thu, 10 Oct 2013 18:51:12 -0400 (EDT)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: notmuch mailing list <notmuch@notmuchmail.org>\r
+Subject: possible infinite recursion in notmuch-cli\r
+User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Thu, 10 Oct 2013 18:51:09 -0400\r
+Message-ID: <874n8ospsy.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha512; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\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: Thu, 10 Oct 2013 22:51:23 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hi notmuch folks--\r
+\r
+On oss-security recently, there was a discussion about recursive\r
+compression and the ability to create infinite loops.\r
+\r
+ id:20131010013106.GA29693@openwall.com\r
+\r
+After some discussion with amdragon on IRC, i believe that this is only\r
+relevant to notmuch when actively decrypting a message -- OpenPGP's\r
+ability to embed compression makes it possible to write a PGP/MIME\r
+message that is a quine: that is, when decompressed, it would expand to\r
+itself, which would send our parser into an infinite loop.\r
+\r
+Since we're not decrypting during indexing, only notmuch-show and\r
+notmuch-reply are probably affected by this problem. (but if someone\r
+implements indexing of encrypted messages, then we'd have to worry about\r
+this in the indexer as well)\r
+\r
+The simple and generalized solution would be to limit the recursive\r
+depth of our walk of the MIME tree; probably a large limit of something\r
+like 30 or 50 would not trigger any real-world problems, and would halt\r
+a runaway recursion well before most modern machines ran out of\r
+resources.\r
+\r
+A more targeted fix might be to just limit the number of recursive\r
+decryptions that happen, since the MIME spec does not appear to be\r
+capable of permitting other parts to provide both compression and\r
+nesting, which is the root of the problem.  However, it's possible that\r
+our MIME parsing ends up being more permissive than the specs, and is\r
+willing to try to interpret (for example) a gzip-compressed multipart/*\r
+or message/* part.=20=20\r
+\r
+So the simple/generalized solution is probably the right way to go.\r
+\r
+Sorry i don't have time to implement the fix myself right now, but i\r
+wanted to make sure the active coders in the project are aware of the\r
+issue.\r
+\r
+Regards,\r
+\r
+      --dkg\r
+\r
+references:\r
+\r
+ http://mumble.net/~campbell/blag.txt (see 2013-10-08)\r
+ http://www.openwall.com/lists/oss-security/2013/10/10/2\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.14 (GNU/Linux)\r
+\r
+iQJ8BAEBCgBmBQJSVy9dXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB\r
+NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcfRsQAIFmyQdi41nImeLcXj++Uv37\r
+A70y14mCeosYEt18WkGmWutb/13ZSPgtMqyF+mUNjxjVCdPeYDoBR0KQyLmz5R2K\r
+TGUwtVUppsvtRHQJhct2vZOf5m9024Yy01eFqs75Iy2DqTmktW9HjeZUXLoBYx/L\r
+mkO+QDx5sLGizWCKa8Cc8/fs67lScQe3mP/7eV1TopwEJxhVmZ2GymczDdmdvwhI\r
+PCmo+iSR5dK2r2NRYycyZBLVYUftvPCRk0J0jxHBgi8aN7FUWRWm9eFh6+xJ610N\r
+LCTaYhrZ7ba6a6KHYtRWk3ZMWb710uxsIwS7Tc/vvzHnWL5GpvnXzQ8H3V1NDnty\r
+1gfy3puA1OWFdiOwbxLX2jbPxGBz1ywwKXtzq3WmZfmo3JAhlpVdiMX8mc1b8RwD\r
+kghVoyhhwlRLa+ZzJFkgxUcu0uxepYBxK4BYb4F1PFBZl5UoU3GJoHYbq5CpsOXi\r
++gJbE19Q1kvRoKmKZqpl3DOQecDGSypJtZFkU4tvvIW5ZO0DK0G7xwA4JsnzHiMp\r
+zWJtlhq1+kcqDPg/rdW3exltdqWB8UiGyBk3Rw9U5EcrLqL4yeuMmiXpZPb3o8BR\r
+sqltEi8FStFJcXDrTscBo+U0kQelKGviLMRElex6WAxqabiecQxiQrkmL+Q18D2A\r
+O0iXvvJ3LuAzUGGmrSYv\r
+=48MT\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r