6a/b983c6b5f7a0036a96c1ad0720db3c10d6c81c

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 16DD7431FB6\r
   6         for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 14:29:21 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 2.438\r
  10 X-Spam-Level: **\r
  11 X-Spam-Status: No, score=2.438 tagged_above=-999 required=5\r
  12         tests=[DNS_FROM_AHBL_RHSBL=2.438] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id j+60FvmVBXvh for <notmuch@notmuchmail.org>;\r
  16         Sat, 17 Jan 2015 14:29:17 -0800 (PST)\r
  17 Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155])\r
  18         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id DE731431FAF\r
  21         for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 14:29:17 -0800 (PST)\r
  22 Received: from remotemail by yantan.tethera.net with local (Exim 4.80)\r
  23         (envelope-from <david@tethera.net>)\r
  24         id 1YCbrp-0002n3-2d; Sat, 17 Jan 2015 18:29:17 -0400\r
  25 Received: (nullmailer pid 26281 invoked by uid 1000); Sat, 17 Jan 2015\r
  26         22:29:11 -0000\r
  27 From: David Bremner <david@tethera.net>\r
  28 To: Jameson Graef Rollins <jrollins@finestructure.net>, Notmuch Mail\r
  29         <notmuch@notmuchmail.org>\r
  30 Subject: Re: [PATCH] test: initial tests for smime\r
  31 In-Reply-To: <87twzpt6e8.fsf@servo.finestructure.net>\r
  32 References: <87wq4ltbma.fsf@servo.finestructure.net>\r
  33         <1421530691-14060-1-git-send-email-david@tethera.net>\r
  34         <87twzpt6e8.fsf@servo.finestructure.net>\r
  35 User-Agent: Notmuch/0.19+27~g29ffde4 (http://notmuchmail.org) Emacs/24.4.1\r
  36         (x86_64-pc-linux-gnu)\r
  37 Date: Sat, 17 Jan 2015 23:29:11 +0100\r
  38 Message-ID: <87sif99h3c.fsf@maritornes.cs.unb.ca>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: text/plain\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Sat, 17 Jan 2015 22:29:21 -0000\r
  54 \r
  55 Jameson Graef Rollins <jrollins@finestructure.net> writes:\r
  56 \r
  57 > For some reason PATCH 3/4 no longer applies after substituting in this\r
  58 > patch as PATCH 1/4.\r
  59 \r
  60 Ah, I guess I need to send the whole series again.\r
  61 \r
  62 >\r
  63 > But do we really need to test the message output of openssl?  It seems\r
  64 > like it's broken, and if it ever gets fixed we'll need to change this\r
  65 > test.\r
  66 \r
  67 I think it's not so much broken as "canonical". There is some discussion\r
  68 in the openssl-smime man page that pointed me to RFC5751\r
  69 para 3.1.1\r
  70 \r
  71    MIME entities of major type "text" MUST have both their line endings\r
  72    and character set canonicalized.  The line ending MUST be the pair of\r
  73    characters <CR><LF>\r
  74 \r
  75 > But all we really care about is that openssl is properly verifying the\r
  76 > message, yes?  Why not just test that and forget about the rest of\r
  77 > openssl's output?\r
  78 \r
  79 Maybe it doesn't add too much as long as the message is using the "clear\r
  80 signed" multipart/signed format. On the other hand there is an opaque\r
  81 signed format (application/pkcs7-mime with Signeddata) too, where it\r
  82 would be interesting to check for mangling of the text. Similarly, when\r
  83 we add a similar test for encryption, I think we do want to check the\r
  84 content, so we'll have to figure this out at some point.\r
  85 \r
  86 Cheers,\r
  87 \r
  88 d\r