Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Sun, 04 Nov 2007 14:56:37 -0500 Richard Stallman <address@hidden> wrote: 

RS>     My arguments are in a separate message, but essentially the difference
RS>     is between providing a GnuPG interface (epg) and providing an
RS>     architecture with user-supplied ciphers that does not depend on GnuPG or
RS>     any other external tools (encrypt.el).

RS> I just looked at encrypt.el.  It appears to support just GnuPG
RS> and "Built-in simple XOR".  And built-in simple XOR is just an
RS> example, not for real use.

The idea is to allow users to supply their own ciphers, and to support
other external utilities as users find it necessary.  I have not had the
time to write more ciphers.

RS> So what useful generality do we really get from this?

1) users don't have to install GnuPG to use simple obfuscation ciphers
(yes, this is sometimes useful).

2) users can be creative and experiment with ciphers in Emacs Lisp, and
share them with others without modifying GnuPG.

3) other external utilities can be supported.  As an example of a nice
use of multiple utilities, spam.el in the Gnus package supports a wide
array of anti-spam tools (including built-in Lisp); because it's easy to
write a backend for spam.el, users have contributed many (at least 4).

4) ciphers, being Emacs Lisp code, can do almost anything: SSH to a
remote machine, use BBDB, use IMAP, use version control...  There's just
no limit to what users can create within the encrypt.el API, which is
intentionally simple and non-invasive.  GnuPG can not match that
flexibility.

RS> By contrast, if Gnus uses EasyPG, I presume that gives
RS> various advantages in using GnuPG compared with the more
RS> direct use of GnuPG thru encrypt.el.  Could someone confirm
RS> that that is true?

It's not an A or B choice.  Both EasyPG and encrypt.el can be installed
and supported.  They are different libraries with different purposes.
One is a GnuPG interface, the other is a generic API.  At least within
Gnus I see no problem with using both.  Also, encrypt.el can use EasyPG
for GnuPG work, if that's necessary (and I think it's a good idea).

RS> All in all it looks like the best thing is to install EasyPG and make
RS> Gnus use it directly.  I'm willing to change my mind if shown a real
RS> advantage of encrypt.el, but I don't see one now.

I've explained this over and over.  I hope you will see the advantages
after all the explanations I've written.  If you need an example of a
more complicated and more creative Lisp cipher, I'll write one.  I do
hope the idea of giving the users creative freedom appeals to you.

Ted