Re: netrc.el now supports encoded files

[Simon Josefsson <jas@extundo.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> Anyway, it sounds more and more like this could be a separate
>> package.  "encrypt.el" is available, AFAICT.  Using various hooks,
>> such a package might be able to work without the cooperation of Gnus
>> at all.  Then you could request automatic encryption/decrypt of
>> ~/.newsrc.eld by saying (add-to-list 'encrypt-file-alist
>> '("~/.newsrc.eld."  gpg-symmetric)) or something like that.
>
> I think cooperation is good.  Trying to hide the reality of the
> situation - that we're encoding files with external utilities or
> internal functions - is sure to cause problems in the long run.  I see
> it in crypt++.el, and it's not pretty.  It interferes with many
> packages.

Yes.  OTOH, in some (non-Gnus) situations it might useful to be able
to "advice" a package to encrypt its files, without changing the
package.

> I think I'd like to start on gnus-encrypt.el.  These functions will
> be available:
>
> gnus-encrypt-insert-file-contents
> gnus-encrypt-write-file-contents
>
> and these variables:
>
> gnus-encrypt-file-alist
>
> The format of that variable: list of filenames or regular expressions
> matched with an encrypting/decrypting method.  Methods:
>
> '(gpg PUBKEY) ; RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
> '(gpg CIPHER) ; 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
> '(openssl CIPHER) ; too many to list
> '(internal CIPHER) ; rijndael, RC4, XOR, Base64 etc.
>
> What do you think?  Any comments before I start coding?

This sounds good to me.  And probably more reliable than any crypt++
approach.

Btw, the "ecrypto" XEmacs package contain (3)DES and Blowfish in elisp
as well.