Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Stefan Monnier]

>   * subr.el (read-passwd): Disable show-paren-mode.

Should we disable show-paren-mode's highlighting when the paren is
covered by a `display' property?


        Stefan

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 09 Dec 2013 21:36:46 -0500
> Cc: emacs-devel@gnu.org
> 
> >   * subr.el (read-passwd): Disable show-paren-mode.
> 
> Should we disable show-paren-mode's highlighting when the paren is
> covered by a `display' property?

It's not just show-paren-mode.  It's any mode that looks at buffer
text disregarding the display properties.

For that reason, I think read-passwd should use a completely different
implementation, because otherwise it will reveal the secrets with the
next random Emacs feature.

As for your question, I believe the answer is YES, we should not
highlight parentheses covered by display properties.

RE: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Drew Adams]

> > Should we disable show-paren-mode's highlighting when the paren is
> > covered by a `display' property?
> 
> It's not just show-paren-mode.  It's any mode that looks at buffer
> text disregarding the display properties.
> 
> For that reason, I think read-passwd should use a completely different
> implementation, because otherwise it will reveal the secrets with the
> next random Emacs feature.

Just what I was thinking (but in my case only in vague terms).

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Leo Liu]

On 2013-12-10 10:36 +0800, Stefan Monnier wrote:
> Should we disable show-paren-mode's highlighting when the paren is
> covered by a `display' property?
>
>
>         Stefan

I have no opinion either way. read-passwd is really a special case where
emacs should reveal as little as possible. In other cases the highlight
might be helpful.

Leo

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[martin rudalics]

> For that reason, I think read-passwd should use a completely different
> implementation, because otherwise it will reveal the secrets with the
> next random Emacs feature.

IMO read-passwd should be in C and strip any extraneous
text-properties and overlays after running all hooks.

martin

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Tue, 10 Dec 2013 12:12:35 +0800
> Cc: emacs-devel@gnu.org
> 
> On 2013-12-10 10:36 +0800, Stefan Monnier wrote:
> > Should we disable show-paren-mode's highlighting when the paren is
> > covered by a `display' property?
> >
> >
> >         Stefan
> 
> I have no opinion either way. read-passwd is really a special case where
> emacs should reveal as little as possible. In other cases the highlight
> might be helpful.

Maybe you could suggest a couple of such cases, because I cannot think
of one.  We are talking about highlighting parentheses that are not
displayed because some display property is displayed instead, right?

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Josh]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Dec 10, 2013 8:35 AM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > From: Leo Liu <sdl.web@gmail.com>
> > Date: Tue, 10 Dec 2013 12:12:35 +0800
> > Cc: emacs-devel@gnu.org
> >
> > On 2013-12-10 10:36 +0800, Stefan Monnier wrote:
> > > Should we disable show-paren-mode's highlighting when the paren is
> > > covered by a `display' property?
> > >
> > >
> > >         Stefan
> >
> > I have no opinion either way. read-passwd is really a special case where
> > emacs should reveal as little as possible. In other cases the highlight
> > might be helpful.
>
> Maybe you could suggest a couple of such cases, because I cannot think
> of one.  We are talking about highlighting parentheses that are not
> displayed because some display property is displayed instead, right?

Isn't it the case that such parentheses would sometimes be displayed in
conjunction with conditional display specs., i.e. (when condition . spec)?
Also, I'd also expect show-paren-mode to affect parentheses having
display properties like ‘raise' and ’height' that change the appearance
of parentheses but do not display something else entirely.

[-- Attachment #2: Type: text/html, Size: 1535 bytes --]

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Eli Zaretskii]

> Date: Tue, 10 Dec 2013 09:51:02 -0800
> From: Josh <josh@foxtail.org>
> Cc: Leo Liu <sdl.web@gmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Isn't it the case that such parentheses would sometimes be displayed in
> conjunction with conditional display specs., i.e. (when condition . spec)?

If the condition is false, the display spec is inactive, and the
parentheses _are_ displayed.  So this is not the case I was talking
about.

> Also, I'd also expect show-paren-mode to affect parentheses having
> display properties like ‘raise' and ’height' that change the appearance
> of parentheses but do not display something else entirely.

I was talking about the so-called "replacing" display specs.  Sorry
for not being clear enough.

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Leo Liu]

On 2013-12-11 00:35 +0800, Eli Zaretskii wrote:
> Maybe you could suggest a couple of such cases, because I cannot think
> of one.  We are talking about highlighting parentheses that are not
> displayed because some display property is displayed instead, right?

Like I said I have no particular preference for one way or another. But
for example if } is displayed as 'END' and show-paren-mode highlights it
I am fine.

Leo

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Stefan Monnier]

> Like I said I have no particular preference for one way or another. But
> for example if } is displayed as 'END' and show-paren-mode highlights it
> I am fine.

Good point.


        Stefan

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Stefan Monnier]

> IMO read-passwd should be in C and strip any extraneous
> text-properties and overlays after running all hooks.

I don't see why we should write it in C, but stripping away overlays and
text-properties would make sense.  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.  The main property I want to
preserve is that normal editing works (tho you have to do it "blind"),
which is why the "hiding" is done in an after-change-function.


        Stefan

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[martin rudalics]

 > 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.

 > 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.

 > The main property I want to
 > preserve is that normal editing works (tho you have to do it "blind"),
 > which is why the "hiding" is done in an after-change-function.

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.
Obviously, if the text is in a (mini-)buffer there's always a way that
redisplay reveals it.  In this sense `show-paren-mode' was only the tip
of the iceberg.  I would like a "hide" text property which can be only
set and removed from C and overrides any other text or overlay property
specified anywhere else.

martin

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[Stefan Monnier]

>> 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

Re: [Emacs-diffs] trunk r115434: * subr.el (read-passwd): Disable show-paren-mode.

[martin rudalics]

 > 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.

The malicious case would include a person demonstrating how easy it is
to bypass the Emacs protection mechanism.

 > 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.

IIRC we already cover other cases like undo revealing a previously typed
password as well as passwords ending up in bug reports as recently typed
characters.  IMO typing passswords should be based on limited editing
facilities like yanking, self-insertion, cursor movement and deletion
commands.

martin