From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 34EAF6DE11A3 for ; Sun, 12 Nov 2017 07:27:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.428, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.972, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9V5CPYKpZGY for ; Sun, 12 Nov 2017 07:27:02 -0800 (PST) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by arlo.cworth.org (Postfix) with ESMTPS id 84B3F6DE119D for ; Sun, 12 Nov 2017 07:27:02 -0800 (PST) Received: from smtp02.caltech.edu (localhost [127.0.0.1]) by smtp02.caltech.edu (Postfix) with ESMTP id 4B5476C089B; Sun, 12 Nov 2017 07:27:02 -0800 (PST) X-Spam-Scanned: at Caltech-IMSS on smtp02.caltech.edu by amavisd-new Received: from finestructure.net (wsip-70-183-192-102.br.br.cox.net [70.183.192.102]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jrollins) by smtp-server.its.caltech.edu (Postfix) with ESMTPSA id DD8856C088B; Sun, 12 Nov 2017 07:27:01 -0800 (PST) Received: by finestructure.net (Postfix, from userid 1000) id 48EAF6031D; Sun, 12 Nov 2017 07:27:01 -0800 (PST) From: Jameson Graef Rollins To: Daniel Kahn Gillmor , Notmuch Mail Subject: Re: [PATCH 07/18] crypto: new decryption policy "auto" In-Reply-To: <87wp2w17yl.fsf@fifthhorseman.net> References: <20171025065203.24403-1-dkg@fifthhorseman.net> <20171025065203.24403-8-dkg@fifthhorseman.net> <87r2t4s91g.fsf@ligo.caltech.edu> <87wp2w17yl.fsf@fifthhorseman.net> User-Agent: Notmuch/0.25.1 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-pc-linux-gnu) Date: Sun, 12 Nov 2017 07:26:42 -0800 Message-ID: <87h8tzsekt.fsf@ligo.caltech.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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: Sun, 12 Nov 2017 15:27:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, Nov 12 2017, Daniel Kahn Gillmor wrote: > On Sat 2017-11-11 15:14:03 -0800, Jameson Graef Rollins wrote: >> On Wed, Oct 25 2017, Daniel Kahn Gillmor wrote: >>> diff --git a/util/crypto.h b/util/crypto.h >>> index b23ca747..dc95b4ca 100644 >>> --- a/util/crypto.h >>> +++ b/util/crypto.h >>> @@ -16,7 +16,8 @@ typedef struct _notmuch_crypto { >>> } _notmuch_crypto_t; >>>=20=20 >>> GMimeObject * >>> -_notmuch_crypto_decrypt (notmuch_message_t *message, >>> +_notmuch_crypto_decrypt (notmuch_decryption_policy_t decrypt, >>> + notmuch_message_t *message, >>> GMimeCryptoContext* crypto_ctx, >>> GMimeMultipartEncrypted *part, >>> GMimeDecryptResult **decrypt_result, >> >> Why does _notmuch_crypt_decrypt need to have >> "notmuch_decryption_policy_t decrypt" as an input argument? Isn't >> notmuch_decryption_policy_t already an attribute of the crypto_ctx? Is >> there some situation where the policy would differ from what's specified >> in the crypto_ctx? > > crypto_ctx here is just a GMimeCryptoContext, which doesn't know > anything about notmuch_decryption_policy_t. Maybe i'm misunderstanding > your question? > > I'd be happy to streamline the interface to this internal function, but > given that it's not an exported API, i'm not as concerned about things > like future cleanliness -- the notmuch source contains all invocations > of the function anywhere, so if we find a nicer way to streamline it in > the future, we can do that cleanup across the codebase in a single > commit. I guess I'm confusing how things were before, when the crypto_ctx was a notmuch-defined thing that included the GMimeCryptoContext. It seems like _notmuch_crypto_t could just hold the GMimeCryptoContext, as it does for earlier versions of GMime, which would make things easier to pass around. But this discussion is tangent to this patch series. jamie. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtl0IW5QRe4ExYLZZ7TTOq+J7qrwFAloIaDIACgkQ7TTOq+J7 qrzuWA//Xco7RqcBOpLmFgm5aivTQbdEpVWMlXEscuOddlXbJwlNYS4Yke0S9/DL b7kwHJsUXSGz6iT+qQ4iwpBHyDMqLRcSMYgl/nOjMi8EBhPMt2WX3zzsrjKGKCfJ kl0VM+4zzUhpDE2OTCDBbxcAKDbVcCoeMOnuhlP1w4wNVuqmPBZUMzZN3q5/rlX2 GXaa5jKK1rcFe7Xoim5BG2v8fSqeDlRN6n8nGe4mAqwikXnrGvhM6ZScEDGF33d+ QbfO/823lFAyn2emsXW62UeUD5WXsYG1KdE6YVoiEDEFvrw79/zwxVlDIl/XcMSK ymuX0VvuWAo3tT14ewMzVeF4EIc2aCgxeAbTTfji7b1r9xarevn7prezwrfygKxE QkXDNusv+mIoCni9RaXhV4xTi5AXH1HOMe82KAAocAeRD2wszyZmHr8MLuPS1EAU uKXVDXNakIJHD7V/aw247RQDjTouK/HjvhvvnAgZpZ8zm8mys3DScxXn0G3AQL5m A4dXSkjAMd1HFlEDFIZZQECut2QnaLnfTYUz2tFB6AuPMGTVvfJOaBIOvbsnfdw1 D4C//cTHOFWCAy/uMvGcs3wU1n8yaf3dUv/Dy1uniHhAy8317F78YuEFIasdnH7j pnstAH9jmJ21QOE5GMa+goMeZriNQnlNC1meEGaphP5RAhjWcPg= =5b5+ -----END PGP SIGNATURE----- --=-=-=--