From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Opportunistic STARTTLS in smtpmail.el Date: Tue, 31 May 2011 01:10:04 +0200 Organization: Programmerer Ingebrigtsen Message-ID: References: <87d3kal0za.fsf@lifelogs.com> <874o5mky4o.fsf@lifelogs.com> <8762ptue8r.fsf@lifelogs.com> <87k4e8ucw3.fsf@lifelogs.com> <87liyofwxp.fsf@lifelogs.com> <874o5cfui5.fsf@lifelogs.com> <87liyndz5l.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306797026 18831 80.91.229.12 (30 May 2011 23:10:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 May 2011 23:10:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 31 01:10:22 2011 Return-path: Envelope-to: ged-emacs-devel@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 1QRBbK-00024m-FW for ged-emacs-devel@m.gmane.org; Tue, 31 May 2011 01:10:22 +0200 Original-Received: from localhost ([::1]:55187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRBbJ-00014A-UE for ged-emacs-devel@m.gmane.org; Mon, 30 May 2011 19:10:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRBbG-00013l-86 for emacs-devel@gnu.org; Mon, 30 May 2011 19:10:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRBbF-0008El-0b for emacs-devel@gnu.org; Mon, 30 May 2011 19:10:18 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:45122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRBbE-0008EZ-OI for emacs-devel@gnu.org; Mon, 30 May 2011 19:10:16 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QRBbD-00023b-5H for emacs-devel@gnu.org; Tue, 31 May 2011 01:10:15 +0200 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2011 01:10:15 +0200 Original-Received: from larsi by cm-84.215.51.58.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 May 2011 01:10:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 53 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.51.58.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEWzAAiyAAqwAA6zABSz AAa1AAu0AAq0AA2zAAyxAAqxAA2xABCvAA737u+0CyCzAA2eWM48AAABZElEQVQ4jZXSsWrDMBAG YA0me4c+RKGbCBlSPElDIEMCPjtjB5MXMOEKnTt072LwC3TumGxZ7xXaxWvxC3RoT7ITybY89AyB 3KdfJwuLz1F9NVwk/gnfE1ATCQ3DShRXJVSwb8BFdALqUgxKJcqt9EFDYlJqBLxWDwN2hgI9XK/U 2m4FKghmcBBYkiQEU1u1LzcGPXo3D0AHwL+5AARmgJO8B1lmh0Qq2g9hbhO3W9g8zjxAnGcIkAEe DilEDhZSygXaAtjnWrcHXImPgqEoECU+ozv6WkivFu7ofeA9DaQhODBsZtEQWskvUPPjBCGNzMfA f8zXLWN+uszLdvVWibhuuuoyiLubkkE216q7yO61LCvReBVbwqf3siQR+9LCz11VheB4vCcKwe+J DMgm7sPS9qk33B657XNCukTNiSVdwVyKe8WTBzHvfZlA1Et09+T1Sdjfs+0+EA2BuHsmCsC4JuEP jREc+ZD0ZDcAAAAASUVORK5CYII= Mail-Copies-To: never X-Now-Playing: Stephan Mathieu's _Remain_: "Remain" User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:OQh+7iJgrRJUAkzBLe4M2KPH0AQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139921 Archived-At: Here's my concrete suggestion for how auth-source would deal with this stuff. The design requirements are: 1) if users want it, credentials should be encrypted 2) the credentials should be stored in a file that can be edited by hand, if necessary 5) it should be possible to check whether credentials exist without giving a password, even if the credentials are encrypted My solution to all this is to allow putting encrypted stuff into the ~/.authinfo file. It's currently a one-credential-per-line file like this, and this would still be perfectly valid: machine news.foo.org force yes port nntp login bar password zot However, if auth-info.el prompts somebody for a password, auth-info.el will also prompt them for whether the credentials should be stored encrypted. If the user says yes, then auth-info.el will write the following to the file: machine news.foo.org force yes port nntp secret bG9naW4AYmFyAHBhc3N3b3JkAHpvdA The secret is simply a base64-encoded gpg-encoded string made something like this: (base64-encode-string (gpg-encode-string "login^@bar^@password^@zot" (read-string "Password? "))) We can add some padding and entropy to make things l33tly secure, like (base64-encode-string (gpg-encode-string (format "login^@bar^@password^@zot^@pad^@%s" (random 42)) (read-string "Password? "))) When decoding, we don't have to decode anything until we actually know that we need the password. People who think this is too insecure can use ~/.authinfo.gpg files, just like now. That's up to them. And people that think that using no encryption at all can do that, too. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/