From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76050 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: auth-source.el rewrite Date: Thu, 27 Jan 2011 14:20:01 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ei7yumj2.fsf@lifelogs.com> References: <87fwvu5ele.fsf_-_@lifelogs.com> <87wrp4yjtk.fsf@lifelogs.com> <87eiarj0eu.fsf@lifelogs.com> <87pqu795st.fsf@gmx.de> <87tyjjpfkw.fsf@lifelogs.com> <87ipzz8a79.fsf@gmx.de> <87k4ked3fq.fsf@lifelogs.com> <87pqu6vajx.fsf@gmx.de> <87bp36dxfc.fsf_-_@lifelogs.com> <87ipxdlvqd.fsf@gnus.org> <8762tc538p.fsf@lifelogs.com> <87k4hsitc0.fsf@gmx.de> <877hds1x07.fsf@lifelogs.com> <87ei80oyj9.fsf@gmx.de> <8739ofzjfb.fsf@lifelogs.com> <87fwsfihkp.fsf@gmx.de> <877hdrxv27.fsf@lifelogs.com> <8739ofxqf8.fsf@lifelogs.com> <87mxmm47hm.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1296159655 4466 80.91.229.12 (27 Jan 2011 20:20:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Jan 2011 20:20:55 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M24402@lists.math.uh.edu Thu Jan 27 21:20:51 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PiYKo-0006vh-27 for ding-account@gmane.org; Thu, 27 Jan 2011 21:20:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PiYKI-0003Tq-2Y; Thu, 27 Jan 2011 14:20:18 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PiYKG-0003Th-8j for ding@lists.math.uh.edu; Thu, 27 Jan 2011 14:20:16 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PiYKE-00032j-Dd for ding@lists.math.uh.edu; Thu, 27 Jan 2011 14:20:15 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PiYKD-0001mG-Ll for ding@gnus.org; Thu, 27 Jan 2011 21:20:13 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PiYKD-0006Vv-J1 for ding@gnus.org; Thu, 27 Jan 2011 21:20:13 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2011 21:20:13 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2011 21:20:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 115 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 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" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:W9K6a8p2BTpctOBBhiLqMfq9Ux8= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76050 Archived-At: On Thu, 27 Jan 2011 17:49:25 +0100 Michael Albinus wrote: MA> Ted Zlatanov writes: >> I added this option, which seems necessary for extensibility: >> >> :create-extra-keys ((A \"default a\") (B)) means that the extra >> keys A and B will be created when a new entry is created. If >> SPEC had values for A or B, the user will not be prompted, but >> otherwise the user will be prompted for A (with default value as >> given) and for B (with no default). MA> Is it necessary to pass them as list with the keyword :create-extra-keys? MA> Just allow them to be added to SPEC, and if they don't belong to the MA> well known keywords, they are ignored during search, and used during MA> creation. The problem is that you don't know which SPEC keywords should be used for creation and some backends may not support some keywords. I'd rather make it explicit, where there's a base list (for netrc: host user protocol secret) and the user can augment it. That's also the only way to pass the default prompt, meaning a value we'd like to suggest to the user but which they can override. For example this: (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1 :create t :create-extra-keys '((A "default A") (B))) will prompt for A with "default A" as the default, but without a default for B; if the user just hits RET all the way, they'll get the A key in the netrc file but not the B key since it got a nil value. MA> Something else I've seen during reading: If we create a new secret, we MA> use the *first* entry in from auth-sources as container. This is not MA> documented IIRC, but auth-source-user-or-password is implemented like this. MA> If a key comes with multiple values (like ":host (X Y Z)"), the *last* MA> value is taken for creation. Sounds like a headache to me. Couldn't we MA> always use the first entry? OK. That was broken (lists of values were throwing errors) anyhow in the version I posted but I've fixed it in my copy (patch appended). I wonder if the way I'm doing it should be improved, though. I'm setting the symbol value directly with `set' on uninterned symbols. That could bite me. Maybe I should use `letf' instead. On Thu, 27 Jan 2011 13:35:57 +0100 Michael Albinus wrote: MA> Ted Zlatanov writes: >> Regarding caching, I think the cache key will be a serialized version of >> SPEC that expires when the file is modified or after a minute. I really >> don't like caching this information, though; I'd rather force the client >> to cache those results if it makes sense. So I may be annoying and >> remove `auth-source-do-cache' and all the related code altogether. MA> What about using password-cache? If a user does not like password MA> caching (for security reasons, or so), she could set password-cache to nil. MA> There is no need for an additional auth-source-do-cache then. Hmmm. But we're caching more than the password. It could work if the key was not required to be a valid symbol name, so it could be a serialized SPEC (the value doesn't have any restrictions). Right now password-cache-* won't work. Ted Index: auth-source.el =================================================================== --- auth-source.el (revision 5275) +++ auth-source.el (working copy) @@ -349,12 +349,14 @@ specified parameters except :max will be used in the new token, so if you searched for :host X you would create a token with that parameter. When multiple parameters are specified in the search, -the last one is used for creation. So :host (X Y Z) would create -a token for host Z, for instance. +the first one is used for creation. So :host (X Y Z) would create +a token for host X, for instance. This creation can fail if the search was not specific enough to create a new token (it's up to the backend to decide that). You -should `catch' the backend-specific error as usual. +should `catch' the backend-specific error as usual. Some +backends (netrc, at least) will prompt the user rather than throw +an error. :create-extra-keys ((A \"default a\") (B)) means that the extra keys A and B will be created when a new entry is created. If @@ -629,6 +631,10 @@ (file (oref backend source)) (add "")) + (dolist (r required) + (when (and (symbol-value r) (listp (symbol-value r))) + (set r (nth 0 (symbol-value r))))) + ;; for each required element (dolist (r required) (let* ((data (if (member r base-required) (symbol-value r) nil)) @@ -692,6 +698,15 @@ (with-temp-buffer (when (file-exists-p file) (insert-file-contents file)) + (when auth-source-gpg-encrypt-to + ;; (see bug#7487) making `epa-file-encrypt-to' local to + ;; this buffer lets epa-file skip the key selection query + ;; (see the `local-variable-p' check in + ;; `epa-file-write-region'). + (unless (local-variable-p 'epa-file-encrypt-to (current-buffer)) + (make-local-variable 'epa-file-encrypt-to)) + (if (listp auth-source-gpg-encrypt-to) + (setq epa-file-encrypt-to auth-source-gpg-encrypt-to))) (goto-char (point-max)) ;; ask AFTER we've successfully opened the file