tramp-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]