Ted Zlatanov <tzz@lifelogs.com> writes:

> I added Secrets API support (search only, no create or delete) and
> `auth-source-user-or-password' compatibility, plus I rebased the
> branch.  I think the Secrets API should use the :max parameter if
> possible so we don't get too many results at the top level.  Also it
> seems quite slow to get the results one by one so maybe we can optimize
> `secrets-search-items'.

`secrets-search-items' returns already a list of results. It is slow to
get all attributes and secret strings of the items sequentially;
unfortunately there is no D-Bus method to get them in a bunch (for
several items at once).

I've changed `auth-source-secrets-search' such a way that it does not call
`secrets-get-secret', this call is moved to the returned function. This
should reduce the number of D-Bus calls in `auth-source-secrets-search'.

>  Finally, Google Chrome stores passwords in there but with a different
> scheme.  I wonder if it's useful to add specific support for mapping
> those to the auth-source tokens (host, protocol, user) or if I should
> put that special code in url.el only.

This is a disadvantage of the Secret Service API (IMO): it defines
access methods for the storage, but it does not define default
keys/attributes. Every application is free to use its own
attributes. For reuse of existing, we must either do some assumptions,
or we must inspect which attributes are already used, and apply them.

> The `auth-source-user-or-password' wrapper tries to create an entry
> currently, which is not OK.  So it's not ready for use.  When I think
> it's OK, I'll update the manual and merge the branch back into the
> master branch.

I haven't tested this function (yet).

My patch is enclosed.

> Ted

Best regards, Michael.