From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.bugs Subject: bug#9113: 24.0.50; auth-sources: .authinfo versus .authinfo.gpg Date: Fri, 27 Jan 2012 10:23:20 -0600 Organization: =?UTF-8?Q?=D0=A2=D0=B5=D0=BE=D0=B4=D0=BE=D1=80_?= =?UTF-8?Q?=D0=97=D0=BB=D0=B0=D1=82=D0=B0=D0=BD=D0=BE=D0=B2?= @ Cienfuegos Message-ID: <878vkt3yiv.fsf_-_@lifelogs.com> References: <87mxgcffq1.fsf@niu.edu> <87aa5aa38p.fsf@lifelogs.com> <87y5suuz85.fsf@Rainer.invalid> <87bopq6xng.fsf@lifelogs.com> <87mxgcffq1.fsf@niu.edu> <87k44ffsdu.fsf@lifelogs.com> <87aa5aa38p.fsf@lifelogs.com> <87mxgcffq1.fsf@niu.edu> <87k44ffsdu.fsf@lifelogs.com> <87aa5aa38p.fsf@lifelogs.com> <87mxgcffq1.fsf@niu.edu> <87k44ffsdu.fsf@lifelogs.com> <87aa5aa38p.fsf@lifelogs.com> <87y5suuz85.fsf@Rainer.invalid> <87bopq6xng.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327677885 21697 80.91.229.12 (27 Jan 2012 15:24:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Jan 2012 15:24:45 +0000 (UTC) Cc: 9113@debbugs.gnu.org, Lars Ingebrigtsen , Achim Gratz , Roland Winkler To: Daiki Ueno Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 27 16:24:38 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 1RqnfJ-0003vP-Mw for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jan 2012 16:24:38 +0100 Original-Received: from localhost ([::1]:38752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqnfJ-00005t-1E for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jan 2012 10:24:37 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqnfC-0008Pf-BG for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2012 10:24:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rqnf5-0004O1-Uk for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2012 10:24:30 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rqnf5-0004Np-Sz for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2012 10:24:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rqnfh-0005Gs-IO for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2012 10:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ted Zlatanov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jan 2012 15:25:01 +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.132767788020233 (code B ref 9113); Fri, 27 Jan 2012 15:25:01 +0000 Original-Received: (at 9113) by debbugs.gnu.org; 27 Jan 2012 15:24:40 +0000 Original-Received: from localhost ([127.0.0.1]:46899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqnfL-0005GH-2V for submit@debbugs.gnu.org; Fri, 27 Jan 2012 10:24:40 -0500 Original-Received: from cer-mailmxol2.jumptrading.com ([208.78.214.25]:26021) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqnfI-0005G1-7E for 9113@debbugs.gnu.org; Fri, 27 Jan 2012 10:24:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEABxsIk/AqF0N/2dsb2JhbABCrH2CWoFyAQEEAXkQCw0jFhAESQ4Fh3wIt3+JDCkQAQgBBgQDAwSEOjQCBxqDGgSIP5JUjHM Original-Received: from unknown (HELO chiexchange02.w2k.jumptrading.com) ([192.168.93.13]) by cer-mailmxol2.jumptrading.com with ESMTP; 27 Jan 2012 15:25:17 +0000 Original-Received: from internalsmtp.w2k.jumptrading.com (10.2.4.29) by chiexchange02.w2k.jumptrading.com (10.2.4.71) with Microsoft SMTP Server id 8.2.176.0; Fri, 27 Jan 2012 09:23:51 -0600 Original-Received: from tzlatanov-ubuntu-desktop.jumptrading.com ([10.2.27.110]) by internalsmtp.w2k.jumptrading.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2012 09:23:50 -0600 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: (Daiki Ueno's message of "Fri, 27 Jan 2012 10:47:32 +0900, Thu, 26 Jan 2012 16:41:19 -0500") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) X-OriginalArrivalTime: 27 Jan 2012 15:23:50.0941 (UTC) FILETIME=[AC235CD0:01CCDD07] 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:56083 Archived-At: On Fri, 27 Jan 2012 10:47:32 +0900 Daiki Ueno wrote: DU> Ted Zlatanov writes: >>>>> 2) use unencrypted authinfo with encrypted password tokens, which >>>>> looks like this: >>>> >>>>> machine supertest password >>>>> gpg:jA0EAwMC2tUEaZgM7A5gyWM/owySdCOS/cjoFCuf8LI1d1kYX7z6cjsNkakM04u1geh/iesqyH3XQFI+SEVLb/oEC/EoQ0LIgRRoBiLyu9XZWN1ytY7MQxpPZniFz13oGV4/Dwl8yrP3Hba5LfQpHy2FZRM= >> >> It works fairly well but it's hacky, and can't be shared with other >> programs. I'd like to implement it with libnettle at least, so it >> doesn't depend on the external gpg utility. But yes, we could do this >> one and it would work on all platforms with libnettle. DU> I remember there were a couple of concerns: DU> (1) it also doesn't work with GnuPG2 at all (have you tested it?) No, I haven't tested it. DU> (2) even with libnettle, you need to implement OpenPGP packet handling DU> if you want to keep the data compatibility with GPG (I don't think DU> it is a good idea to reinvent another encrypted data format with DU> plist as you proposed) Perhaps it would be OK to generate OpenPGP packets using libnettle, so we are compatible with GPG. That would be a decent amount of work but it would suddenly remove Emacs's dependency on an external utility and make it work on all platforms with GnuTLS support. I think that's a really good direction now that we have libnettle! Are you interested in working on it with me, and do you see any potential problems with this approach? DU> How about: DU> (1) add M-x auth-source-save command to save passwords manually DU> (2) (message "Type \\[auth-source-save] to save your passwords to file") DU> instead of the question That's a very good suggestion, since currently the saving functionality is done as a closure we pass back (internally this closure opens the file, adds the line, then closes it, so it doesn't care about the contents and thus is safe to call in any order). So we could simply queue those closures and then call something to save them. But all the prompting and UI has to be redesigned so it would be a lot of work for me. I'd like some more opinions on this. On Thu, 26 Jan 2012 16:41:19 -0500 Stefan Monnier wrote: >> I'd like to implement it with libnettle at least, so it doesn't depend >> on the external gpg utility. SM> But that would make it work even less with other programs. Yes. I like Ueno-san's suggestion of generating OpenPGP packets ourselves. We can let the user decide whether he prefers encrypted password tokens, encrypting the whole file, or leaving it in the clear. Maybe we could even talk to the GPG agent for credentials. SM> Another option (the better long-term option) is to use an external SM> keychain service to handle these issues. That's what we should focus on SM> for the "next time". >> Do you mean gpg-agent or the OS keychain? SM> I mean the keychain. >> Neither is available on all platforms consistently. SM> AFAIK all platforms have a keychain nowadays and it's the best place to SM> put sensitive passwords such as the ones used to access your IMAP server. I don't think GNU/Linux has anything beyond the Secrets API, and that depends on many optional components. Mac OS X has a standard keychain, which someone attempted to support in Emacs but didn't get it finished. It's not too complicated. W32 has some functionality (see http://msdn.microsoft.com/en-us/library/aa380261(v=VS.85).aspx and http://stackoverflow.com/questions/442923/windows-equivalent-of-os-x-keychain_ for some discussion) but not a fully capable keychain. I don't know about the other platforms we support, but I hope this shows that we should support but not rely on OS keychains. `auth-sources' reflects that by making them optional choices but not the defaults. >>>> IIRC for 23 the default was to keep the password for the current session >>>> and not to store it in any file at all. I think it's a better default >>>> than writing it in clear in some file, so at least for 24.1 reverting to >>>> the Emacs-23 default is very attractive. LI> Well, Emacs 23 just made you write the .authinfo file by hand. Emacs 24 LI> prompts you for whether you want to store the password or not. If you LI> don't want to, say "n". SM> Yes, I guess it's good enough. >> One possible flow: >> If the user says `y' then we can ask (if `auth-sources' is 'ask) >> "Do you want to keep your passwords in a GPG-encrypted file?" >> If they say `y' then set `auth-sources' to "~/.authinfo.gpg" and check >> that EPA/EPG are enabled. If GPG is not available, what do we do? Use >> libnettle? Or explain and pretend they said `n'? SM> If GPG is not available, ask a different question, as in "It will be SM> saved in cleartext, is that OK?" I think we'll need something on top of EPA/EPG if we support OpenPGP packets with libnettle, an encryption services wrapper, which we can ask "can we encrypt?" "can we encrypt a file with external GPG?" "can we encrypt a file with internal OpenPGP and libnettle?" and so on. Once we have that wrapper API we can build the user interaction easily, without ad-hoc checks. This is getting a little long for the bug report, do you want to move it to emacs-devel? Ted