From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Opportunistic STARTTLS in smtpmail.el Date: Tue, 31 May 2011 05:13:09 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y61nnpoq.fsf@lifelogs.com> References: <87d3kal0za.fsf@lifelogs.com> <874o5mky4o.fsf@lifelogs.com> <8762ptue8r.fsf@lifelogs.com> <87k4e8ucw3.fsf@lifelogs.com> <87liyofwxp.fsf@lifelogs.com> <874o5cfui5.fsf@lifelogs.com> <87liyndz5l.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306836825 15328 80.91.229.12 (31 May 2011 10:13:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 31 May 2011 10:13:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 31 12:13:41 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 1QRLxC-0007rm-VQ for ged-emacs-devel@m.gmane.org; Tue, 31 May 2011 12:13:39 +0200 Original-Received: from localhost ([::1]:34231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRLxC-00045R-Df for ged-emacs-devel@m.gmane.org; Tue, 31 May 2011 06:13:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRLx5-00044c-PN for emacs-devel@gnu.org; Tue, 31 May 2011 06:13:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRLx1-0000yS-T8 for emacs-devel@gnu.org; Tue, 31 May 2011 06:13:31 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:44924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRLx1-0000yG-I8 for emacs-devel@gnu.org; Tue, 31 May 2011 06:13:27 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QRLx0-0007pX-Gs for emacs-devel@gnu.org; Tue, 31 May 2011 12:13: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 ; Tue, 31 May 2011 12:13: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 ; Tue, 31 May 2011 12:13:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 71 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:qjq31Vc40ySnM7DtS/yHJ/agINY= 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:139953 Archived-At: On Tue, 31 May 2011 01:10:04 +0200 Lars Magne Ingebrigtsen 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 "login^@bar^@password^@zot" 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 "login^@bar^@password^@zot^@pad^@%s" (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:" it needs to decode that hex data. We should provide a general mode that can show the file with all the gpg: 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