bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 31 Jan 2012 12:51:48 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>>>> Or does (say) OS X (or Ubuntu) start a key chain when you log in, and
>>>> then Thunderbird consults that when it connects to the IMAP server?
>>> Exactly.  So, yes, I want Emacs to support the system's keychain tool,
>>> since it's the right solution for the job.
>> auth-sources.el supports already secrets.el, which is an interface to
>> Gnome keyring and KWallet, respectively.

SM> So that's what we should use by default when available.

I don't think secrets.el has a probing function to decide if there's
something that can talk to us via the Secrets API.  If that was
possible, we could make it the first choice.  But I'm concerned that
then we *automatically* pick one solution for some users and another for
others, and I'm going to have to support that.

On Mac OS X, I would really like to use the system keychain.  But the
bindings were never finished and I don't know enough to do it myself.

>> The problem is, that there is no default under which name a password is
>> stored there.  Every application seems to use its own naming scheme.

SM> While it is probably a problem for users, I don't think it's a problem
SM> for Emacs: it just means that the password you store with one
SM> application won't automatically work in some other application when
SM> accessing the same service on the same host.

I chose to use the netrc/authinfo format to be compatible with other
applications; I could have used something much more capable otherwise.
Similarly for keychains I think we should try to be consistent with
Firefox and Chrome, at least for HTTP/HTTPS and probably in general.
Compatibility with those applications is a big benefit to our users.

Ted