nnimap-username

nnimap-username

[Daiki Ueno]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi,

The current nnimap/auth-source combo does not seem to support multiple
IMAP accounts on the same host/port.  How about adding `nnimap-username'
server parameter to user can specify username like:

 (setq gnus-secondary-select-methods
       '((nnimap "ueno"
                 (nnimap-address "example.org")
                 (nnimap-username "ueno"))
         (nnimap "daiki"
                 (nnimap-address "example.org")
                 (nnimap-username "daiki"))))

Here is a quick patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnimap-username.diff --]
[-- Type: text/x-patch, Size: 2690 bytes --]

=== modified file 'lisp/gnus/auth-source.el'
--- lisp/gnus/auth-source.el	2010-10-10 22:48:40 +0000
+++ lisp/gnus/auth-source.el	2010-10-25 02:30:05 +0000
@@ -325,7 +325,9 @@
               (cond
                ((equal "password" m)
                 (let ((passwd (read-passwd
-                               (format "Password for %s on %s: " prot host))))
+			       (if user
+				   (format "Password for %s on %s/%s: " user host prot)
+				 (format "Password for %s on %s: " prot host)))))
                   (cond
                    ;; Secret Service API.
                    ((consp source)

=== modified file 'lisp/gnus/nnimap.el'
--- lisp/gnus/nnimap.el	2010-10-24 22:32:38 +0000
+++ lisp/gnus/nnimap.el	2010-10-25 01:57:59 +0000
@@ -58,6 +58,9 @@
 If nnimap-stream is `ssl', this will default to `imaps'.  If not,
 it will default to `imap'.")
 
+(defvoo nnimap-username nil
+  "The IMAP username used to login.")
+
 (defvoo nnimap-stream 'ssl
   "How nnimap will talk to the IMAP server.
 Values are `ssl', `network', `starttls' or `shell'.")
@@ -263,7 +266,7 @@
 		     ?s host
 		     ?p port)))))
 
-(defun nnimap-credentials (address ports &optional inhibit-create)
+(defun nnimap-credentials (address ports &optional inhibit-create username)
   (let (port credentials)
     ;; Request the credentials from all ports, but only query on the
     ;; last port if all the previous ones have failed.
@@ -271,7 +274,7 @@
 		(setq port (pop ports)))
       (setq credentials
 	    (auth-source-user-or-password
-	     '("login" "password") address port nil
+	     '("login" "password") address port username
 	     (if inhibit-create
 		 nil
 	       (null ports)))))
@@ -410,7 +413,7 @@
 				 (nnoo-current-server 'nnimap) ports t)
 				;; Then look them up based on the
 				;; physical address.
-				(nnimap-credentials nnimap-address ports)))))
+				(nnimap-credentials nnimap-address ports nil nnimap-username)))))
 		  (setq nnimap-object nil)
 		(setq login-result (nnimap-command "LOGIN %S %S"
 						   (car credentials)
@@ -418,12 +421,12 @@
 		(unless (car login-result)
 		  ;; If the login failed, then forget the credentials
 		  ;; that are now possibly cached.
-		  (dolist (host (list (nnoo-current-server 'nnimap)
-				      nnimap-address))
+		  (dolist (host (list (list (nnoo-current-server 'nnimap) nil)
+				      (list nnimap-address nnimap-username)))
 		    (dolist (port ports)
 		      (dolist (element '("login" "password"))
 			(auth-source-forget-user-or-password
-			 element host port))))
+			 element (car host) port (nth 1 host)))))
 		  (delete-process (nnimap-process nnimap-object))
 		  (setq nnimap-object nil))))
 	    (when nnimap-object


[-- Attachment #3: Type: text/plain, Size: 25 bytes --]


Regards,
-- 
Daiki Ueno

Re: nnimap-username

[Reiner Steib]

On Mon, Oct 25 2010, Daiki Ueno wrote:

> The current nnimap/auth-source combo does not seem to support multiple
> IMAP accounts on the same host/port.

I'm not sure about the current implementation, but this used to work
for me:

,----[ ~/.authinfo ]
| machine fm  login some-long-login@fm.invalid
| machine bar login some-long-login@bar.invalid
`----

,----[ From `G e' buffers: ]
| ;;; Editing the select method for `nnimap+fm:INBOX'.
| (nnimap "fm"
|       (nnimap-address "fastmail.fm")
|       (nnimap-directory "~/Mail/var/nnimap/fm"))
|--------------------
| ;;; Editing the select method for `nnimap+bar:INBOX'.
| (nnimap "bar"
|       (nnimap-address "fastmail.fm")
|       (nnimap-directory "~/Mail/var/nnimap/bar"))
`----

<http://thread.gmane.org/v9ad72zycr.fsf@marauder.physik.uni-ulm.de>


Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: nnimap-username

[Daiki Ueno]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> The current nnimap/auth-source combo does not seem to support multiple
>> IMAP accounts on the same host/port.
>
> I'm not sure about the current implementation, but this used to work
> for me:

Aha, thanks for the information.  It works for me.

However, the current implementation automatically creates(?)
~/.authinfo.gpg, it might good to setup this easily without editing
~/.authinfo.gpg by hand.

Anyway I think this specific setting is worth being documented in
gnus*.texi or auth.texi, or is it already there?

Regards,
-- 
Daiki Ueno

auth-source tokens (was: nnimap-username)

[Ted Zlatanov]

On Mon, 25 Oct 2010 16:13:11 +0900 Daiki Ueno <ueno@unixuser.org> wrote: 

DU> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>> The current nnimap/auth-source combo does not seem to support multiple
>>> IMAP accounts on the same host/port.
>> 
>> I'm not sure about the current implementation, but this used to work
>> for me:

DU> Aha, thanks for the information.  It works for me.

DU> However, the current implementation automatically creates(?)
DU> ~/.authinfo.gpg, it might good to setup this easily without editing
DU> ~/.authinfo.gpg by hand.

DU> Anyway I think this specific setting is worth being documented in
DU> gnus*.texi or auth.texi, or is it already there?

I am working on an auth-source rewrite that will address this common
problem.  Sorry for the delay, it's been in the works for a while.  The
VM guys (Uday Reddy specifically) need this functionality as well.

The new design will work a lot more like the Secrets API: it will be
search-based and always return a list of matching tokens with
properties.  I'll provide a compatibility layer to fit with the old
auth-source API, mark the old API deprecated, and will try to ensure
that nothing will break during the transition to the new API.

Ted

Re: auth-source tokens

[Ted Zlatanov]

Here's my auth-source API proposal.  `auth-source-user-or-password' will
still be provided but this will be the main entry point.  In some ways
it's a Lisp-y interpretation of the Secrets API.

We may end up with a C implementation of some parts for security, so I'm
trying to move away from plain values and to use tokens instead.  As
you'll see at the end of the docstring, if the token's :value key holds
a function, the user has to call it (I may provide a helper function for
this).  That makes it much easier to provide secure storage for the
tokens.

Backends are searched with the same SPEC as the tokens themselves.  That
lets the user and applications define arbitrary search criteria for
backends, including the "username" mentioned earlier in this thread.  It
also simplifies the API and the auth-source internals.

:max is an important change.  It ensures we stop searching backends as
soon as we have enough tokens and defaults to 1.

:create is another important one.  It unifies create-if-missing and
delete-existing in a clean way (I think).

Because this will affect many parts of Emacs, I want feedback before I
implement it.  I've spent a lot of time thinking about this API so I
hope you'll agree it's an improvement over
`auth-source-user-or-password'.  I have some code written but didn't
append it because I'm perfectly willing to throw it away if the API has
flaws, and I think it's harder to ask for that if you see working code :)

Thanks
Ted

(defun auth-source-search (&rest spec)
  "Parse `auth-sources' for matches of the SPEC plist.

Common keys are :type, :max, :host, :protocol, and :user.

A string value is matched as a regex for the
file (netrc) backend and literally by the Secrets API.  A symbol
is matched as its string value.  All the SPEC values can be
single values or lists.

:create t means to create a token if possible.  When it is
'rewrite-existing, any matching existing token will be copied
into the new token and deleted.  This defaults to nil and will
generate an error if used with :max greater than 1..

:max N means to return at most N items (defaults to 1)

:types (A B C) means to match only tokens of types A, B, or C.
Common types include `password and `login.  Defaults to t.

:host (X Y Z) means to match only hosts X, Y, or Z as a regular
expression.  Defaults to t.

:protocol (P Q R) means to match only protocols P, Q, or R.
Defaults to t.

:K (V1 V2 V3) for any other key K will match values V1, V2, or
V3.  If any of the values are strings, they are matched as
regular expressions in the file (netrc) backend and literally in
the Secrets API.  If any are symbols, they are matched literally
as the symbol name.

Return value is a list with at most :max tokens.  Each token is a
plist with keys :backend, :value, :type, :max, :host, :protocol,
and :user, plus any other keys provided by the backend.

The token's :value key can hold a function.  In that case you must call
it to obtain the actual value."
)

Re: auth-source tokens

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> (defun auth-source-search (&rest spec)
>   "Parse `auth-sources' for matches of the SPEC plist.

The major functionality of this defun is returning hits, matching the
spec. That the function needs also to parse `auth-sources' in order to
decide where to search, is second class information. I would start with
the major information.

> Common keys are :type, :max, :host, :protocol, and :user.

You haven't mentioned :create.

> A string value is matched as a regex for the
> file (netrc) backend and literally by the Secrets API.  A symbol
> is matched as its string value.  All the SPEC values can be
> single values or lists.

Hmm, maybe we shall extend secrets.el to support also regexp search?

> :create t means to create a token if possible.  When it is
> 'rewrite-existing, any matching existing token will be copied
> into the new token and deleted.  This defaults to nil and will
> generate an error if used with :max greater than 1..

I have a vague idea what you mean with rewrite-existing, but it is not
clear from the explanation. The word `token' is not explained. It shall
be clear, that `create' means actions in the chosen backend.

> :max N means to return at most N items (defaults to 1)

Stupid remark: it shall be greater than 0 :-)

An alternative would be to allow 0, and the function just returns t or
nil, depending whether there exist a matching token.

> :types (A B C) means to match only tokens of types A, B, or C.
> Common types include `password and `login.  Defaults to t.

:type or :types? :type is used above.

I believe, this needs more explanation what :type is. Can it have other
values but `password' or `login'?

> :host (X Y Z) means to match only hosts X, Y, or Z as a regular
> expression.  Defaults to t.
>
> :protocol (P Q R) means to match only protocols P, Q, or R.
> Defaults to t.

Shall explain what you mean with this. Could be also numbers I guess
(which is different from above, which allows on symbols or strings).

You have not explained :user.

> :K (V1 V2 V3) for any other key K will match values V1, V2, or
> V3.  If any of the values are strings, they are matched as
> regular expressions in the file (netrc) backend and literally in
> the Secrets API.  If any are symbols, they are matched literally
> as the symbol name.

This duplicates the saying at the beginning.

> Return value is a list with at most :max tokens.  Each token is a
> plist with keys :backend, :value, :type, :max, :host, :protocol,
> and :user, plus any other keys provided by the backend.
>
> The token's :value key can hold a function.  In that case you must call
> it to obtain the actual value."
> )

I would say, that :value relates to :type.

Best regards, Michael.

Re: auth-source tokens

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Because this will affect many parts of Emacs, I want feedback before I
> implement it.

Looks good to me.  The only thing that needs clarification (I think) is
this: 

> :create t means to create a token if possible.  When it is
> 'rewrite-existing, any matching existing token will be copied
> into the new token and deleted.  This defaults to nil and will
> generate an error if used with :max greater than 1..

What token is created?  If you're using (for instance) '("imap"
"imaps") as the port spec, it's unclear what port spec will be used when
creating.  auth-sources/netrc/nnimap now uses the last port as the spec
when creating the token, which works OK.  Perhaps the same convention
should be used here.  Or :create should explicitly name what it's
supposed to create if the search fails.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: auth-source tokens

[Ted Zlatanov]

On Sat, 30 Oct 2010 00:15:44 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Looks good to me.  The only thing that needs clarification (I think) is
LMI> this: 

>> :create t means to create a token if possible.  When it is
>> 'rewrite-existing, any matching existing token will be copied
>> into the new token and deleted.  This defaults to nil and will
>> generate an error if used with :max greater than 1..

LMI> What token is created?  If you're using (for instance) '("imap"
LMI> "imaps") as the port spec, it's unclear what port spec will be used when
LMI> creating.  auth-sources/netrc/nnimap now uses the last port as the spec
LMI> when creating the token, which works OK.  Perhaps the same convention
LMI> should be used here.  Or :create should explicitly name what it's
LMI> supposed to create if the search fails.

I clarified that, thanks.  But it's up to the backend how the creation
is implemented, and you can now request a specific backend with
:backend-types.

On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> The major functionality of this defun is returning hits, matching the
MA> spec. That the function needs also to parse `auth-sources' in order to
MA> decide where to search, is second class information. I would start with
MA> the major information.

>> Common keys are :type, :max, :host, :protocol, and :user.
MA> You haven't mentioned :create.

Both fixed.

>> A string value is matched as a regex for the
>> file (netrc) backend and literally by the Secrets API.  A symbol
>> is matched as its string value.  All the SPEC values can be
>> single values or lists.

MA> Hmm, maybe we shall extend secrets.el to support also regexp search?

It would be nice to make the interface consistent.

>> :create t means to create a token if possible.  When it is
>> 'rewrite-existing, any matching existing token will be copied
>> into the new token and deleted.  This defaults to nil and will
>> generate an error if used with :max greater than 1..

MA> I have a vague idea what you mean with rewrite-existing, but it is not
MA> clear from the explanation. The word `token' is not explained. It shall
MA> be clear, that `create' means actions in the chosen backend.

I tried to clarify it.  It may require examples.

>> :max N means to return at most N items (defaults to 1)

MA> Stupid remark: it shall be greater than 0 :-)

MA> An alternative would be to allow 0, and the function just returns t or
MA> nil, depending whether there exist a matching token.

I like that; I mentioned it.

>> :types (A B C) means to match only tokens of types A, B, or C.
>> Common types include `password and `login.  Defaults to t.

MA> :type or :types? :type is used above.

MA> I believe, this needs more explanation what :type is. Can it have other
MA> values but `password' or `login'?

I removed :type.  'login is just :user and 'password is :secret.  Auth
tokens should have properties, not types, to make the interface simpler.

>> :host (X Y Z) means to match only hosts X, Y, or Z as a regular
>> expression.  Defaults to t.
>> 
>> :protocol (P Q R) means to match only protocols P, Q, or R.
>> Defaults to t.

MA> Shall explain what you mean with this. Could be also numbers I guess
MA> (which is different from above, which allows on symbols or strings).

(renamed :protocol to :port)

It can be whatever you specify.  So if the netrc file says

user x port y

then it will match whatever y is.  I don't want to have the old
ambiguity of "should I say 143 or imap or imaps?"

MA> You have not explained :user.

Done.

>> :K (V1 V2 V3) for any other key K will match values V1, V2, or
>> V3.  If any of the values are strings, they are matched as
>> regular expressions in the file (netrc) backend and literally in
>> the Secrets API.  If any are symbols, they are matched literally
>> as the symbol name.

MA> This duplicates the saying at the beginning.

Gone.

>> Return value is a list with at most :max tokens.  Each token is a
>> plist with keys :backend, :value, :type, :max, :host, :protocol,
>> and :user, plus any other keys provided by the backend.
>> 
>> The token's :value key can hold a function.  In that case you must call
>> it to obtain the actual value."
>> )

MA> I would say, that :value relates to :type.

Yes, that was my intuition.  So I renamed :value to :secret, eliminated
:type, and the result is:

(defun auth-source-search (&rest spec)
  "Search or modify authentication backends according to SPEC.

This function parses `auth-sources' for matches of the SPEC
plist.  It can optionally create or update an authentication
token if requested.  A token is just a standard Emacs property
list with a :secret property that can be a function; all the
other properties will always hold scalar values.

Typically the :secret property, if present, contains a password.

Common search keys are :max, :host, :port, and :user.  In
addition, :create specifies how tokens will be updated or
created.  Finally, :backend-type can specify which backend types
you want to check.

A string value is matched as a regex for the
file (netrc) backend and literally by the Secrets API.  A symbol
is matched as its string value.  All the SPEC values can be
single values or lists.

:create t means to create a token if possible.  When it is
'rewrite-existing, any matching existing token will be copied
into the new token and deleted.  This defaults to nil and will
generate an error if used with :max greater than 1.  Any
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, so :host (X Y Z) would create a token for
host Z.  This can fail if the search was not specific enough to
create a new token (it's up to the backend to decide that).

:backend-type (X Y Z) will check only those backends.  'netrc and
'secrets are the only ones supported right now.

:max N means to return at most N items (defaults to 1).  When 0
the function will return just t or nil to indicate if any matches
were found.

:host (X Y Z) means to match only hosts X, Y, or Z according to
the match rules above.  Defaults to t.

:user (X Y Z) means to match only users X, Y, or Z according to
the match rules above.  Defaults to t.

:port (P Q R) means to match only protocols P, Q, or R.
Defaults to t.

:K (V1 V2 V3) for any other key K will match values V1, V2, or
V3 (note the match rules above).

The return value is a list with at most :max tokens.  Each token
is a plist with keys :backend :host :port :user, plus any other
keys provided by the backend (notably :secret).  But note the
exception for :max 0, which see above.

The token's :secret key can hold a function.  In that case you
must call it to obtain the actual value."

)

Re: auth-source tokens

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 
>
>>> A string value is matched as a regex for the
>>> file (netrc) backend and literally by the Secrets API.  A symbol
>>> is matched as its string value.  All the SPEC values can be
>>> single values or lists.
>
> MA> Hmm, maybe we shall extend secrets.el to support also regexp search?
>
> It would be nice to make the interface consistent.

OK. I'll check next days whether secrets.el can be extended this
way. The Secrets API doesn't support it, it checks the attribute values
"... via case-sensitive string equality". That means all token must be
retrieved using only attribute matches which are *not* a regex. From the
resulting tokens those must be removed, whose attributes with regex do
not match.

I still have a comment:

> (defun auth-source-search (&rest spec)
>   "Search or modify authentication backends according to SPEC.
>
> :create t means to create a token if possible.  When it is
> 'rewrite-existing, any matching existing token will be copied
> into the new token and deleted.  This defaults to nil and will
> generate an error if used with :max greater than 1.  Any
> 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, so :host (X Y Z) would create a token for
> host Z.  This can fail if the search was not specific enough to
> create a new token (it's up to the backend to decide that).

How do you handle attributes which have a regex as value in SPEC? They
shouldn't be created with that value.

Best regards, Michael.

Re: auth-source tokens

[Ted Zlatanov]

On Sun, 14 Nov 2010 18:24:50 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 
>> 
>>>> A string value is matched as a regex for the
>>>> file (netrc) backend and literally by the Secrets API.  A symbol
>>>> is matched as its string value.  All the SPEC values can be
>>>> single values or lists.
>> 
MA> Hmm, maybe we shall extend secrets.el to support also regexp search?
>> 
>> It would be nice to make the interface consistent.

MA> OK. I'll check next days whether secrets.el can be extended this
MA> way. The Secrets API doesn't support it, it checks the attribute values
MA> "... via case-sensitive string equality". That means all token must be
MA> retrieved using only attribute matches which are *not* a regex. From the
MA> resulting tokens those must be removed, whose attributes with regex do
MA> not match.

Hrrrrm.  I guess we can pass "" and then examine the results directly.
But it sucks.  OTOH I don't see a need for substring or regex searching
for secrets anyhow, now that I think about it.  Is it really necessary?

MA> I still have a comment:
...
MA> How do you handle attributes which have a regex as value in SPEC? They
MA> shouldn't be created with that value.

Good catch.  I was thinking of them in Perl terms, where a regex is a
distinct kind of object and forgot ELisp doesn't have that luxury.  So
either we go with the plan above to allow only exact matching or we
create a special kind of object that can be passed to the search
function to indicate a regex search (and said object can carry the
creation value).

My vote is to do exact matching only.  It will produce simpler code and
will be easier to understand in the manual.  If it's going to be used
all over Emacs, it should be so.

Ted

Re: auth-source tokens

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> My vote is to do exact matching only.  It will produce simpler code and
> will be easier to understand in the manual.  If it's going to be used
> all over Emacs, it should be so.

1+

In general, one shall know the exact purpose a secret is needed for.

> Ted

Best regards, Michael.

Re: auth-source tokens

[Ted Zlatanov]

On Mon, 15 Nov 2010 05:47:22 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> In general, one shall know the exact purpose a secret is needed for.

OK, final revision I hope...  Note all backends will just throw an error
rather than changing the return value when creation fails.  I think
that's the least surprising behavior.

Ted

(defun auth-source-search (&rest spec)
  "Search or modify authentication backends according to SPEC.

This function parses `auth-sources' for matches of the SPEC
plist.  It can optionally create or update an authentication
token if requested.  A token is just a standard Emacs property
list with a :secret property that can be a function; all the
other properties will always hold scalar values.

Typically the :secret property, if present, contains a password.

Common search keys are :max, :host, :port, and :user.  In
addition, :create specifies how tokens will be updated or
created.  Finally, :backend-type can specify which backend types
you want to check.

A string value is always matched literally.  A symbol is matched
as its string value, literally.  All the SPEC values can be
single values (symbol or string) or lists thereof (in which case
any of the search terms matches).

:create t means to create a token if possible.  When it is
'rewrite-existing, any matching existing token will be copied
into the new token and deleted.  This defaults to nil and will
generate an error if used with :max greater than 1.  Any
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.

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.

:backend-type (X Y Z) will check only those backends.  'netrc and
'secrets are the only ones supported right now.

:max N means to return at most N items (defaults to 1).  When 0
the function will return just t or nil to indicate if any matches
were found.

:host (X Y Z) means to match only hosts X, Y, or Z according to
the match rules above.  Defaults to t.

:user (X Y Z) means to match only users X, Y, or Z according to
the match rules above.  Defaults to t.

:port (P Q R) means to match only protocols P, Q, or R.
Defaults to t.

:K (V1 V2 V3) for any other key K will match values V1, V2, or
V3 (note the match rules above).

The return value is a list with at most :max tokens.  Each token
is a plist with keys :backend :host :port :user, plus any other
keys provided by the backend (notably :secret).  But note the
exception for :max 0, which see above.

The token's :secret key can hold a function.  In that case you
must call it to obtain the actual value."

)

Re: auth-source tokens

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, final revision I hope...  Note all backends will just throw an error
> rather than changing the return value when creation fails.  I think
> that's the least surprising behavior.

I'm OK with this. The auth-sources info pages might show some examples,
though.

> Ted

Best regards, Michael.

auth-source.el rewrite (was: auth-source tokens)

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On Mon, 15 Nov 2010 17:03:30 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> OK, final revision I hope...  Note all backends will just throw an error
>> rather than changing the return value when creation fails.  I think
>> that's the least surprising behavior.

MA> I'm OK with this. The auth-sources info pages might show some examples,
MA> though.

Attached is a version of auth-source.el I finally did over the weekend
that implements:

1) defclass auth-source-backend (using eioio) which gives us a lot of
flexibility, including the ability to let users customize the backends
directly.

2) accepts auth-sources in the format '("~/.authinfo.gpg" "~/.authinfo")
and the other ones that Customize can produce through the function
auth-source-backend-parse

3) auth-source-search (the documentation is mostly unchanged, except for
"You probably want at least a :secret property if you specify
:create.").  It returns early if :max is set.

4) netrc backend: auth-source-netrc-parse, auth-source-netrc-normalize,
auth-source-netrc-search; not done: auth-source-netrc-create.  This
removes the dependency on netrc.el and simplifies things a bit.  Note
the alist-to-plist rewrite and key aliasing are done in
auth-source-netrc-normalize.  I didn't want to rewrite
auth-source-netrc-parse too much from the starting point of
netrc-parse.  Also note the :secret key is a function now and clients
have to expect that.  I think that's a good thing.

Everything after 

;;; older API

is unchanged from before and will probably be rewritten.

Look it over and let me know what you think.  I'm still not sure how the
creation should work exactly and hope you will tell me how the rewrite
"feels," especially considered against the Secrets API.

Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 37306 bytes --]

Re: auth-source.el rewrite

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Look it over and let me know what you think.  I'm still not sure how the
> creation should work exactly and hope you will tell me how the rewrite
> "feels," especially considered against the Secrets API.

I've skimmed the code, and it looks very nice to me.  But I still
haven't familiarised myself with the Secrets API, so I can't really
comment there...

So should we(*) just alter nnimap to use the new auth-source API and drop
it into git Gnus?  Usually the best way to get the feel of how stuff
works is to use it.

---
*) I.e., you.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: auth-source.el rewrite

[Ted Zlatanov]

On Mon, 24 Jan 2011 15:36:58 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Look it over and let me know what you think.  I'm still not sure how the
>> creation should work exactly and hope you will tell me how the rewrite
>> "feels," especially considered against the Secrets API.

LI> I've skimmed the code, and it looks very nice to me.  But I still
LI> haven't familiarised myself with the Secrets API, so I can't really
LI> comment there...

LI> So should we(*) just alter nnimap to use the new auth-source API and drop
LI> it into git Gnus?  Usually the best way to get the feel of how stuff
LI> works is to use it.

LI> *) I.e., you.

I don't want to affect all the people using auth-source.el currently.
Remember it's not just a Gnus facility.  So I wanted to get the API
settled before comitting.  Michael Albinus will probably know if the API
makes sense in terms of the Secrets API; I think it should couple OK.

The biggest problem is creation IMO.  I think each backend will need its
own list of required keys (always including :host, :secret and :user)
and when the search query is not sufficient to fulfill the requirements,
the user will be prompted for those values.  It still feels clumsy.

Ted

Re: auth-source.el rewrite

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I don't want to affect all the people using auth-source.el currently.
> Remember it's not just a Gnus facility.  So I wanted to get the API
> settled before comitting.  Michael Albinus will probably know if the API
> makes sense in terms of the Secrets API; I think it should couple OK.

It's already on my todo list. I hope I find a free time slot for test,
latest the weekend.

I owe also the SS section for the auth-sources manual ...

> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Ted Zlatanov]

On Tue, 25 Jan 2011 22:09:19 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I don't want to affect all the people using auth-source.el currently.
>> Remember it's not just a Gnus facility.  So I wanted to get the API
>> settled before comitting.  Michael Albinus will probably know if the API
>> makes sense in terms of the Secrets API; I think it should couple OK.

MA> It's already on my todo list. I hope I find a free time slot for test,
MA> latest the weekend.

Thanks but don't worry about testing, just look at the API and the code.
I haven't written anything for the Secrets API so you have to use the
netrc backend as a sample implementation.

MA> I owe also the SS section for the auth-sources manual ...

No rush on that, especially with the API changes I'm making.

Ted

Re: auth-source.el rewrite

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Thanks but don't worry about testing, just look at the API and the code.
> I haven't written anything for the Secrets API so you have to use the
> netrc backend as a sample implementation.

OK, but short tests help me to understand the API better. And if it
comes to creation of new entries, I would like to *see* how it works.

> MA> I owe also the SS section for the auth-sources manual ...
>
> No rush on that, especially with the API changes I'm making.

Don't say that! It will keep me silent for months!

> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Ted Zlatanov]

On Wed, 26 Jan 2011 09:32:42 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Thanks but don't worry about testing, just look at the API and the code.
>> I haven't written anything for the Secrets API so you have to use the
>> netrc backend as a sample implementation.

MA> OK, but short tests help me to understand the API better. And if it
MA> comes to creation of new entries, I would like to *see* how it works.

Bah.  Now I have to write auth-source-netrc-create before the weekend :)

Ted

Re: auth-source.el rewrite

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MA> OK, but short tests help me to understand the API better. And if it
> MA> comes to creation of new entries, I would like to *see* how it works.
>
> Bah.  Now I have to write auth-source-netrc-create before the weekend :)

For the rest, I've played already around. In general, the new API looks
good to me. Appended is a patch for some few minor things I've observed
during the game.

And now waiting for the creation thingie ...

> Ted

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3582 bytes --]

*** /home/albinus/lisp/auth-source.el.~1~	2011-01-25 13:55:05.000000000 +0100
--- /home/albinus/lisp/auth-source.el	2011-01-26 17:41:59.223404487 +0100
***************
*** 41,46 ****
--- 41,47 ----
  
  (require 'gnus-util)
  (require 'netrc)
+ (require 'assoc)
  (eval-when-compile (require 'cl))
  (eval-when-compile (require 'eieio))
  
***************
*** 93,104 ****
  
  ;;(auth-source-backend "netrc" :type 'netrc)
  
- (defcustom auth-source-do-cache t
-   "Whether auth-source should cache information."
-   :group 'auth-source
-   :version "23.2" ;; No Gnus
-   :type `boolean)
- 
  (defcustom auth-source-protocols '((imap "imap" "imaps" "143" "993")
                                     (pop3 "pop3" "pop" "pop3s" "110" "995")
                                     (ssh  "ssh" "22")
--- 94,99 ----
***************
*** 173,179 ****
  It's best to customize this with `M-x customize-variable' because the choices
  can get pretty complex."
    :group 'auth-source
!   :version "23.2" ;; No Gnus
    :type `(repeat :tag "Authentication Sources"
                   (choice
                    (string :tag "Just a file")
--- 168,174 ----
  It's best to customize this with `M-x customize-variable' because the choices
  can get pretty complex."
    :group 'auth-source
!   :version "24.1" ;; No Gnus
    :type `(repeat :tag "Authentication Sources"
                   (choice
                    (string :tag "Just a file")
***************
*** 216,222 ****
    "List of recipient keys that `authinfo.gpg' encrypted to.
  If the value is not a list, symmetric encryption will be used."
    :group 'auth-source
!   :version "23.2" ;; No Gnus
    :type '(choice (const :tag "Symmetric encryption" t)
                   (repeat :tag "Recipient public keys"
                           (string :tag "Recipient public key"))))
--- 211,217 ----
    "List of recipient keys that `authinfo.gpg' encrypted to.
  If the value is not a list, symmetric encryption will be used."
    :group 'auth-source
!   :version "24.1" ;; No Gnus
    :type '(choice (const :tag "Symmetric encryption" t)
                   (repeat :tag "Recipient public keys"
                           (string :tag "Recipient public key"))))
***************
*** 592,598 ****
  "Given a property list SPEC, return search matches from the :backend.
  See `auth-source-search' for details on SPEC."
    ;; just in case, check that the type is correct
!   (assert (eq type (oref backend type)))
  
    (let ((results (auth-source-netrc-normalize
                    (auth-source-netrc-parse
--- 587,593 ----
  "Given a property list SPEC, return search matches from the :backend.
  See `auth-source-search' for details on SPEC."
    ;; just in case, check that the type is correct
!   (assert (or (null type) (eq type (oref backend type))))
  
    (let ((results (auth-source-netrc-normalize
                    (auth-source-netrc-parse
***************
*** 860,866 ****
             host protocol username)
            found)                        ; return the found data
        ;; else, if not found
!       (let ((choices (apply 'auth-source-pick search)))
          (dolist (choice choices)
            (if delete-existing
                (apply 'auth-source-delete choice search)
--- 855,861 ----
             host protocol username)
            found)                        ; return the found data
        ;; else, if not found
!       (let ((choices (apply 'auth-source-search search)))
          (dolist (choice choices)
            (if delete-existing
                (apply 'auth-source-delete choice search)

Re: auth-source.el rewrite

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Wed, 26 Jan 2011 20:35:34 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
MA> OK, but short tests help me to understand the API better. And if it
MA> comes to creation of new entries, I would like to *see* how it works.
>> 
>> Bah.  Now I have to write auth-source-netrc-create before the weekend :)

MA> For the rest, I've played already around. In general, the new API looks
MA> good to me. Appended is a patch for some few minor things I've observed
MA> during the game.

I applied your patch to my copy (attached below).

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> And now waiting for the creation thingie ...

OK, I'll aim for that to be done soon.

Thanks
Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 37257 bytes --]

Re: auth-source.el rewrite

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Wed, 26 Jan 2011 14:35:12 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 26 Jan 2011 20:35:34 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 
MA> And now waiting for the creation thingie ...

TZ> OK, I'll aim for that to be done soon.

This was fairly easy (though the code looks messy, but that's because
humans can't parse nils).  It omits any values if the user doesn't enter
them, including the password.  I think the :secret key should not be
required on creation, after considering the alternative is to read the
password anyhow.  So I've removed that requirement from the docs and the
code.

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).

This version writes the serialized data with the %S format so spaces in
the input are not a problem, and with :create-extra-keys it will add
those extra keys to the output line, prompting for them with a default
value as indicated in the `auth-source-search' docs.

I'm pretty happy with this.  The Secrets API support still needs to be
done before it's pushed out, though.

Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 41351 bytes --]

Re: auth-source.el rewrite

[Michael Albinus]

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.

What about using password-cache? If a user does not like password
caching (for security reasons, or so), she could set password-cache to nil.

There is no need for an additional auth-source-do-cache then.

> Thanks
> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Michael Albinus]

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).

Is it necessary to pass them as list with the keyword :create-extra-keys?
Just allow them to be added to SPEC, and if they don't belong to the
well known keywords, they are ignored during search, and used during creation.

Something else I've seen during reading: If we create a new secret, we
use the *first* entry in from auth-sources as container. This is not
documented IIRC, but auth-source-user-or-password is implemented like this.

If a key comes with multiple values (like ":host (X Y Z)"), the *last*
value is taken for creation. Sounds like a headache to me. Couldn't we
always use the first entry?

> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Ted Zlatanov]

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

Re: auth-source.el rewrite

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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)))

This results in 

Debugger entered--Lisp error: (void-variable A)
  symbol-value(A)
  (and (symbol-value r) (listp (symbol-value r)))

For me, the argument list looks a little bit ugly. Couldn't we merge at
least :create and :create-extra-keys, and use keys for the extra keys?
Something like

(auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
:create '(:A "default A" :B))

The value for :create could also be t, when there are no extra
keys. :replace-existing could be a special key in the list, which is not
added to the new entry.

> 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.

Any string works as key. In Tramp, I do it similar (serializing method,
user, host, protocol). No big deal.

> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Sat, 29 Jan 2011 15:11:48 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

>> 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)))

MA> This results in 

MA> Debugger entered--Lisp error: (void-variable A)
MA>   symbol-value(A)
MA>   (and (symbol-value r) (listp (symbol-value r)))

I think I'll just keep all the values in an alist instead of setting
symbol values.  It will simplify the code, too.

MA> For me, the argument list looks a little bit ugly. Couldn't we merge at
MA> least :create and :create-extra-keys, and use keys for the extra keys?
MA> Something like

MA> (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
MA> :create '(:A "default A" :B))

MA> The value for :create could also be t, when there are no extra
MA> keys. :replace-existing could be a special key in the list, which is not
MA> added to the new entry.

You're right that it's ugly.  How about a simple alist
`auth-source-creation-defaults' that can be let-bound around the
function call?  Then the default prompts would not be necessary and we
can just have

(let ((auth-source-creation-defaults '((user "defaultUser") (A "default A"))))
  (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1 
                      :create '(A B)))

which would say "If you have to prompt for the user or A, use those
default prompts.  There is no default for B but it should be in the new
entry."

That removes a lot of special cases in the arguments so I like it.  Also
it gives us a way to override the default prompt for the required keys
(host user protocol) for the netrc backend, which was not allowed before.

I think I should eliminate the :replace-existing mode.  It's confusing
to merge search and conditional creation like that.  All the :max 1
conditions were just a pain for both the library and the API user.  I'd
rather provide a deletion facility so we can say

(when (setq entry (nth 0 (auth-source-search spec)))
...
  (when (auth-source-delete entry)
     ... modify entry as needed, adding :create t or whatever else
     (setq success (apply 'auth-source-search entry))))

I put a full example for the :create option in the docs, see the
attached source below.  It's not implemented, just the docs are done.
What do you think?  I like it better, it's clear what it does and how it
does it.  Also I made creation include only the keys in :create, not any
search key.

MA> Any string works as [password-cache] key. In Tramp, I do it similar
MA> (serializing method, user, host, protocol). No big deal.

Oh, OK.  Looking at the source, I thought it was a problem.  Thanks for
explaining.

Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 43176 bytes --]

Re: auth-source.el rewrite

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I put a full example for the :create option in the docs, see the
> attached source below.  It's not implemented, just the docs are done.
> What do you think?  I like it better, it's clear what it does and how it
> does it.  Also I made creation include only the keys in :create, not any
> search key.

Let's do it this way.

> Ted

Best regards, Michael.

Re: auth-source.el rewrite

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Mon, 31 Jan 2011 15:30:25 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I put a full example for the :create option in the docs, see the
>> attached source below.  It's not implemented, just the docs are done.
>> What do you think?  I like it better, it's clear what it does and how it
>> does it.  Also I made creation include only the keys in :create, not any
>> search key.

MA> Let's do it this way.

OK, working version attached.  As we discussed, it does not have a
:rewrite-existing or :create-extra-keys option.

I added two working examples to the docs to demonstrate
`auth-source-creation-defaults' and the two :create modes.  They should
be sufficient to show the usage.

I made deletion happen with a :delete t parameter and implemented it (by
commenting out the line) for the netrc backend.  `auth-source-delete'
just calls `auth-source-search' with :delete overridden to t.  The
deleted entry is returned.  I think all of that is reasonable.

I hope this is the last API iteration.  Sorry for the long discussion; I
wanted to make sure we'd have something usable for everyone.  If we
settle on this, I'll add the search result caching and start on the
Secrets API implementation.  Then I'll do the manual update...

I considered making a Git branch for this work but was too lazy.  Sorry
for the constant inconvenience of looking at attachments.

Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 46739 bytes --]