Re: Opportunistic STARTTLS in smtpmail.el

[Ted Zlatanov]

On Tue, 31 May 2011 01:10:04 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> The design requirements are:

LMI> 1) if users want it, credentials should be encrypted

LMI> 2) the credentials should be stored in a file that can be edited by
LMI> hand, if necessary

LMI> 5) it should be possible to check whether credentials exist without
LMI> giving a password, even if the credentials are encrypted

LMI> My solution to all this is to allow putting encrypted stuff into the
LMI> ~/.authinfo file.

LMI> It's currently a one-credential-per-line file like this, and this would
LMI> still be perfectly valid:

LMI> machine news.foo.org force yes port nntp login bar password zot

LMI> However, if auth-info.el prompts somebody for a password, auth-info.el
LMI> will also prompt them for whether the credentials should be stored
LMI> encrypted.  If the user says yes, then auth-info.el will write the
LMI> following to the file:

LMI> machine news.foo.org force yes port nntp secret 
bG9naW4AYmFyAHBhc3N3b3JkAHpvdA

LMI> The secret is simply a base64-encoded gpg-encoded string made something
LMI> like this:

LMI> (base64-encode-string (gpg-encode-string "address@hidden@address@hidden"
LMI>                        (read-string "Password? ")))

LMI> We can add some padding and entropy to make things l33tly secure, like

LMI> (base64-encode-string
LMI>  (gpg-encode-string
LMI>   (format "address@hidden@address@hidden@address@hidden" (random 42))
LMI>   (read-string "Password? ")))

LMI> When decoding, we don't have to decode anything until we actually know
LMI> that we need the password.
  
LMI> People who think this is too insecure can use ~/.authinfo.gpg files,
LMI> just like now.  That's up to them.  

LMI> And people that think that using no encryption at all can do that, too.

s/auth-info/auth-source/g right?  Or are you making a new library?

The above works for me, mostly.  The creation prompts can set a
dynamically scoped `auth-source-encrypted-p' variable to tell all the
creation functions that they are looking at an encrypted file or not
(since double-encrypting is not necessary).  But I would encrypt each
token separately, not several at once, so `auth-source-search' knows if
the token is present.

IOW rather than your "secret" token, let's keep the existing tokens but
the netrc backend of auth-source will know that when it sees "xyz
gpg:<hex data>" it needs to decode that hex data.

We should provide a general mode that can show the file with all the
gpg:<hex data> locations replaced, showing the decrypted data with text
overlays and different colors.  The mode could also edit the encrypted
data inline.  This would be very useful for all of Emacs, not just
auth-source.  Sort of a scratch pad with arbitrary encryption intervals.
With such a mode, a lot less direct auth-source support will be needed
for these encrypted tokens.  The netrc backend would simply use the
general mode.

Ted