emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

netrc field encryption in auth-source (was: Opportunistic STARTTLS in sm


From: Ted Zlatanov
Subject: netrc field encryption in auth-source (was: Opportunistic STARTTLS in smtpmail.el)
Date: Sun, 05 Jun 2011 10:11:11 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

(xposted to the Gnus mailing list and thread subject changed, finally)

On Fri, 03 Jun 2011 23:54:18 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Ted Zlatanov <address@hidden> writes:
>> We'd associate a passphrase with the file, not each piece.  It should be
>> just like using a fully encrypted file, with the same passphrase caching
>> mechanism if symmetric encryption is used.

LMI> Yeah, that was what I was thinking, too.  If you've given the GPG
LMI> password to decrypt the IMAP password, it wouldn't be necessary to
LMI> repeat that to get the NNTP password.

LMI> So there would be the same amount of GPG passwords with plain-text gpg:
LMI> tokens as with the fully-encrypted .authinfo.gpg file.  The main
LMI> functional difference is that with the plain-text file you don't have to
LMI> give the GPG password immediately to see whether you even have a token
LMI> that matches your search criteria.

On Fri, 03 Jun 2011 23:50:11 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Ted Zlatanov <address@hidden> writes:

>> I understand.  But it sucks from the `auth-source-search' perspective
>> because now every secret blob has to be decoded to find out if it has
>> tokens X or Y when the search spec requires X or Y.  So I'm against it.

LMI> True, I didn't think of that.  Then I think your idea for this makes
LMI> most sense, and please go ahead and implement it.  :-)

OK, I will implement it like so in the netrc backend:

key1 val1 key2 gpg:hexdata key3 gpg:hexdata

Where hexdata encodes "((secret "thesecret") (salt "thesalt"))"

The decoding will happen late, probably in the funcall to obtain the
secret (and it will set some scoped variables to cache the data).  That
may be a little surprising to the user but it's the most secure
approach, I think.

If a user puts gpg: tokens in a .gpg file, I'll let them.

The creation process will by default create plaintext data, but maybe I
will add a y/n prompt for "secret" and "password" tokens to save them
encrypted.  I'm not sure yet, I need to try the process.

Is there a decent cipher that's built into Emacs, as a fallback if GPG
is not installed and usable?  I don't see one.

Thanks
Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]