Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id A057D429E25 for ; Fri, 23 Dec 2011 19:44:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05gPkxx31wfs for ; Fri, 23 Dec 2011 19:44:37 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by olra.theworths.org (Postfix) with ESMTP id 23DB2431FB6 for ; Fri, 23 Dec 2011 19:44:37 -0800 (PST) X-AuditID: 12074424-b7fae6d000000906-65-4ef54aa465aa Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 70.8C.02310.4AA45FE4; Fri, 23 Dec 2011 22:44:36 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pBO3iaFf024142; Fri, 23 Dec 2011 22:44:36 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBO3iZIj017672 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2011 22:44:36 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1ReIYC-0002FD-7W; Fri, 23 Dec 2011 22:45:36 -0500 Date: Fri, 23 Dec 2011 22:45:36 -0500 From: Austin Clements To: Jameson Graef Rollins Subject: Re: [PATCH 2/4] Introduce a generic tree-like abstraction for MIME traversal. Message-ID: <20111224034511.GB1927@mit.edu> References: <1323027100-10307-1-git-send-email-amdragon@mit.edu> <1323460468-4030-1-git-send-email-amdragon@mit.edu> <1323460468-4030-3-git-send-email-amdragon@mit.edu> <87k46572f7.fsf@gmail.com> <87mxb05dpt.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mxb05dpt.fsf@servo.finestructure.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hTV1l3i9dXPYMNHLYurW/vZLfbs87K4 fnMmswOzx93TXB47Z91l93i26hZzAHMUl01Kak5mWWqRvl0CV8bpMzPYC2ZzV0yY3srUwHiX o4uRk0NCwETi+etDLBC2mMSFe+vZQGwhgX2MEpdnh0HYGxgldt+P6WLkArJPMkk8b2xigXCW MEoc3NID1sEioCrRfPIa2CQ2AQ2JbfuXM4LYIgJmEj1f/oDZzAJeEhM+nWLqYuTgEBaIkHi6 ow4kzCugLfGutZUdYuYXRol/q/cxQiQEJU7OfMIC0aslcePfS7BeZgFpieX/wB7gFDCV6Jhw HqxcVEBFYsrJbWwTGIVmIemehaR7FkL3AkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZ JXqpKaWbGEFBzu6isoOx+ZDSIUYBDkYlHt7GpV/8hFgTy4orcw8xSnIwKYnyXnX76ifEl5Sf UpmRWJwRX1Sak1p8iFGCg1lJhFczCaicNyWxsiq1KB8mJc3BoiTOq6H1zk9IID2xJDU7NbUg tQgmK8PBoSTB+8QTaKhgUWp6akVaZk4JQpqJgxNkOA/Q8CkgNbzFBYm5xZnpEPlTjIpS4rzb QBICIImM0jy4XlgSesUoDvSKMO9LkCoeYAKD634FNJgJaHCMEcjVxSWJCCmpBkbfo5v8c9I5 /HS05kp/SZqfZ6Et9MxdJ4NVa7my1fUOgS2zuHiClTvff/ynFuB0Rc347Tahjsxbkj5zPK8/ nu77KDdU4PnhII99rwMctu+suPhaoO3uXHcJhuak6+KXJ8t4tiYJzn/uFWLQa5hyLfhMpK45 7/vS/x/OK6rky/wzEG/ecdGEV4mlOCPRUIu5qDgRAJ7o4DgdAwAA Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 03:44:37 -0000 Quoth Jameson Graef Rollins on Dec 10 at 1:17 pm: > On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin wrote: > > + out->is_encrypted = TRUE; > > + out->is_signed = TRUE; > > > > These are set only if we do decryption/verification. But their > > names and comments imply that they should reflect properties of > > the part and be set independently from whether we are actually > > doing decryption or verification. > > I don't think this directly affects anything at the moment, but this is > a good point. I can imagine that it might be good to maintain that > distinction down the line so it's probably worth being consistent here. See my response to Dmitry's original email. The structural properties can be derived directly from the type of the part field, so I got rid of these fields. > > Both decryption and verification use cryptoctx. But decryption > > is done iff decrypt is true (without checking if cryptoctx is > > set) and verification is done iff cryptoctx is set (without any > > special flag). Why is it asymmetric? Do we need to check if > > cryptoctx is set for decryption? > > We probably should. We can probably fix this in followup patches, since > Austin is just working off of what dkg and I put in there originally. Actually, this one was my fault from when I tweaked the control flow to use the MIME node context.