Re: tzz-auth-source-rewrite branch

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 06 Feb 2011 19:38:45 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

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

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

I'll leave it that way for now because it will be cached, but that seems
like a painful limitation long-term.

Am I correct in assuming that substring/regex searches on the attributes
are not possible?

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

Yes, but now every time the user wants the secret they will get a
surprise call and caching won't work.  So I would prefer to call
`secrets-get-secret' early.  I left that bit out of the patch, I hope
you don't mind.

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

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

I think we should support the Google Chrome schema, at least:

username_value => user
origin_url => protocol (using the protocol piece of the URL) and host
(using the host piece)

Those values won't work for creation (meaning we won't be able to create
valid Chrome entries without user assistance), but at least there's a
good chance that the user can reuse their Chrome passwords.  Is that
reasonable?  Do you know of any other software that has its own schema
like Chrome does?

Ted

p.s. Sorry about the multiple merge and commit messages on this branch.