From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/84961 Path: news.gmane.org!not-for-mail From: Jens Lechtenboerger Newsgroups: gmane.emacs.gnus.general Subject: Default encryption for Message Date: Sun, 21 Sep 2014 12:08:44 +0200 Message-ID: <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 1411294215 22549 80.91.229.3 (21 Sep 2014 10:10:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 10:10:15 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33205@lists.math.uh.edu Sun Sep 21 12:10:10 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XVe5o-0005nK-LP for ding-account@gmane.org; Sun, 21 Sep 2014 12:10:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1XVe4p-00034X-Um; Sun, 21 Sep 2014 05:09:08 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1XVe4n-00034I-FP for ding@lists.math.uh.edu; Sun, 21 Sep 2014 05:09:05 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XVe4j-0000xl-AK for ding@lists.math.uh.edu; Sun, 21 Sep 2014 05:09:02 -0500 Original-Received: from mout.kundenserver.de ([212.227.126.131]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XVe4g-0000aM-Dz for ding@gnus.org; Sun, 21 Sep 2014 12:08:58 +0200 Original-Received: from PC (mnsr-4db1e100.pool.mediaWays.net [77.177.225.0]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M8M5O-1YHREO1E2c-00vxDw; Sun, 21 Sep 2014 12:08:50 +0200 OpenPGP: id=0xA142FD84; url=http://www.informationelle-selbstbestimmung-im-internet.de/A142FD84.asc Mail-Followup-To: ding@gnus.org User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V02:K0:kqiaKMHIrLdEEP50ZI/z27P8TAMjW3gBGzKoD+LGo5N yL5zn290gnN31hEbUCKQfulfzFvtBsd3Eb4t8/niswPZpkCkzF O7C6ZRO/4ZmK2VG3twnhWbSyp6VASWIwWT1jfWig573aCMAk0o YghRf0zGKAFLvhZCZE8ynhFh5hi6QMB0mvZ+Nr4BBM2kxhN0X/ kKR576BPRU1DSLMSAilb/E7EdYlqtzLq/1HGTv0Xbq29Q5/pIR RWdQuPLHwUOhKLyS1CjdDQOpoFiRzOuI7j6SrJqtsxhfMsr8/s AUwt4pUrPuxzcogkT0PAOQVYx1zEF1P0m8fzEJEtcHPMGz3ZEw gX02sSmAKo5cWLwfTvfxqr01eH400obPG0O2rRfQxOmvgMIskd t6lIst47n0YnA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:84961 Archived-At: Hi there, my stance on encryption is simple: The Internet is a hostile place, where all personal communication must be encrypted. Network software should perform encryption by default and require a conscious decision on the user=E2=80=99s part to send out plaintext. Based on this conviction I have been maintaining DefaultEncrypt (and ExtendSMIME) for some time [1]: http://www.emacswiki.org/emacs/DefaultEncrypt Essentially, that package extends Gnus Message to add MML encryption tags if public keys for all recipients are available. I=E2=80=99d like to integrate that code into Gnus, but I see a couple of challenges, which I=E2=80=99d like to discuss with you. (This message is long, be warned ;) I prepared a new version of that package with the aim to simplify discussion, where I replaced the key rebinding with add-hooks and renamed functions to indicate where they might belong: http://informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt-4.1= -discussion.el http://informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt-4.1= -discussion.el.asc (No new functionality is added. This is not a regular release.) 1. Bcc handling. Bcc handling in Gnus is broken. Messages are encrypted to all recipients, giving away the key IDs (thus, in general the identities) of all recipients, including the =E2=80=9Cblind=E2=80=9D ones. The Right Thing is explained there: http://lists.gnupg.org/pipermail/gnupg-users/2014-April/049394.html In DefaultEncrypt I added a test to warn against such cases. In the version linked above, mml-secure-bcc-is-safe implements that test. I suggest to copy that function (and its prerequisites) into mml-sec.el. Then, mml-secure-bcc-is-safe can be added as message-send-hook, which I suggest as default until proper Bcc handling is implemented. 2. mml-default-encrypt-method The variable mml-default-encrypt-method combines two separate concepts: First, whether to use OpenPGP or S/MIME. Second, if OpenPGP is chosen whether to use MIME Security or not. For me, this is not good enough. Suppose I preferred S/MIME in general (which I do not). Then, I would need to customize mml-default-encrypt-method for S/MIME. If I then send an e-mail to someone who does not use S/MIME but OpenPGP, my code kicks in, detects that OpenPGP should be used, but does not know whether to use MIME Security or not. Thus, I=E2=80=99m using an additional variable that focuses on MIME Security for OpenPGP: mml-secure-pgp-without-mime If (a variant of) that variable was added to Gnus, mml-encrypt-alist probably would need to change to include a generic pgp function, which decides whether to use MIME or something else. My own variable mml-secure-pgp-without-mime is currently just a Boolean, so it would not be good enough to distinguish pgp, pgpmime, and pgpauto. When and what is pgpauto good for, anyways? 3. Creation of signatures If I=E2=80=99m not mistaken, Gnus only supports the creation of signatures for reply messages (gnus-message-replysign and gnus-message-replysignencrypted). I added a variable mml-secure-insert-signature with the following doc string: Control whether MML signature tags should be produced. If it is nil, no signatures are created. If it is `always', signature tags are inserted for new messages (with their type determined by `mml-default-sign-method'). If is is `encrypted', messages that are encrypted are also signed. If this variable is set to nil, my code sets gnus-message-replysignencrypted to nil, which is a hack. Maybe my variable should really be called gnus-message-sign and supersede gnus-message-replysign and gnus-message-replysignencrypted. Maybe more values would be necessary then to cover all situations where MML sign tags should be added automatically (always, only in replies to signed messages, only in encrypted replies to signed messages, only in encrypted replies to signed and encrypted messages, in every encrypted message, never). I=E2=80=99m not sure about user expectations and the necessity of backwards compatibility, though. 4. mm-encrypt-option I wrote code around mm-encrypt-option, via the variable mml-secure-i-am-aware-of-mm-encrypt-option with the following doc string: In general, multiple public keys may exist for a single e-mail address (e.g., for different security levels or before one key expires). In such a case, EasyPG and gpg automatically select a key, while gpgsm reports an ambiguity. This variable is intended as safety check against the default setting of `mm-encrypt-option'. If that variable has its default value of nil, some key is selected automatically, without any documentation as to what selection process is applied. If you are really sure about the appropriateness of that process, set this variable to t. If you are unsure about that process, do not touch the default value of this variable, and you will be asked to select keys manually if multiple ones are available. If you configure `mm-encrypt-option' to `guided', this variable does not have any effect. (However, in that case you will *always* be asked to choose keys, even if only one per recipient is available. Quite likely, that is not what you want.) Clearly, my variable is a hack. A better approach might be a third value for mm-encrypt-option, say guided-if-multiple, to only enter guided mode if multiple keys are available. That would require, however, to modify code in mml1991.el, mml2015.el, and mml-smime.el, which brings me to the next point. 5. Refactoring mml1991.el, mml2015.el, and mml-smime.el share code, forcing copy-and-paste on updates. For example, in the past I used mml2015-epg-find-usable-key to find usable keys. With Gnus v5.13, mml2015-epg-find-usable-key and mml1991-epg-find-usable-key were exact duplicates, while mml-smime-epg-find-usable-key was similar but did not test for disabled keys. I went for mml2015-epg-find-usable-key in all cases. With Ma Gnus v0.7, mml2015-epg-find-usable-key was rewritten with an incompatible list of arguments to use the new function mml2015-epg-check-sub-key, while mml1991-epg-find-usable-key remained unchanged. Why actually? To be honest I don=E2=80=99t understand the comment in mml2015-epg-find-usable-key about =E2=80=9CNon e-mail user-id=E2=80=9D with mml-signers and mml2015-encrypt-to-self. In fact, I don=E2=80=99t understand mml2015-encrypt-to-self (which is not mentioned in the manual) at all. If I set that to true I cannot send encrypted messages but receive the error: =E2=80=9CNeither message sender nor mml2015-signers are set=E2=80=9D For reasons I don=E2=80=99t understand the code seems to bind encrypt-to-self to signing. I like the freedom of encryption independently of the controlling chains of signatures (also, signatures require the presence of private keys, which is not the case for encryption). I=E2=80=99m simply using encrypt-to and hidden-encrypt-to in gpg.conf. Alternatively, messages could be encrypted to the From address. Alternatively, why is gpg=E2=80=99s encrypt-to not good enough? (Also, currently users probably need to configure three variables: mml2015-encrypt-to-self, mml1991-encrypt-to-self, mml-smime-encrypt-to-self) In any case, I=E2=80=99d like to use a stable interface into epg and suggest to provide that in a new file, say mml-epg.el. Then, we could move either mml2015-epg-find-usable-key or mml1991-epg-find-usable-key with the new name mml-epg-find-usable-keys into that file and use that in mml1991, mml2015, and mml-smime. Actually, that function should have an additional Boolean argument specifying whether to return just one key or all of them. Also, the functions named mml-epg-... in jl-encrypt.el could go into that file. I=E2=80=99d be happy to write that file once we discussed the change in mml2015-epg-find-usable-key about =E2=80=9CNon email user-id=E2=80=9D menti= oned above. What=E2=80=99s your opinion? Best wishes Jens [1] Actually, much more could be done. (a) Emacs or Gnus could check whether GnuPG is installed. If not, recommend its installation. The following is what https://www.mailpile.is/ seems to do. (b) For every message Gnus could check whether a secret key exists for the From address. If not, (recommend to) create one. (With customizable exceptions.) (c) For every plaintext message, attach the own public key, and point to a good guide, e.g.: https://emailselfdefense.fsf.org/ (With customizable exceptions.) (d) Automatically import public keys. (e) Support search over encrypted messages.