From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id UD5aDVdiNGAQbgAA0tVLHw (envelope-from ) for ; Tue, 23 Feb 2021 02:03:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YOymB1diNGBkTwAA1q6Kng (envelope-from ) for ; Tue, 23 Feb 2021 02:03:03 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6F49E85A9 for ; Tue, 23 Feb 2021 03:03:00 +0100 (CET) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id C036E26C7C; Mon, 22 Feb 2021 21:02:50 -0500 (EST) Received: from che.mayfirst.org (unknown [162.247.75.117]) by mail.notmuchmail.org (Postfix) with ESMTPS id 96A0726BEC for ; Mon, 22 Feb 2021 21:02:48 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614045766; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=jR/qrdVIvEzxcMh5EWkxuOLUiXnbo5wWt48Fl9m6vcM=; b=aVhtKBgxEElByYkBhvgQlmvy4dYVALMYk5M8qop+WECz/3ez0No0/65cAgmMIAuP+EK8A mJ7lI18q8FzX0naBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614045766; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=jR/qrdVIvEzxcMh5EWkxuOLUiXnbo5wWt48Fl9m6vcM=; b=ccc2j5SI32MHaokLZglVHSoR6mVfU3K/7f7vAcembGo4zvzo0SnwSYZ8tm1KnPGOr5mXT hhgrh/IWjdSItR1Oio2ZFcRJF2b7uruwB2cQMqJttPF0HzaIDtlXNYq2H6v3YxXq7fnT+QL hSSbkEEwW52+CKY9A28htbq9Txj4IE2QflvHapGbyrZXuXrF9G+0Y8Uc5B3DlEvK3R+BjcZ 8R5dJoghF3il1oOvnbBNIoiigLIWMKRUPSOAT8BLX7yzz08qA24g8G8VB8Cr/CzAQqWYZVr Ypp9eh9GPGQGmp4NFSuIoXxpXGTX3Bl/VCYhQxOCWqrlU1ASUS4LAdQ1eA1A== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 67A07F9A5; Mon, 22 Feb 2021 21:02:44 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0926420415; Mon, 22 Feb 2021 21:02:25 -0500 (EST) From: Daniel Kahn Gillmor To: David Edmondson , notmuch@notmuchmail.org Subject: Re: [PATCH v2 0/2] scaffolding for autocrypt support In-Reply-To: <20210221152132.2302112-1-dme@dme.org> References: <20210221152132.2302112-1-dme@dme.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 22 Feb 2021 21:02:23 -0500 Message-ID: <87r1l7fsnk.fsf@fifthhorseman.net> MIME-Version: 1.0 Message-ID-Hash: MZ3I474NA7KBJDIXZ5TXXR3FXTCVK6UG X-Message-ID-Hash: MZ3I474NA7KBJDIXZ5TXXR3FXTCVK6UG X-MailFrom: dkg@fifthhorseman.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============9042632360289414039==" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.50 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=fifthhorseman.net header.s=2019 header.b=aVhtKBgx; dkim=fail ("body hash did not verify") header.d=fifthhorseman.net header.s=2019rsa header.b=ccc2j5SI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fifthhorseman.net (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 6F49E85A9 X-Spam-Score: -1.50 X-Migadu-Scanner: scn1.migadu.com X-TUID: LevfDbK7TjPV --===============9042632360289414039== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, all-- On Sun 2021-02-21 15:21:30 +0000, David Edmondson wrote: > I started looking at how to add autocrypt support based on > https://git.sr.ht/~zge/autocrypt. Thanks for this work, i'm glad to see the interest in autocrypt! I tend to think that the autocrypt handling belongs in libnotmuch, and not just in the emacs frontend, so i'm a bit concerned about what we'll have to prune out of the emacs frontend if we do manage to land the features in libnotmuch itself. I want it in libnotmuch and in the cli because: a) i want the database to hold the autocrypt tables, so that it can be dumped/restored between notmuch-based clients b) i want non-emacs frontends of notmuch to be able to make use of it relatively easily. that said, i've failed to get the code into shape for libnotmuch yet, and i also don't want to block this work -- i want to see more autocrypt adoption generally, and i'm feeling guilty for having been so tardy in getting ito into notmuch. My general outline for getting autocrypt into notmuch is the following list of steps. it's a fairly long list, but each step shouldn't be a huge amount of work. 0) augment the database so that it can store the autocrypt "peers" table and the autocrypt "accounts" table, and they can be dumped and restored. see https://autocrypt.org/level1.html#autocrypt-internal-state 1) add a configuration option that affects "notmuch {new,insert,reindex}" that ingests the loading of autocrypt headers according to the standard policy for updating the peer state (see https://autocrypt.org/level1.html#updating-autocrypt-peer-state) 2) add a configuration option that affects "notmuch {new,insert,reindex}" that enables detection of any Autocrypt Setup Message from another client sharing the same inbox, and adjusts the "accounts" table appropriately. 3) add a "notmuch autocrypt" subcommand with its own subsubcommands: "notmuch autocrypt enable [mutual]" and "notmuch autocrypt disable " -- these subsubcommands update the "accounts" table as well. 4) add "notmuch autocrypt generate-setup-message" subsubcommand for enabled accounts that produces its own self-targeted Autocrypt Setup Message on stdout, which can be injected into the mailsystem by the user's notmuch setup. 5) Add "notmuch autocrypt prune" subsubcommand which clears accumulated cruft from the autocrypt peers table 6) in libnotmuch, if is a source e-mail address, and is a set of destination addresses, add is a boolean, a new function notmuch_autocrypt_recommendation(, , ) that returns an Autocrypt Recommendation (ui-recommendation and a set of target-keys, see https://autocrypt.org/level1.html#provide-a-recommendation-for-message-= encryption) 7) add a new subsubcommand that exposes notmuch_autocrypt_recommendation() to the cli. 8) emacs frontend work during message composition (i have no idea how to do this) -- dynamically adjust the message composition buffer as the from, to, cc, and bcc fields change to show the current autocrypt recommendation status, in combination with the ability for the user to manually turn on encryption (if available) or off (if on by default). 9) more emacs frontend work -- at send time (at the end of composition) if the autocrypt recommendation is encrypt, or if it's available and the user has manually turned it on, encrypt the message using standard autocrypt format (which is just PGP/MIME, using the recommended keys). It's possible that (9) could be replaced with a new subcommand like "notmuch send" which could have a "--autocrypt-checked" argument, such that the notmuch cli actually does the full encryption for the user, or acts as some sort of filter for the outgoing message. there might also be some library-level work that could use notmuch and gmime to translate the message this way; I haven't really pieced those things together, or how they would integrate into the emacs frontend, but the steps laid out above seem to be necessary for that to happen in either case. I'd love any collaboration on this -- especially for the parts that i don't know how to do at all, like the emacs composition window frontend =2D- but also on the earlier parts, as i've been procrastinating on it for too long. David, do you think this plan will collide with the series you're proposing? do you see problems or downsides with the plan sketched here (other than it not existing =F0=9F=98=9B)? > Sending seems straightforward, as far as I understand autocrypt, at > least. https://autocrypt.org and the #autocrypt channel on freenode are both good resources for understanding autocrypt in more detail, fwiw. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDRiMAAKCRA+nXFzcd5W XEESAQCd0DNVlsLHwPYB4f27qHE5E4ZwP236EF3xNZtzaM7poAEAxhHn0XqBCXcp nCoS6381GSD2vHmFNhPTpVEMK/jLbQI= =sE2g -----END PGP SIGNATURE----- --=-=-=-- --===============9042632360289414039== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============9042632360289414039==--