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

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 30 Jan 2012 17:33:47 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The encryption doesn't have to be strong.  It could use a well-known
>> secret that the user can override, rather than an actual passphrase, and
>> then no questions will be asked.

LI> Sure.  This is what Firefox (etc.) does, and (most) people seem to be
LI> satisfied with that.  On the other hand, this is just obscuring the
LI> passwords, so the difference between this and, say,

LI> machine smtp.gmail.com user foo password base64:c2VjcmV0

LI> isn't huge.  (I mean, it is a real difference, but I'm not quite sure
LI> whether it's a difference with a distinction.  :-)

LI> So perhaps auth-source should just base64-encode password tokens by
LI> default for Emacs 24.1?  That would give the users less of an "EEK"
LI> feeling if they're looking at this file, and somebody is looking over
LI> their shoulders...

On Tue, 31 Jan 2012 14:55:57 +0800 Chong Yidong <cyd@gnu.org> wrote: 

CY> Or we could rot13 it ;-)

Base64 or ROT-13 would make the encryption trivial to crack *and* would
make the tokens unusable by other programs.  I don't think it's a good
compromise.

On Tue, 31 Jan 2012 10:00:32 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> The problem is, that there is no default under which name a password
MA> is stored [in the Secrets API]. Evrery application seems to use its
MA> own naming scheme.

We can probably work around that.  I'm more concerned that there is no
standard keychain for GNU/Linux or W32.  These are completely optional
services, up to the administrator and the user to install and activate.
On most server machines, for instance, you won't find a desktop
environment with a keychain or a GPG agent, although you may find a SSH
agent.  This solution is guaranteed to work only for Mac OS X.

On Mon, 30 Jan 2012 23:21:19 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Exactly.  So, yes, I want Emacs to support the system's keychain tool,
>> since it's the right solution for the job.

LI> If that's possible, then it would indeed be a lot better than stashing
LI> the credentials in a file.

I'm not convinced it's better, see above.  In addition, it's hardly
portable: how would the user take his credentials to another machine?
Another platform?  It seems like a lock-in situation which I am not keen
to impose on our users.

As a default, it seems that storing the credential data in a temporary
in-memory auth-source backend *by default* is the best solution.  

Then on exit or on `auth-source-save', if there is something in the
in-memory backend, we can ask the user if he wants to save the passwords
and where, with all the consequent UI choices.  The user can pick a
plain file, or a plain file with password tokens, or a GPG-encrypted
file (with or without external support), or the platform's keychain
service, if available.  At that time the UI can modify `auth-sources'
for the user.

Ted