[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Passwords, stored in Gnome Keyring and KWallet
From: |
Michael Albinus |
Subject: |
Re: Passwords, stored in Gnome Keyring and KWallet |
Date: |
Wed, 24 Feb 2010 09:28:00 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux) |
Ted Zlatanov <address@hidden> writes:
> possible TODO list, then:
>
> - secrets-debug should be structured like auth-source-debug to prevent
> leaking sensitive information. Right now I don't see anything
> sensitive though.
OK. In fact, I haven't done something useful wrt secrets-debug yet :-)
> - make part of Emacs (so both Tramp and Gnus can use it; since it
> requires a recent Emacs anyway). I think it makes sense to keep it
> out of {gnus,tramp}/contrib/ or {gnus,tramp}/lisp/ because it depends
> on specific Emacs internals. I don't know about XEmacs support but of
> course have no problem with it.
Agreed. I will offer this, after the 23.2 release.
> - possibly rename to secrets-service.el if you feel the urge or someone
> makes you do it :)
Yep. I don't feel the urge, but I will follow pressures ...
> - change auth-source.el to take '(secrets "COLL") as a auth-sources spec
> naming collection COLL. Then it will simply call
>
> (secrets-get-attribute "COLL" "hostname:port" :login)
> (secrets-get-attribute "COLL" "hostname:port" :password)
>
> to get the login and password spec. Does that seem reasonable? I
> think the host name + port should be the key for simplicity (rather
> than searching and listing collection items), but you should decide.
>
> The calls to secrets.el will be autoloaded so unless you use the
> 'secrets spec in auth-sources, you won't load the library.
I would let it to you. Allow "COLL" to be nil; then the (temporary)
collection "session" will be used. If "COLL" does not exist, you could
offer to create it on-the-fly.
However, the password is NOT an attribute. You must retrieve it with
(secrets-get-secret "COLL" "hostname:port")
And I don't know, whether "hostname:port" is sufficient as secret item
name. You might want to connect to a given host under different
identities, for example via ssh as "address@hidden" or "address@hidden". I
assume, you use different passwords then.
If you want to encode it in the secret item name, you shall use
"address@hidden:port". But I still believe it is more simple to use
attributes, because it is more convenient to *search* for an entry via
attributes, in order to know, whether it exists it already, or not.
See my test cases at the end of secrets.el. The item "address@hidden"
was creted in the login keyring by another application; it is in fact
"address@hidden".
> - write docs in auth.info on setting this up
>
> I can do the last two in that order, but need your opinion on the item
> key.
Yes, please do. We can discuss pros and cons, once it is running :-)
> Thanks!
> Ted
Best regards, Michael.