From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: netrc field encryption in auth-source (was: Opportunistic STARTTLS in smtpmail.el) Date: Sun, 05 Jun 2011 10:11:11 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wrh0fh4g.fsf_-_@lifelogs.com> References: <87y61nnpoq.fsf@lifelogs.com> <87fwnuacc5.fsf@lifelogs.com> <878vtmo081.fsf@lifelogs.com> <87tycamhmv.fsf@lifelogs.com> <87pqmxvfoh.fsf@lifelogs.com> <87sjrttwh8.fsf@lifelogs.com> <87wrh4b9h9.fsf@lifelogs.com> <87aae05l8p.fsf-ueno@unixuser.org> <87k4d4b66p.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1307286738 13978 80.91.229.12 (5 Jun 2011 15:12:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 5 Jun 2011 15:12:18 +0000 (UTC) Cc: ding@gnus.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 05 17:12:14 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QTEzt-0003ha-UF for ged-emacs-devel@m.gmane.org; Sun, 05 Jun 2011 17:12:14 +0200 Original-Received: from localhost ([::1]:45145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTEzt-0003rp-40 for ged-emacs-devel@m.gmane.org; Sun, 05 Jun 2011 11:12:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTEzF-0003nl-4w for emacs-devel@gnu.org; Sun, 05 Jun 2011 11:11:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTEzA-0008TL-DO for emacs-devel@gnu.org; Sun, 05 Jun 2011 11:11:32 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:45899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTEz9-0008Rd-RD for emacs-devel@gnu.org; Sun, 05 Jun 2011 11:11:28 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QTEz8-0003SZ-4w for emacs-devel@gnu.org; Sun, 05 Jun 2011 17:11:26 +0200 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jun 2011 17:11:26 +0200 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jun 2011 17:11:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 52 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.hsd1.il.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:ru7bSidVFNG8ESFRm2q/EGaj1Aw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140199 gmane.emacs.gnus.general:79027 Archived-At: (xposted to the Gnus mailing list and thread subject changed, finally) On Fri, 03 Jun 2011 23:54:18 +0200 Lars Magne Ingebrigtsen wrote: LMI> Ted Zlatanov 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 wrote: LMI> Ted Zlatanov 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