From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/84988 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Default encryption for Message Date: Tue, 23 Sep 2014 16:02:00 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <86wq8xffpv.fsf@informationelle-selbstbestimmung-im-internet.de> Reply-To: ding@gnus.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1411502561 4341 80.91.229.3 (23 Sep 2014 20:02:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Sep 2014 20:02:41 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33232@lists.math.uh.edu Tue Sep 23 22:02:33 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 1XWWIA-00028p-L5 for ding-account@gmane.org; Tue, 23 Sep 2014 22:02:31 +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 1XWWI5-0000AC-58; Tue, 23 Sep 2014 15:02:25 -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 1XWWI3-0000A1-Vk for ding@lists.math.uh.edu; Tue, 23 Sep 2014 15:02:23 -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 1XWWI1-0006V6-QJ for ding@lists.math.uh.edu; Tue, 23 Sep 2014 15:02:23 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XWWHz-0000Vo-3I for ding@gnus.org; Tue, 23 Sep 2014 22:02:19 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XWWHt-0001tT-66 for ding@gnus.org; Tue, 23 Sep 2014 22:02:13 +0200 Original-Received: from 198.0.146.153 ([198.0.146.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 22:02:13 +0200 Original-Received: from tzz by 198.0.146.153 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 22:02:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 46 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 198.0.146.153 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (darwin) Cancel-Lock: sha1:4ZyK/4bzPgkD03unXdjxocEIuLg= X-Spam-Score: -2.4 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:84988 Archived-At: On Sun, 21 Sep 2014 12:08:44 +0200 Jens Lechtenboerger wrote: JL> 1. Bcc handling. JL> Bcc handling in Gnus is broken. Messages are encrypted to JL> all recipients, giving away the key IDs (thus, in general the JL> identities) of all recipients, including the “blind” ones. JL> The Right Thing is explained there: JL> http://lists.gnupg.org/pipermail/gnupg-users/2014-April/049394.html JL> In DefaultEncrypt I added a test to warn against such cases. In the JL> version linked above, mml-secure-bcc-is-safe implements that test. JL> I suggest to copy that function (and its prerequisites) into JL> mml-sec.el. Then, mml-secure-bcc-is-safe can be added as JL> message-send-hook, which I suggest as default until proper Bcc JL> handling is implemented. I don't think warning is enough. If it can be fixed, it should be fixed. JL> 2. mml-default-encrypt-method No opinion. JL> 3. Creation of signatures ... JL> I’m not sure about user expectations and the necessity of backwards JL> compatibility, though. No opinion, except IMO the Right Thing should override backwards compatibility when it comes to security. JL> 4. mm-encrypt-option ... JL> Clearly, my [solution] is a hack. A better approach might be a third JL> value for mm-encrypt-option, say guided-if-multiple, to only enter JL> guided mode if multiple keys are available. That would require, JL> however, to modify code in mml1991.el, mml2015.el, and mml-smime.el, JL> which brings me to the next point. Ask once, then save the preference in a Customize-controlled variable. JL> 5. Refactoring No opinion. Ted