From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.bugs Subject: bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg Date: Sat, 28 Jan 2012 02:47:53 -0600 Message-ID: <20259.46649.66744.396059@gargle.gargle.HOWL> References: <87mxgcffq1.fsf@niu.edu> <87k44ffsdu.fsf@lifelogs.com> <87aa5aa38p.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1327740510 14642 80.91.229.12 (28 Jan 2012 08:48:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Jan 2012 08:48:30 +0000 (UTC) Cc: 9113@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 28 09:48:26 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rr3xQ-00042c-8p for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Jan 2012 09:48:24 +0100 Original-Received: from localhost ([::1]:51514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rr3xP-00075W-Gs for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Jan 2012 03:48:23 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rr3xN-00075R-AD for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2012 03:48:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rr3xM-0004Oj-Al for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2012 03:48:21 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rr3xM-0004Of-33 for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2012 03:48:20 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rr3y2-0005SW-4u for bug-gnu-emacs@gnu.org; Sat, 28 Jan 2012 03:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Roland Winkler" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jan 2012 08:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9113 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9113-submit@debbugs.gnu.org id=B9113.132774052420960 (code B ref 9113); Sat, 28 Jan 2012 08:49:02 +0000 Original-Received: (at 9113) by debbugs.gnu.org; 28 Jan 2012 08:48:44 +0000 Original-Received: from localhost ([127.0.0.1]:47466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rr3xk-0005S1-3X for submit@debbugs.gnu.org; Sat, 28 Jan 2012 03:48:44 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:41605 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rr3xh-0005Ru-Ox for 9113@debbugs.gnu.org; Sat, 28 Jan 2012 03:48:43 -0500 Original-Received: from 82.red-80-32-229.staticip.rima-tde.net ([80.32.229.82]:37644 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1Rr3x0-0001rx-50; Sat, 28 Jan 2012 03:47:59 -0500 In-Reply-To: <87aa5aa38p.fsf@lifelogs.com> X-Mailer: VM 8.2 trial under 24.0.92.1 (x86_64-unknown-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:56116 Archived-At: On Thu Jan 26 2012 Ted Zlatanov wrote: > I don't recall exactly either. But here's how we can proceed. We have > several options: > > 1) go back to authinfo.gpg as the first choice > > 2) use unencrypted authinfo with encrypted password tokens, which looks like > this: > > machine supertest password > gpg:jA0EAwMC2tUEaZgM7A5gyWM/owySdCOS/cjoFCuf8LI1d1kYX7z6cjsNkakM04u1geh/iesqyH3XQFI+SEVLb/oEC/EoQ0LIgRRoBiLyu9XZWN1ytY7MQxpPZniFz13oGV4/Dwl8yrP3Hba5LfQpHy2FZRM= > > 3) work on the libnettle support (automatic if we use GnuTLS) so the > external GPG executable is not needed to generate encrypted password > tokens or encrypted authinfo files > > 4) use Daiki Ueno's plist storage format (already in auth-source but not > well tested AFAIK) > > 5) ask the user if he has no authinfo file what he wants to do, and > choose sensible defaults from the above depending on whether EPA/EPG and > GPG; or libnettle are available. If we do that, `auth-sources' will be > set to 'ask by default. For me, being a user who does not know too much about the subtleties of "smart solutions" for this problem, it would already be helpful if the relevant docstrings / info pages / a *Warnings* buffer contained a warning like It is highly recommended to store the file .authinfo as an encrypted file as .authinfo.gpg, though in some cases such a solution can be inconvenient or otherwise problematic. On the other hand, describe-variable currently gives for auth-sources auth-sources is a variable defined in `auth-source.el'. Its value is ("~/.authinfo" "~/.authinfo.gpg" "~/.netrc") Documentation: List of authentication sources. The default will get login and password information from "~/.authinfo.gpg", which you should set up with the EPA/EPG packages to be encrypted. If that file doesn't exist, it will try the unencrypted version "~/.authinfo" and the famous "~/.netrc" file. See the auth.info manual for details. What general scheme of precedence is implemented here if auth-sources is a list and the "default value" in this list is not the first or last one, but the second? Or is this just a bug in the docstring? For this problem, I cannot find helpful comments in the auth.info manual either. I suggest that the docstring of auth-sources should provide a hyperlink to the relevant section of the auth.info manual. Roland