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: Tim Cross
Subject: Re: auth-source change default spec
Date: Thu, 3 May 2012 14:09:25 +1000

On 2 May 2012 22:25, Ted Zlatanov <address@hidden> wrote:
> 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.
>

OK, will update emacs and log a bug report with recipe if I am still
able to reproduce the issue.

> 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
>
>
I agree. The ability for the user to specify/choose where the entry is
saved would be an adequate solution and provides a reasonable outcome
for the majority of users regardless of their level of concern or
configuration sophistication re: security and auth-sources.
Unfortunately, I can't recommend the best approach for menu
generation/handling.

thanks for being receptive to my comments/suggestions and the effort put in.

Tim



-- 
Tim Cross



reply via email to

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