[Top][All Lists]
[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
- Re: Opportunistic STARTTLS in smtpmail.el, (continued)
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/06/01
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/06/01
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Robert Pluim, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Daiki Ueno, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Stefan Monnier, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Daiki Ueno, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Ted Zlatanov, 2011/06/02
- Re: Opportunistic STARTTLS in smtpmail.el, Lars Magne Ingebrigtsen, 2011/06/03
- netrc field encryption in auth-source (was: Opportunistic STARTTLS in smtpmail.el),
Ted Zlatanov <=
- Re: netrc field encryption in auth-source, Lars Magne Ingebrigtsen, 2011/06/26
- GPGME (was: netrc field encryption in auth-source), Ted Zlatanov, 2011/06/27
- Re: GPGME, Daiki Ueno, 2011/06/27
- Re: GPGME, Ted Zlatanov, 2011/06/28
- Re: GPGME, Daiki Ueno, 2011/06/28
- secure plist store, Daiki Ueno, 2011/06/29
- Re: secure plist store, Lars Magne Ingebrigtsen, 2011/06/29
- Re: secure plist store, Daiki Ueno, 2011/06/29
- Re: secure plist store, Ted Zlatanov, 2011/06/29
- Re: secure plist store, Daiki Ueno, 2011/06/29