Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Thu, 1 Nov 2007 10:30:54 +0900 "Daiki Ueno" <address@hidden> wrote: 

DU> 2007/11/1, Ted Zlatanov <address@hidden>:
>> It definitely makes sense to move encrypt.el into Emacs as well then.
>> My main concern was that it overlaps with all the other *crypt*.el
>> packages, and I really think that encrypt.el's simplicity and
>> non-invasiveness justifies its existence.  But it requires password.el.
>> I'm open to suggestions as to the best way to manage it.

DU> epa-file.el in EasyPG can also do that.  Have you looked at it?
DU> I think it is much easier to use since it does not need elisp setup
DU> like encrypt-file-alist.

encrypt-file-alist can be set up via Customize.  It's intended as an
API, however, so I am not concerned about end users too much.

Your EasyPG code is probably better, I am not an ELisp expert by any
means.  But epa-file.el not an API, and does not support arbitrary
ciphers as encrypt.el does (AFAIK).  See the encrypt.el XOR cipher for
an example of what I mean.  EasyPG seems firmly attached to the GPG/PGP
process, which is not a bad thing, only it doesn't provide an abstract
encryption API.

DU> Yes, EasyPG is a bit complex and invasive.  But IMO sometimes
DU> usability should be given priority over simplicity &
DU> non-invasiveness.

Sure, and that's your choice to make within the EasyPG package, which
has specific needs.  I think an API must be simple an non-invasive,
though, and encrypt.el is by those standards a better API than
epa-file.el or any other *crypt* package I've seen.  If I'm wrong,
please tell me.

DU> BTW, I just tried encrypt.el and I encountered a few issues.  (1) It
DU> uses gnus-error to report errors so there is a dependency to
DU> gnus-util.el.

Yes.  I'll gladly fix that if it moves outside Gnus but for now that's
the appropriate notification mechanism.

DU> (2) The instruction says M-x encrypt-file-contents but there is no
DU> such function (perhaps is it a typo of
DU> encrypt-write-file-contents?).

I fixed that in the docs.  Thank you very much.

DU> (3) encrypt-find-model does not resolve path names.

That was intentional at the time, because I thought resolving the path
wouldn't allow matching ~ and such.  If it's wrong, please let me know.

Ted