emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auth-source change default spec


From: Ted Zlatanov
Subject: Re: auth-source change default spec
Date: Wed, 02 May 2012 08:25:44 -0400
User-agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)

On Wed, 2 May 2012 07:41:19 +1000 Tim Cross <address@hidden> wrote: 

TC> It seems that if the user has both an .authinfo and an .authinfo.gpg
TC> file, auth-sources is not searching both files. Note that the
TC> .authinfo file only contains the entries that were just added and that
TC> the previous entries are still only in the .authinfo.gpg file. Note
TC> also that the entries are all for different resources. The evidence is
TC> that auth-source-search is NOT searching all identified files, only
TC> the first one i.e. authinfo not authinfo.gpg even if it does not find
TC> a match for the requested resource in .authinfo. From what you write,
TC> I get the impression that this is not the expected behaviour - the
TC> search is supposed to search all available files until (in the case of
TC> :max 1) at least one match if found. This does not seem to be the
TC> case.

This is either a bug or a misconfiguration; I just tested it and the
search went to the second file for me.  Please open a bug, set
`auth-source-debug' to 'trivia, and attach the value of `auth-sources'
and the content of *Messages* to show the log output when the bug
occurs.  If you can attach the edited .authinfo* files, even better.

TC> If I have a .authinfo.gpg file and auth-sources knows I have the
TC> file (it has already prompted for the passphrase in the initial
TC> search) and has failed to find the resource and has prompted for the
TC> values and then prompts to save those values, I think it should save
TC> them (or at least offer to save them) to the most secure version it
TC> knows about i.e. .authinfo.gpg. With the existing setup, it is very
TC> easy for the user to be under a false sense of security - they have
TC> setup an .authinfo.gpg file, obviously have the necessary supporting
TC> programs etc and I think they should expect that a program which
TC> offers to save new credentials will use the more secure method when
TC> it already knows the gpg file exists

There are 4 typical backends (plist-store, Secrets API, and netrc files
which can be .gpg or not), and the place where the file is stored may be
a factor too (e.g. a .gpg file on a NFS server may be considered worse
than unencrypted locally).  So we don't know what the user considers secure.

I'd rather change the "add entry" prompt to offer a choice of places to
save the new entry, so the user can choose.  This is a rare event so it
makes sense to bring up a menu.  I really don't think the auth-source
library should decide what's most secure!

What's a good multiple-choice menu library in Emacs?  Or do I roll my
own?  I can't solve it with a one-line prompt so it has to be fairly
intelligent yet work in a TTY.  I need it to be built-in, not external.

The choices would be:

Save to:

(show contents of `auth-sources' here with an explanation)

(1) [first `auth-sources' entry]
(2) [second `auth-sources' entry]
...

(e) Customize `auth-sources'

(c) Cancel

TC> The problem with expecting users being required to edit the
TC> auth-sources file is that they may encounter the auth-sources
TC> library as a side effect of running some other program. 

...

TC> The user is not required to configure anything in order to enable
TC> auth-sources. I think this creates a slight inconsistency. To obtain
TC> secure behaviour, the user must edit a value they may not even know
TC> about for a library they have made no concious decision to
TC> use.

You are right, but making the user configure `auth-sources' the first
time it's used would really annoy many Emacs users.  I'd rather make it
work OK by default, prompt for the save place as you suggested above,
and rely on the user to be curious and customize their environment.

So if I get the menu question addressed, I'll add that menu.

Ted




reply via email to

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