From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Tue, 06 Nov 2007 03:38:33 -0500 Message-ID: References: <2366.81.51.30.174.1098020712.squirrel@yxa.extundo.com> <87y7dd2e0f.fsf@mocca.josefsson.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1194338536 1657 80.91.229.12 (6 Nov 2007 08:42:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2007 08:42:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Simon Josefsson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 06 09:42:20 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IpK0p-0007Ag-02 for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2007 09:42:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpK0d-0008RZ-Su for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2007 03:42:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpJxJ-0006i3-5y for emacs-devel@gnu.org; Tue, 06 Nov 2007 03:38:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpJxF-0006fe-2Q for emacs-devel@gnu.org; Tue, 06 Nov 2007 03:38:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpJxE-0006fJ-Q1 for emacs-devel@gnu.org; Tue, 06 Nov 2007 03:38:36 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IpJxC-0005uf-A6 for emacs-devel@gnu.org; Tue, 06 Nov 2007 03:38:34 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IpJxB-0003Hp-4I; Tue, 06 Nov 2007 03:38:33 -0500 In-reply-to: <87y7dd2e0f.fsf@mocca.josefsson.org> (message from Simon Josefsson on Mon, 05 Nov 2007 11:16:48 +0100) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82641 Archived-At: There are solutions intended to address the real problem here: GnuPG uses a helper program pin-entry that asks the user for passwords. I believe it can cache passwords too. However, this is not widely used, and definitely not used or known except to GnuPG users. I'm not convinced it is mature enough to be suggested as a solution for password input in emacs. And anyway, you'd still have the gc-problem in emacs if the password is transfered into an emacs elisp variable. Is pin-entry the program that is supposed to avoid the need to enter passwords thru any other program? I think we discussed how Emacs could use pin-entry, right? I think we concluded that this was possible under a window system but not on a tty; is that correct? Maybe we should pursue this and look for a complete solution along these lines. Is it possible to use pin-entry for applications other than GnuPG? Could it be the basis of a complete solution? The existing `read-passwd' API is not suitable for password.el, because each password needs to be associated with an application-dependent 'key'. There is no parameter for that in `read-passwd'. Do you think it is worth adding one? I see no harm in adding one. Adding it at the end would avoid incompatibility. Alternatively, and what I consider the best idea (but it was some time since this was discussed and I may very well have forgotten some important point): let's make `read-passwd' a more lower-level primitive, used by `password-read'. All else being equal, I'd rather avoid adding another level of function calling. It increases the total complexity, and I don't see any benefit. What is the benefit here?