Re: auth-source.el rewrite

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 27 Jan 2011 17:49:25 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> 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 <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> 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