From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode. Date: Wed, 11 Dec 2013 10:13:34 -0500 Message-ID: References: <83siu1xszu.fsf@gnu.org> <52A6C842.7060700@gmx.at> <52A81ECD.7040504@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386774836 1173 80.91.229.3 (11 Dec 2013 15:13:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Dec 2013 15:13:56 +0000 (UTC) Cc: Eli Zaretskii , sdl.web@gmail.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 11 16:14:01 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VqlU8-0007Sr-4u for ged-emacs-devel@m.gmane.org; Wed, 11 Dec 2013 16:14:00 +0100 Original-Received: from localhost ([::1]:57866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqlU7-0007Sk-Lw for ged-emacs-devel@m.gmane.org; Wed, 11 Dec 2013 10:13:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqlTx-0007RG-B4 for emacs-devel@gnu.org; Wed, 11 Dec 2013 10:13:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqlTq-0004mt-1Z for emacs-devel@gnu.org; Wed, 11 Dec 2013 10:13:49 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:57246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqlTp-0004me-Rj; Wed, 11 Dec 2013 10:13:41 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id rBBFDYWp022575; Wed, 11 Dec 2013 10:13:35 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 0028FAE321; Wed, 11 Dec 2013 10:13:34 -0500 (EST) In-Reply-To: <52A81ECD.7040504@gmx.at> (martin rudalics's message of "Wed, 11 Dec 2013 09:14:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4788=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4788> : inlines <305> : streams <1089107> : uri <1620913> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:166297 Archived-At: >> I don't see why we should write it in C, but stripping away overlays and >> text-properties would make sense. > In Lisp there's always a simple way to inadvertently or maliciously > reveal some text property. C wouldn't eliminate but reduce that danger. For the "maliciously" case: this is Emacs we're talking about. Even if implemented in C, a "malicious" intruder can place enough advices to circumvent pretty much any such "security". So worrying about this case is not very useful. Second, hiding the text from display is just a "sanity" measure. Note that there are many cases where you actually want to see the password as you type it (it's pretty common nowadays to see password prompts where you can click a "show password" toggle box). Showing the paren-matches is not that terrible of a problem. We already display the number of chars and I haven't heard anyone complain about this "information leak". >> Another approach would be to replace chars with . not just in the >> display but in the buffer itself and keep the actual chars in >> a text property. > Sounds good but not entirely trivial to implement. If we want it to be 100%, indeed it's not trivial, but using the new pre-redisplay-functions it should be pretty easy to do a "good enough" job (good enough to cover show-paren-mode, for instance). > Which is the weak point IMO. I wouldn't like to type a password with > `after-change-functions' or any other hook running in between. I don't think we want to try and disable pre/post-command-hook, timers, process filters, before/after-change-functions, and other redisplay hooks just out of paranoia. Stefan