Re: Passwords, stored in Gnome Keyring and KWallet

[Michael Albinus]

Ted Zlatanov <address@hidden> writes:

> MA> I would let it to you. Allow "COLL" to be nil; then the (temporary)
> MA> collection "session" will be used. If "COLL" does not exist, you could
> MA> offer to create it on-the-fly.
>
> We should make it Just Work.  Is there a reason not to create it on the
> fly?

Not from the functional pov. But one should restrict the number of
collections; if there are too many, it is harder to share the secrets
between different applications.

> Can the collection be guessed from the system configuration by
> secrets.el, if there's only one active collection?

In gnome-keyring, there must be at least the collection "login".
Furthermore, the Secret Service API contains an alias mechanism for
collections. The special alias "default" is mentioned explicitely, so
one could also simply use this collection. I don't know, what is more
useful; here we need some feedback for our default settings.

> MA> And I don't know, whether "hostname:port" is sufficient as secret item
> MA> name. You might want to connect to a given host under different
> MA> identities, for example via ssh as "address@hidden" or "address@hidden". I
> MA> assume, you use different passwords then.
>
> MA> If you want to encode it in the secret item name, you shall use
> MA> "address@hidden:port". But I still believe it is more simple to use
> MA> attributes, because it is more convenient to *search* for an entry via
> MA> attributes, in order to know, whether it exists it already, or not.
>
> MA> See my test cases at the end of secrets.el. The item "address@hidden"
> MA> was creted in the login keyring by another application; it is in fact
> MA> "address@hidden".
>
> Hmm, auth-source depends on the "host+protocol" key for everything.  The
> assumption is always that there's only one login per host+protocol.

Personally, I use different accounts on the remote hosts. Sometimes I
connect as address@hidden, sometimes as address@hidden etc, always via ssh.

> Can you show specifically how I would call secrets.el, given host X and
> port Y, and use the first username found (the password comes from the
> discovered object as you mentioned)?  The docs for secrets-search-items
> are incorrect so I want to be sure (though from your examples at the end
> it looks reasonably easy).

There are always lists, and you could use the car of a list as first hit.

Assume, you have created 4 items on host "remote-host":

(secrets-create-item nil "item" "geheim" :method "sudo" :user "joe" :host 
"remote-host")
(secrets-create-item nil "another item" "whatever" :method "sudo" :user 
"suzanne" :host "remote-host")
(secrets-create-item nil "now this" "42" :method "ssh" :user "ted" :host 
"remote-host")
(secrets-create-item nil "now that" "27" :method "ftp" :user "ted" :host 
"remote-host")

You can get all items for "remote-host" by this:

(secrets-search-items nil :host "remote-host")
=> ("now this" "item" "now that" "another item")

If you want to know ted's items on "remote-host", you apply

(secrets-search-items nil :user "ted" :host "remote-host")
=> ("now this" "now that")

And if you want the user names of all items on "remote-host" registered
for method (aka port) "sudo", you do:

(let (result)
  (dolist (item
           (secrets-search-items nil :method "sudo" :host "remote-host")
           result)
    (add-to-list 'result (secrets-get-attribute nil item :user))))
=> ("joe" "suzanne")

> We can make the preferred username part of the auth-sources spec like
> this (also including the secrets tag, and completely untested):
>
> (defcustom auth-sources '((:source "~/.authinfo.gpg" :host t :protocol t))
>   "List of authentication sources.
>
> Each entry is the authentication type with optional properties."
>   :group 'auth-source
>   :version "23.1" ;; No Gnus

This must be 23.2. There were some bug fixes in dbus.el since 23.1,
needed for secrets.el.

>   :type `(repeat :tag "Authentication Sources"
>                (list :tag "Source definition"
>                      (const :format "" :value :source)
>                      (choice :tag "Authentication backend choice"
>                              (string :tag "Authentication Source (file)")
>                              (list :tag "secrets.el (Secret Service 
> API/KWallet/GNOME KeyRing)" 
>                                      (const secrets)
>                                      (choice :tag "Collection to use"
>                                              (string :tag "Collection name")
>                                              (const :tag "Any" nil)
>                                              (const :tag "Temporary" temp))))

I understand the intention. However, the temporary (session) collection
in secrets.el is coded either as "session" or as nil. Maybe we can
reflect this.

>                      (const :format "" :value :host)
>                      (choice :tag "Host (machine) choice"
>                              (const :tag "Any" t)
>                              (regexp :tag "Host (machine) regular expression 
> (TODO)")
>                              (const :tag "Fallback" nil))
>                      (const :format "" :value :protocol)
>                      (choice :tag "Protocol"
>                              (const :tag "Any" t)
>                              (const :tag "Fallback" nil)
>                              ,@auth-source-protocols-customize)
>                      (const :format "" :value :preferred-username)
>                      (choice :tag "Personality or username"
>                              (const :tag "Any" t)
>                              (const :tag "Fallback" nil)
>                              (string :tag "Specific user name")))))
>
> Like I said this is untested but the point is to show the structure
> under the authentication backend choices and the optional personality
> parameter (which can be extended to mean more than just username,
> depending on the backend).  Do you think this is OK?

Yes, this looks OK.

> Then I'll simply pass the preferences as an optional list to
> auth-source-pick and take them into account when searching (so the glue
> to each backend would notice them).  I would like to make it completely
> optional, though, because a single username is by far the most common
> use case, so the above defcustom, which makes it mandatory, will
> probably not be the final version.

Let's try it.

> Ted

Best regards, Michael.