Gnus development mailing list
 help / color / mirror / Atom feed
* Default encryption for Message
@ 2014-09-21 10:08 Jens Lechtenboerger
  2014-09-23 20:02 ` Ted Zlatanov
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Jens Lechtenboerger @ 2014-09-21 10:08 UTC (permalink / raw)
  To: ding

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’s 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’d like to integrate that code into Gnus, but I see a couple of
challenges, which I’d 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 “blind” 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’m 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’m 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’m 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’t understand the comment in
mml2015-epg-find-usable-key about “Non e-mail user-id” with
mml-signers and mml2015-encrypt-to-self.  In fact, I don’t
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: “Neither message sender nor
mml2015-signers are set”
For reasons I don’t 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’m simply using encrypt-to and
hidden-encrypt-to in gpg.conf.  Alternatively, messages could be
encrypted to the From address.  Alternatively, why is gpg’s
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’d 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’d be happy to write that file once we discussed the change in
mml2015-epg-find-usable-key about “Non email user-id” mentioned
above.

What’s 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.



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-11-20 16:31 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-21 10:08 Default encryption for Message Jens Lechtenboerger
2014-09-23 20:02 ` Ted Zlatanov
2014-09-24 13:59   ` Jens Lechtenboerger
2014-09-24 15:28     ` Ted Zlatanov
2014-09-24  2:23 ` Daiki Ueno
2014-09-24 14:30   ` Jens Lechtenboerger
2014-09-25  3:06     ` Daiki Ueno
2014-09-25 16:18       ` Jens Lechtenboerger
2014-09-28  0:16         ` Daiki Ueno
2014-10-02 16:51           ` Jens Lechtenboerger
2015-10-16 16:26 ` Refactoring of mml1991.el, mml2015.el, mml-smime.el (was: Default encryption for Message) Jens Lechtenboerger
2015-10-18  7:36   ` Refactoring of mml1991.el, mml2015.el, mml-smime.el Peter Münster
2015-10-18 14:09   ` Greg Troxel
2015-10-19 12:58     ` Jens Lechtenboerger
2015-11-06  2:10   ` Daiki Ueno
2015-11-07 20:28     ` Jens Lechtenboerger
2015-11-11  6:20       ` Daiki Ueno
2015-11-14 15:44         ` Jens Lechtenboerger
2015-11-20 16:31           ` in defense of GitLab or something (was: Refactoring of mml1991.el, mml2015.el, mml-smime.el) Ted Zlatanov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).