GNU bug report logs -
#9113
24.0.50; auth-sources: .authinfo versus .authinfo.gpg
Previous Next
Full log
Message #74 received at 9113 <at> debbugs.gnu.org (full text, mbox):
On Mon, 30 Jan 2012 17:33:47 +0100 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
LI> Ted Zlatanov <tzz <at> 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 <at> 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 <at> 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 <at> gnus.org> wrote:
LI> Stefan Monnier <monnier <at> 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
This bug report was last modified 13 years and 123 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.