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 07:38:53 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87sjqsrew2.fsf@lifelogs.com> References: <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> <87r56csynd.fsf@lifelogs.com> <87wrg4kh7p.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 1309352791 18709 80.91.229.12 (29 Jun 2011 13:06:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Jun 2011 13:06:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 29 15:06:27 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 1QbuTL-0001zZ-Co for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 15:06:27 +0200 Original-Received: from localhost ([::1]:46174 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbuTJ-0005wj-TF for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 09:06:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbu32-0006vy-9j for emacs-devel@gnu.org; Wed, 29 Jun 2011 08:39:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbu2z-0006LE-A8 for emacs-devel@gnu.org; Wed, 29 Jun 2011 08:39:16 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:51295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbu2y-0006Kt-Nh for emacs-devel@gnu.org; Wed, 29 Jun 2011 08:39:13 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qbu2x-0005y7-8V for emacs-devel@gnu.org; Wed, 29 Jun 2011 14:39:11 +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 14:39:11 +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 14:39:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 91 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:Elmqe2jOHuYE2ZMxzxf4b4q3y1E= 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:141172 Archived-At: On Wed, 29 Jun 2011 20:30:34 +0900 Daiki Ueno wrote: DU> Ted Zlatanov writes: 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? DU> OK, honestly, I would say that it won't work with GPG2 since GPG2 does DU> always do the password operation in the agent. Have you tried that? I'm not sure what you're asking, unfortunately. What do you want me to try? >> The nicest thing about the netrc format, IMHO, is that other programs >> understand it. DU> What other programs use GPG encrypted netrc? You mean fully encrypted (authinfo.gpg)? None; that format, however, is the only one available that offers full encryption. The field encryption (GPG tokens) is backwards compatible and no other programs support decrypting those tokens yet (although I would push for it in libcurl, for example). DU> What other programs writes passwords automatically into that file? Why does that matter? It's a convenience we offer. Most other programs that use it fail silently if the credentials are not in there; we ask to save instead. That seems a good choice to me but I want to listen and change things if there are better ways to do it. So far Stefan Monnier and you have complained about the *prompting* and I've tried to fix the prompting issues that Stefan noted in a long bug thread. But no one has complained about the *functionality* or asked to change it. DU> IMHO, these are very ad-hoc approaches and causing unnecessary DU> complexities. Perhaps you could recommend a better way. Besides the Secrets API, which does not work across platforms, I'm not aware of one. >> 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?" DU> I guess that file is edited when a user is accessing to some machines DU> frequently with legacy clients (like ~/.rhosts). Git+libcurl use the netrc file, for instance. It's the only way to provide passwords for Git over HTTP AFAIK. DU> I really hope that Gnus does the password caching in more suckless DU> way, as modern clients like Thunderbird do, at least by default. What are you talking about when you say "password caching"? There are at least 3 pieces: - searching for credentials and using them (host, port, user name, secret) - saving credentials for the session - saving credentials permanently Not to mention the EPA/EPG interaction with the .gpg files, where it sometimes needs to ask for the passphrase. DU> For my case, I have never edited netrc by hand. After upgrading to Gnus DU> in Emacs 24, it started asking with confusing multiple-choice question DU> to save the password, and I answered the question with "y" without DU> reading the help carefully. Then, from the next time, it started asking DU> passwords unwanted timing - really annoying, and it shouldn't be the DU> default behavior for new users. I'm trying to understand the problem of "unwanted timing." Do you mean you're getting prompted for your credentials repeatedly? What Gnus backend are you talking about? Set `auth-source-debug' to 'trivia and check the *Messages* buffer to see what `auth-source-search' calls are failing; that's a good first step to understand what's wrong. In general, if you don't think we should be asking for passwords, how would you suggest we behave when passwords are needed, e.g. for IMAP? Would you rather see something like assistant.el employed to do a multi-step configuration, and then when credentials are missing we simply say "sorry but you have to redo the setup for service X" or ask for the credentials immediately? I think that's what most other MUAs do, with some small variations. They usually save the credentials to a place that only works for that MUA. Ted