From: Ted Zlatanov <tzz@lifelogs.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Chong Yidong <cyd@gnu.org>, Roland Winkler <winkler@gnu.org>,
9113@debbugs.gnu.org, Achim Gratz <Stromeko@nexgo.de>,
Michael Albinus <michael.albinus@gmx.de>
Subject: bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg
Date: Tue, 31 Jan 2012 06:11:32 -0500 [thread overview]
Message-ID: <87liooyvmj.fsf_-_@lifelogs.com> (raw)
In-Reply-To: <87fwexduac.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 30 Jan 2012 17:33:47 +0100, Tue, 31 Jan 2012 14:55:57 +0800, Mon, 30 Jan 2012 17:36:51 +0100, Mon, 30 Jan 2012 17:18:30 -0500, Tue, 31 Jan 2012 10:00:32 +0100, Mon, 30 Jan 2012 23:21:19 +0100")
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
next prev parent reply other threads:[~2012-01-31 11:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 3:08 bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg Roland Winkler
2012-01-25 20:18 ` Ted Zlatanov
2012-01-26 2:02 ` Stefan Monnier
2012-01-26 15:32 ` Ted Zlatanov
2012-01-26 17:28 ` Stefan Monnier
2012-01-26 17:52 ` Lars Ingebrigtsen
2012-01-26 17:53 ` Achim Gratz
2012-01-26 20:01 ` bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, " Ted Zlatanov
2012-01-26 21:41 ` Stefan Monnier
2012-01-30 16:36 ` Lars Ingebrigtsen
2012-01-30 22:18 ` Stefan Monnier
2012-01-30 22:21 ` Lars Ingebrigtsen
2012-01-31 9:00 ` Michael Albinus
2012-01-31 17:51 ` Stefan Monnier
2012-02-13 17:35 ` Ted Zlatanov
2012-02-13 18:35 ` Michael Albinus
2012-01-27 1:47 ` bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, " Daiki Ueno
2012-01-27 16:23 ` Ted Zlatanov
2012-01-29 9:50 ` Daiki Ueno
2012-01-30 16:33 ` bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg, " Lars Ingebrigtsen
2012-01-31 6:55 ` Chong Yidong
2012-01-31 11:57 ` Lars Ingebrigtsen
2012-02-03 17:14 ` Kevin Rodgers
2012-01-31 11:11 ` Ted Zlatanov [this message]
2012-01-31 11:37 ` Michael Albinus
2012-02-13 17:38 ` Ted Zlatanov
2012-01-28 8:47 ` Roland Winkler
2012-01-28 19:05 ` Lars Ingebrigtsen
2012-01-28 19:32 ` Roland Winkler
2012-01-30 16:18 ` Lars Ingebrigtsen
2012-01-30 18:49 ` Roland Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87liooyvmj.fsf_-_@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=9113@debbugs.gnu.org \
--cc=Stromeko@nexgo.de \
--cc=cyd@gnu.org \
--cc=larsi@gnus.org \
--cc=michael.albinus@gmx.de \
--cc=winkler@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.