From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/86228 Path: news.gmane.org!not-for-mail From: Jens Lechtenboerger Newsgroups: gmane.emacs.gnus.general Subject: Refactoring of mml1991.el, mml2015.el, mml-smime.el (was: Default encryption for Message) Date: Fri, 16 Oct 2015 18:26:34 +0200 Message-ID: <87k2qmsrt1.fsf@informationelle-selbstbestimmung-im-internet.de> References: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445012877 1438 80.91.229.3 (16 Oct 2015 16:27:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 16:27:57 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34462@lists.math.uh.edu Fri Oct 16 18:27:45 2015 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zn7r5-0002Tl-BM for ding-account@gmane.org; Fri, 16 Oct 2015 18:27:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.85) (envelope-from ) id 1Zn7qF-0003er-31; Fri, 16 Oct 2015 11:26:51 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Zn7qB-0003eN-Py for ding@lists.math.uh.edu; Fri, 16 Oct 2015 11:26:47 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zn7q9-0005T4-Fp for ding@lists.math.uh.edu; Fri, 16 Oct 2015 11:26:47 -0500 Original-Received: from mx1.mailbox.org ([80.241.60.212]) by quimby.gnus.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Zn7q7-0007nL-Iw for ding@gnus.org; Fri, 16 Oct 2015 18:26:43 +0200 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 125D743F8A for ; Fri, 16 Oct 2015 18:26:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id vWMUHnCXXzyT for ; Fri, 16 Oct 2015 18:26:36 +0200 (CEST) OpenPGP: id=0xA142FD84; url=http://www.informationelle-selbstbestimmung-im-internet.de/A142FD84.asc Mail-Followup-To: ding@gnus.org In-Reply-To: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> (Jens Lechtenboerger's message of "Sun, 21 Sep 2014 12:08:44 +0200") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-Spam-Score: -4.9 (----) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:86228 Archived-At: On 2014-09-21, at 12:08, Jens Lechtenboerger wrote: > 5. Refactoring > mml1991.el, mml2015.el, and mml-smime.el share code, forcing > copy-and-paste on updates. Hi there, this is a continuation of a one year old thread. Sorry for the delay. Essentially, I proposed a refactoring of mml1991.el, mml2015.el, and mml-smime.el such that common code can be maintained in a single file. I did that now, with a new file mml-epg.el that is accompanied by test cases, mml-epg-test.el. My changes are as follows, please let me know what you think. * Common code moved to mml-epg.el (from all three previous files) Functionality concerning passphrase callback, code to check user IDs and sub-keys for validity, code to find usable public and private keys, common code from sign and encrypt functions. * Treatment of common variables There are variables in mml1991.el and mml2015.el for which I doubt that users will really set them differently. In fact, both files concern OpenPGP, most likely (or for sure?) with GnuPG, and I fail to see reasons to set them differently. These are the variables I=E2=80=99m refer= ring to: mml1991-cache-passphrase and mml2015-cache-passphrase, mml1991-passphrase-cache-expiry and mml2015-passphrase-cache-expiry, mml1991-signers and mml2015-signers, mml1991-encrypt-to-self and mml2015-encrypt-to-self. In my code, each pair is replaced with a single variable with the prefix =E2=80=9Cmml-epg-openpgp=E2=80=9D, e.g., =E2=80=9Cmml-epg-openpgp-cache-pas= sphrase=E2=80=9D. Concerning S/MIME, I introduced the same variables with prefix =E2=80=9Cmml-epg-smime=E2=80=9D. Also, two variables from mml2015.el and mml-smime.el were missing in mml1991.el, whose functionality is present now with the common prefix =E2=80=9Cmml-epg-openpgp=E2=80=9D: mml-epg-openpgp-sign-with-sender and mml-epg-openpgp-always-trust * Treatment of encrypt-to-self As discussed last year, encrypt-to-self in mml2015.el is implicitly based on signature-related variables (based on undocumented use of mml2015-sign-with-sender), which I find counter-intuitive. I changed the encrypt-to-self variables into independent ones: If the value is t, then the message is also encrypted to the sender=E2=80=99s key. Alternativ= ely, the value can also be a list of encryption keys (or corresponding e-mail addresses), in which case the message is also encrypted to those keys. * Minor (?) differences among previous files, now unified In mml-smime-epg-passphrase-callback, password-cache-key-id is not passed as argument to password-read, while such an argument is passed in the corresponding functions in mml2015.el and mml1991.el. Now that argument is passed also for S/MIME. Is there a reason not to pass that argument? In mml1991.el, prior to encryption, recipients were not enclosed in ankle brackets "<" and ">", while such brackets were added in mml2015.el. Now they are added in all cases. * Passphrase caching If I=E2=80=99m not mistaken, with GnuPG 2.x (and gpgsm) passphrases cannot = be cached within Emacs as gpg-agent is started automatically and tries to invoke a pinentry program. So caching-related variables only apply to GnuPG 1.x and S/MIME with openssl (I suggest not to advertise the latter any longer, see separate point below). In fact, one of my test cases (mml-epg-en-decrypt-passphrase-no-cache-smime-todo) has an expected failure for gpgsm, as the cache is not inspected. Another test case (mml-epg-en-decrypt-passphrase-no-cache-openpgp-todo) is skipped for GnuPG 2.x. Is there a way to cache passphrases within Emacs, even with gpgsm and GnuPG 2.x? Note that GnuPG 2.x is where the development happens, and according to GnuPG=E2=80=99s README, =E2=80=9C2.0 is the current stable version for gene= ral use=E2=80=9D, while =E2=80=9C1.4 is the old standalone version which is most suitable for older or embedded platforms.=E2=80=9D So, if we cannot cache for the current stable version, should we not recommend caching inside gpg-agent in general and get rid of the associated code? Even if there was a way, should we not recommend caching inside gpg-agent in general? * Selecting =E2=80=9Cusable=E2=80=9D keys In mml2015-epg-find-usable-key the test mml2015-epg-check-user-id is not applied if the condition (string-match "\\`<" name) is true. I don=E2=80=99t understand this, but I still copied the code to mml-epg-find-usable-keys. What is special about names starting with "<" (except that they are used to indicate exact matches for e-mail addresses in GnuPG)? Why should revoked or expired user IDs be OK if they match that pattern? In fact, one of my test cases (mml-epg-find-usable-keys-todo) is an expected failure due to this behavior, where a revoked user IDs is returned (also expired ones could be returned, if one knows how to create them). Moreover, the function mml2015-epg-find-usable-secret-key does not check validity of subkeys requested by key ID. Two of my test cases (mml-epg-find-usable-keys-todo-2 and -3) fail due to this issue, when an expired subkey is requested and the mainkey is returned. Also, test case mml-epg-sign-verify-todo behaves in the wrong way due to this issue. Finally, function mml-epg-find-usable-key has an argument USAGE, which can be `sign'. However, as main keys can typically be used to sign (by the key owner), almost every key is =E2=80=9Cusable=E2=80=9D for USAGE = `sign' according to this function, although no sign operation can be performed when the private key is missing. I=E2=80=99ve written new functions mml-epg-check-sub-key-2 and mml-epg-find-usable-keys-2 to address the above issues (with corresponding test cases). Note that mml-epg-find-usable-keys-2 subsumes mml-epg-find-usable-keys and mml-epg-find-usable-secret-keys (which are based on mml2015.el). The doc string explains the differences. Essentially, I propose to use mml-epg-find-usable-keys-2 (and changed helper functions) instead of mml-epg-find-usable-keys and mml-epg-find-usable-secret-keys. * Choice of =E2=80=9Cusable=E2=80=9D keys, now with customizable preferences Previously, the =E2=80=9Cfirst=E2=80=9D usable key (based on an undocumente= d order) was chosen if multiple keys were available (for encryption as well as signing). My new code asks the user which one to use and allows to customize that choice (new variable mml-epg-key-preferences). * Questions while coding In mml-epg-test.el two TODO comments occur, marking sections that need verification. One is discussed above (passphrase caching). The second one: In my test code, I use several fixtures for test setup, sometimes calling one fixture from another. I ran into infinite loops, when I called variables representing function bodies =E2=80=9Cbody=E2=80=9D in sev= eral fixtures. By renaming variables to have different names in different fixtures, the code runs as I expected. Why do those infinite loops occur? Missing understanding on my part or an Emacs bug? Moreover, I added several TODO comments in mml-epg.el, related to above points as well as to additional questions: In mml-epg-select-keys-1, I use y-or-n-p to display a question (let-binding message-truncate-lines to nil), but the question gets truncated if called from an encryption context. To see this, invoke mml-epg-select-preferred-keys-todo from mml-epg-test.el (see README.txt for detailed instructions), mark one or two keys, and press `C-c C-c'. You=E2=80=99ll be asked whether to save that choice, but the question is truncated. How can I resize the echo area to display the entire message? (With mml-epg-select-preferred-keys-ok you can see the entire message, but outside an encryption context.) Towards the end of mml-epg.jl three basic functions are defined, which might be of independent interest. Where should they go? In mml-epg.el I use define-obsolete-variable-alias, probably in an incorrect way. Where/how should that be done to make sure that potential user customizations of the obsolete variables carry over to the new ones? * Preference for openssl vs epg (gpgsm) Currently, Gnus prefers openssl over epg (gpgsm), via (defcustom mml-smime-use (if (featurep 'epg) 'epg 'openssl)) in mml-smime.el. However, epg does not get loaded on its own even if it is present. Thus, users need to set mml-smime-use or require epg in their ~/.emacs, but the manual does not mention gpgsm at all. Where would be an appropriate place to (require 'epg)? I propose to change that preference in favor of epg (gpgsm) as: ** Gpgsm manages certificates (storage, expiry, revocation). Users need to perform those tasks manually with openssl. ** Openssl has bugs as documented in the BUGS section of man smime(1). In particular: SMIMECapabilities are ignored, no revocation checking is done on the signer's certificate. ** Advertised SMIMECapabilities include broken encryption algorithms. With the precompiled openssl 1.0.1f on my system RC2 is advertised, which should have been dropped since S/MIME 3.x, see: https://tools.ietf.org/html/rfc5751#appendix-B * Next steps A tarball with my files is available over there (README.txt explains its contents): http://informationelle-selbstbestimmung-im-internet.de/emacs/mml-epg-2015-1= 0-16.tar.bz2 http://informationelle-selbstbestimmung-im-internet.de/emacs/mml-epg-2015-1= 0-16.tar.bz2.asc What are your suggestions to continue from here? Best wishes Jens