Re: auth-source change default spec

[Tim Cross]

Hi  Ted,

I'm a bit concerned I've not been clear enough on the precise issue we
encountered as some of what you wrote appears to contradict the
experience we had. I will try to re-state the issue to ensure we are
all talking about the same thing.

Recently, I added support for auth-sources to a package which provides
integration with various google services. Previously, the password was
only requested interactively when you used one of the services.
However, the addition by google of two step authentication and special
application passwords has made this approach less appealing.

Adding the support for auth-sources was trivial and essentially, we
used a version of the example given in the auth-sources manual.
Initial testing worked fine. However, we then found a user who ran
into problems. Once they had run the code and added their google
credentials, other systems, such as smtpmail, ceased to work.

After some debugging, we found the problem. The new credentials had
been added to ~/.authinfo, but the user already had a .authinfo.gpg
file.

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

If the search functionality had searched all avaialable files, the
issue probably would not have come up. However, this does highlight my
other concern. If I have a .authinfo.gpg file and auth-sources knows I
have the file (it has already prompted for the passphrase in the
initial search) and has failed to find the resource and has prompted
for the values and then prompts to save those values, I think it
should save them (or at least offer to save them) to the most secure
version it knows about i.e. .authinfo.gpg. With the existing setup, it
is very easy for the user to be under a false sense of security - they
have setup an .authinfo.gpg file, obviously have the necessary
supporting programs etc and I think they should expect that a program
which offers to save new credentials will use the more secure method
when it already knows the gpg file exists. My suggestion to make
.authinfo.gpg the first default was another way to ensure this, though
given the lack of support for such encryption on some platforms, the
better solution would be to use the most secure method auth-sources
knows is available by default. or at the very least use whatever the
user is using.

The problem with expecting users being required to edit the
auth-sources file is that they may encounter the auth-sources library
as a side effect of running some other program. The user is not
required to configure anything in order to enable auth-sources. I
think this creates a slight inconsistency. To obtain secure behaviour,
the user must edit a value they may not even know about for a library
they have made no concious decision to use. However, if the above two
points were addressed i.e. searching and using the most secure file
known about by default, this is much less of an issue IMO.

Tim

2012/5/2 Ted Zlatanov <address@hidden>:
> On Mon, 30 Apr 2012 14:51:24 +0200 Richard Riley <address@hidden> wrote:
>
> RR> I would expect [`auth-sources'] should default to the most
> RR> secure. And allow fall through on the search. Should you really
> RR> want, for some really obscure reason, to prefer a plain text file
> RR> for secure passwords over the .gpg then some sort of override could
> RR> be implemented. I know I'd be pretty miffed if I saved passwords
> RR> thinking they were going into .gpg only to have them read out to me
> RR> at a later date by someone who got hold of the plaintext file.
>
> The prompt clearly says "add entry to authinfo/authinfo.gpg?" when
> entries are added automatically, and if you edit manually you should
> know what you're editing.
>
> The fall-through works just fine.  But if an entry is in the first file
> in `auth-sources', and :max 1 is specified, there's no need to open a
> bunch of files when we have an answer already.
>
> On Tue, 1 May 2012 08:41:49 +1000 Tim Cross <address@hidden> wrote:
>
> TC> For me, the main question relating to this and usability is to what
> TC> extent other platforms, like windows, will have the necessary
> TC> encryption facilities available such that having the encrypted version
> TC> as default will not result in really broken or inconvenient behaviour
> TC> for them. Not being a windows user, I cannot assess this issue.
>
> I can tell you it doesn't work on W32 and many other platforms.  We'd
> need a native implementation of the OpenPGP packet format (probably
> through libnettle).  If we had that, we could definitely use .gpg as the
> default everywhere.  libcurl (thus Git and curl, among others) would
> still be unable to use it, but at least you'd have Emacs-side consistency.
>
> TC> Regardless of the style of authinfo file being used, my issue is that
> TC> the library appears to only use the first choice in the auth-sources
> TC> list even when it knows (at least should) there is a gpg file. In this
> TC> situation, it should default to the gpg version, not to the first item
> TC> in the auth-sources spec.
>
> I disagree.  `auth-sources' specifies a search order and should not be
> rearranged by the auth-source.el library.
>
> TC> Unfortunately,, I don't think asking the user to edit the auth-sources
> TC> list is the right answer.
>
> I think it's the only answer.  Why is it a problem to ask the user to do
> `M-x customize-variable auth-sources'?  It's completely analogous with
> the rest of Emacs' customization UI.
>
> TC> I think this can be resolved fairly easily. If auth-sources has
> TC> already found a .authinfo.gpg file in it's initial search, then that
> TC> should become the default file to sotre new credentials, regardless
> TC> of what is first in auth-sources.
>
> I don't want to change the simple, clear logic of "save to the first
> place you can."  Otherwise you'd have to pick between saving to
> plist-store, Secrets API, or .gpg file.  Which one is right?
>
> TC> In addition, it would be good to allow the user to [change] the
> TC> destination filename at the prompt when asked if they want to save
> TC> the current credentials.
>
> That's a good idea.  Maybe offer a choice between the various entries in
> `auth-sources' that can save.
>
> TC> Not also, the auth-sources manual is a bit misleading. It states that
> TC> the gpg version will be searched first. If I understand correctly,
> TC> this is not the case - it depends on auth-sources.
>
> Thanks, I've updated the manual in the Gnus repo and it should make its
> way to Emacs.
>
> TC> I will also need to check the meaning of :max 1 - I thought that meant
> TC> the search should return a maximum of one result, not, as seems to be
> TC> implied by the text in that bug report, that the library would only
> TC> search a max of 1 file. Another (less desirable) solution would be for
> TC> the library to continue to search all files until either it found a
> TC> match or ran out of files. This would at least stop the bug we ran
> TC> into beause auth-source created a .authinfo file when we already had
> TC> an .authinfo.gpg file.
>
> `auth-source-search' will pass :max to each parser, which will stop when
> it finds enough entries.  So if there are 3 files and the second one has
> the entry, `auth-source-search' will open 2 files for parsing.  :max
> definitely does not refer to the number of files to check.
>
> Ted
>
>



-- 
Tim Cross