From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Mon, 05 Nov 2007 11:16:48 +0100 Message-ID: <87y7dd2e0f.fsf@mocca.josefsson.org> References: <2366.81.51.30.174.1098020712.squirrel@yxa.extundo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1194257874 21848 80.91.229.12 (5 Nov 2007 10:17:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2007 10:17:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 05 11:17:54 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 1Ioz1P-0006KZ-7X for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 11:17:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ioz1E-0004Zn-C3 for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 05:17:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ioz0x-0004Lr-2R for emacs-devel@gnu.org; Mon, 05 Nov 2007 05:17:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ioz0v-0004Kp-Qo for emacs-devel@gnu.org; Mon, 05 Nov 2007 05:17:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ioz0v-0004Kc-Hw for emacs-devel@gnu.org; Mon, 05 Nov 2007 05:17:01 -0500 Original-Received: from yxa.extundo.com ([83.241.177.38]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ioz0s-0008Jg-OU; Mon, 05 Nov 2007 05:16:59 -0500 Original-Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lA5AGmND025372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 11:16:51 +0100 OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071105:rms@gnu.org::cNSTT5d27YeoOpau:7HoG X-Hashcash: 1:22:071105:emacs-devel@gnu.org::VjwkG5YGby9/p4Ss:Kz1y In-Reply-To: (Richard Stallman's message of "Fri, 02 Nov 2007 11:02:36 -0400") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean 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:82562 Archived-At: There are risks associated with caching passwords (i.e., the password is stored in memory and may be swapped out to disk), and possibly it should not be the default. However, I think the risks are somewhat overblown. The garbage-collecting nature of elisp exposes this risk anyway. All passwords entered into emacs may be swapped out to disk. 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. Another point of view is that several parts of Emacs already contains code to cache passwords. Reducing that code duplication is what triggered me to write password.el. 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? 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'. New elisp applications, that want to allow users to cache passwords, can start to use the `password-read' API. Existing elisp applications with their own ad-hoc code to cache passwords could be modified to use password-read. Users can modify the caching behaviour by setting password-* variables. Regarding naming, possibly `password-read-and-cache' should be removed. The problem with it is that it enters passwords into the cache without allowing applications to verify that the password is correct. However, applications could detect this and use `password-cache-remove', but it seems less reliable to me. /Simon Richard Stallman writes: > Here's what I said about read-passwd and password.el in 2004. Setting > aside what I said about the short term, the main issue seems to be > whether to cache passwords. > > Simon, what do you think about this now? > What do others think? > > > First message: > > It occurs to me that paranoid people might be worried about saving > passwords in a cache like this. What do people know about that issue? > > The text added to the manual is clear enough. I have some issues > about the substance: > > -- Function: read-passwd prompt &optional confirm default > This function reads a password, prompting with PROMPT. It does > not echo the password as the user types it; instead, it echoes `.' > for each character in the password. > > This ought to use the cache now, but the text does not say so. > > (Later): It looks like all you did was move read-passwd into > password.el without changing it. What I suggested was to integrate > read-passwd into this file--which means, make it use the cache. > > There is no sense in moving read-passwd into the new file without > making it use the new file's facilities. That change only causes > password.el to be loaded for programs that don't use the cache. > It provides no benefit. > > So if its definition is to remain unchanged, it should stay in subr.el > where it is preloaded. But I would rather see it move to password.el > and *take advantage of the facilities of password.el*. > > Can this be done? > > -- Function: password-read prompt key > Read a password from the user, using `read-passwd', prompting with > PROMPT. If a password has been stored in the password cache, > using `password-cache-add' on the same KEY, it is returned > directly, without querying the user. > > Once read-passwd uses the cache, won't password-read be obsolete? > > Why have both password-read and password-read-and-add? > Why not always add? Is the idea that for some purposes > it is ok to cache, but for others it is too risky? > > > Second message: > > Other applications typically ask the user whether they want to > remember the password in memory. If read-passwd is changed to cache > passwords (however, to use the cache, callers of read-passwd must be > updated, to provide the "key" into the hash table), it could ask the > user this. Opinions on this welcome. > > Having it always ask would be too annoying, I think. So that would > need to be a new argument, which means the feature is no benefit > unless we change the callers. > > That is the wrong thing to do at present. So I think we should put > read-passwd back where it was and remove the new file for now. > > Looking ahead to the future, > > > Why have both password-read and password-read-and-add? > > Why not always add? Is the idea that for some purposes > > it is ok to cache, but for others it is too risky? > > No, the reason was this: if the user entered an incorrect password, it > should not be cached. If an incorrect password is cached, the code > might infloop trying the incorrect password automatically over and > over again. It was considered safer to first read the password, then > try to use it, and if successful then it is cached. > > In that case, password-read-and-add makes no sense, right? > Why add a shortcut that in best practice should not be used? > > I'm not sure my argument is good, it may be simpler to always cache, > and have the calling code invoke password-cache-remove whenever there > is a password failure. > > That is a reasonable alternative, I guess, but then password-read > should add the password and we should not have password-read-and-add > as a separate entry point. > > But it doesn't make sense to discuss this without dealing with the > question of whether caching of correct passwords is desirable.