From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Wed, 27 Oct 2004 21:08:28 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <2366.81.51.30.174.1098020712.squirrel@yxa.extundo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098904807 5414 80.91.229.6 (27 Oct 2004 19:20:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Oct 2004 19:20:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 27 21:19:57 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CMtAS-0006uN-00 for ; Wed, 27 Oct 2004 21:09:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMtID-0007fh-EZ for ged-emacs-devel@m.gmane.org; Wed, 27 Oct 2004 15:17:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMtHy-0007bf-6T for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:16:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMtHw-0007bJ-TB for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:16:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMtHw-0007b3-Qr for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:16:52 -0400 Original-Received: from [217.13.230.178] (helo=yxa.extundo.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CMt9v-0006co-Go; Wed, 27 Oct 2004 15:08:36 -0400 Original-Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.1/8.13.1/Debian-15) with ESMTP id i9RJ8SKt004429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 27 Oct 2004 21:08:29 +0200 Original-To: rms@gnu.org X-Hashcash: 1:22:041027:rms@gnu.org::b0cfc769ceacdf95:7c3a7d X-Hashcash: 1:22:041027:emacs-devel@gnu.org::31c53cf9f750a3e9:1bd30ed In-Reply-To: (Richard Stallman's message of "Wed, 27 Oct 2004 06:47:35 -0400") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on yxa-iv X-Virus-Status: Clean 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29074 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29074 Richard Stallman writes: > 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? Yes, that is a valid concern. That was one reason I didn't think of changing the existing read-passwd interface. 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. > 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. Sorry, I did not get this at first. > 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? Yes. I'll work on it. > -- 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? Yes. > 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. 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.