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: secure plist store Date: Wed, 29 Jun 2011 05:46:46 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r56csynd.fsf@lifelogs.com> References: <87pqmxvfoh.fsf@lifelogs.com> <87sjrttwh8.fsf@lifelogs.com> <87wrh4b9h9.fsf@lifelogs.com> <87aae05l8p.fsf-ueno@unixuser.org> <87k4d4b66p.fsf@lifelogs.com> <87wrh0fh4g.fsf_-_@lifelogs.com> <87y60ncma8.fsf_-_@lifelogs.com> <87vcvrne02.fsf-ueno@unixuser.org> <87r56ep3sm.fsf@lifelogs.com> <874o39n171.fsf-ueno@unixuser.org> 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 1309344873 2611 80.91.229.12 (29 Jun 2011 10:54:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Jun 2011 10:54:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 29 12:54:28 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 1QbsPa-0002Kh-Vq for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 12:54:27 +0200 Original-Received: from localhost ([::1]:37776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbsPa-0004f2-8R for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 06:54:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbsIT-0002ga-4r for emacs-devel@gnu.org; Wed, 29 Jun 2011 06:47:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbsIO-0002Pj-4d for emacs-devel@gnu.org; Wed, 29 Jun 2011 06:47:04 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbsIN-0002PX-KR for emacs-devel@gnu.org; Wed, 29 Jun 2011 06:46:59 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QbsIL-0007fF-Oz for emacs-devel@gnu.org; Wed, 29 Jun 2011 12:46:57 +0200 Original-Received: from 38.98.147.133 ([38.98.147.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Jun 2011 12:46:57 +0200 Original-Received: from tzz by 38.98.147.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Jun 2011 12:46:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 46 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.133 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:Td3VbsDiPu7houctyewbXlyQmzY= 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:141160 Archived-At: On Wed, 29 Jun 2011 18:05:36 +0900 Daiki Ueno wrote: DU> Lars Magne Ingebrigtsen writes: >>> I didn't notice that the field encryption code is already checked in. >>> However, it does not work for me at all and looks too complicated - also >>> it apparently does not benefit from GPG2 passphrase caching (see "(auth) >>> GnuPG and EasyPG Assistant Configuration"). >> Lars> Can't it be altered to support passphrase caching? DU> Not really - GPG2 passphrase caching is smarter than elisp level caching DU> as it uses unique ID embedded in GPG data, so it allows user to share DU> passphrases even among multiple Emacs processes. ...so you're saying we don't benefit from a feature we can't use? What are we supposed to change or improve? >>> --8<---------------cut here---------------start------------->8--- >>> (("baz" :secret-user t :host "baz.example.org") >>> ("bar" :secret-user t :host "bar.example.org") >>> ("foo" :host "foo.example.org" :port 80)) Lars> The nice thing about the netrc format is that people can edit it Lars> themselves. This looks more fragile. DU> The above format is tentative and could be improved. The nicest thing about the netrc format, IMHO, is that other programs understand it. Your proposal is no better than a binary store as far as other programs are concerned. The GPG tokens we currently have are backwards compatible, meaning that they can be mixed with unencrypted lines and tokens, and that's the reason we did them that way. DU> Anyway, as the encrypted fields in netrc is also not easily editable DU> and given that the people editing netrc are kind of power user, how DU> about making netrc files as fallback and read-only from Gnus? The encrypted fields are not supposed to be editable, though that's not hard to provide. Editing the netrc directly is not a power user feature. They are very easy to read and understand. I have shown dozens of people with various skill levels how to use them and the only question they tend to ask is "what about spaces in the password?" Ted