From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, sdl.web@gmail.com, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.
Date: Wed, 11 Dec 2013 10:13:34 -0500 [thread overview]
Message-ID: <jwvwqjba0qd.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <52A81ECD.7040504@gmx.at> (martin rudalics's message of "Wed, 11 Dec 2013 09:14:05 +0100")
>> 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
next prev parent reply other threads:[~2013-12-11 15:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1Vpqlh-0007jZ-DD@vcs.savannah.gnu.org>
2013-12-10 2:36 ` [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode Stefan Monnier
2013-12-10 3:52 ` Eli Zaretskii
2013-12-10 7:52 ` martin rudalics
2013-12-11 4:29 ` Stefan Monnier
2013-12-11 8:14 ` martin rudalics
2013-12-11 15:13 ` Stefan Monnier [this message]
2013-12-11 17:55 ` martin rudalics
[not found] ` <<83siu1xszu.fsf@gnu.org>
2013-12-10 3:59 ` Drew Adams
2013-12-10 4:12 ` Leo Liu
2013-12-10 16:35 ` Eli Zaretskii
2013-12-10 17:51 ` Josh
2013-12-10 18:17 ` Eli Zaretskii
2013-12-11 0:03 ` Leo Liu
2013-12-11 4:19 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvwqjba0qd.fsf-monnier+emacsdiffs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
--cc=sdl.web@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).