[PATCH] Keep network security info buffers after use

[PATCH] Keep network security info buffers after use

[Karl Fogel]

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

What do people think of the attached behavior change?

Summary: after the user is prompted about whether to accept a 
remote cert, the buffer(s) with information about the cert should 
stay around, instead of being killed like they currently are.

Request: I'd like to know if people agree with the overall goal 
here.  I'm still testing the change (I need to learn something new 
in order to test it -- namely, how to artifically "forget" a cert 
so that I get re-prompted again, and if anyone has tips on that, 
I'm all ears).

Motivation:

Recently I was sending an email from Emacs on a new machine, and I 
got prompted about whether to accept the remote SMTP server's 
cert.  The prompt function is `nsm-query-user', and its manner of 
prompting didn't allow me to easily leave the minibuffer to go 
into the "*Network Security Manager*" buffer and grab the cert 
info so that I could save it to inspect further later on (maybe 
there was something I could have done with a recursive edit, but I 
didn't want to break my flow that much).

So after accepting the cert, I tried to go back to the "*Network 
Security Manager*" buffer to get the remote server fingerprint -- 
but alas, the buffer was gone.

Hence this change: make it so that that buffer (and another 
related cert-specific buffer) stay around after the user has been 
prompted, in case the user wants to go back and get the 
information in them.

I'm not sure whether just eliminating the calls to `kill-buffer' 
is enough.  Maybe they should be replaced with `bury-buffer' 
calls, to make sure that those buffers aren't in the user's face? 
As I said above, I'm still testing.  I'd just like to know if we 
agree with the goal of this change.  I won't push it to master 
until a) I know we agree on the goal, and b) it's fully tested.

Best regards,
-Karl


[-- Attachment #2: Keep network security info buffers after use --]
[-- Type: text/plain, Size: 7339 bytes --]

From 3b9a564d2aaae83f612d55f4d9592fa5d96986eb Mon Sep 17 00:00:00 2001
From: Karl Fogel <kfogel@red-bean.com>
Date: Sun, 17 Dec 2023 12:17:11 -0600
Subject: [PATCH] Keep network security info buffers after use

* lisp/net/nsm.el (nsm-query-user): Don't kill the two informational
  buffers "*Network Security Manager*" and "*Certificate Details*".
  Even after making a decision about a certificate, the user might
  want to go back to those buffers to get information from them.

Note that while the diff is large, the actual change is tiny.  The
removal of the `unwind-protect' wrapper caused much reindentation
(there's nothing to unwind now, as both unwindforms went away).  The
"real" diff is just the removal of the two `kill-buffer' calls at the
end of the function and would look something like this:

  --- lisp/net/nsm.el
  +++ lisp/net/nsm.el
  @@ -918,9 +918,7 @@ nsm-query-user
                      (goto-char (point-min))
                      (read-only-mode)))))
               ;; Return the answer.
  -            (cadr answer))
  -        (kill-buffer cert-buffer)
  -        (kill-buffer buffer)))))
  +            (cadr answer))))))
---
 lisp/net/nsm.el | 139 ++++++++++++++++++++++++------------------------
 1 file changed, 69 insertions(+), 70 deletions(-)

diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 09f7ac52537..9df08b33ca9 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -846,81 +846,80 @@ nsm-query-user
                         '((?b "backward page" "See previous page")
                           (?f "forward page" "See next page"))))))
       ;; Then ask the user what to do about it.
-      (unwind-protect
-          (let* ((pems (cl-loop for cert in certs
-                                collect (gnutls-format-certificate
-                                         (plist-get cert :pem))))
-                 (cert-index 0)
-                 show-details answer buf)
-            (while (not done)
-              (setq answer (if show-details
-                               (read-multiple-choice "Viewing certificate:"
-                                                     details-choices)
-                             (read-multiple-choice "Continue connecting?"
-                                                   accept-choices)))
-              (setq buf (if show-details cert-buffer buffer))
-
-              (cl-case (car answer)
-                (?q
-                 ;; Exit the details window.
-                 (set-window-buffer (get-buffer-window cert-buffer) buffer)
-                 (setq show-details nil))
-
-                (?d
-                 ;; Enter the details window.
-                 (set-window-buffer (get-buffer-window buffer) cert-buffer)
-                 (with-current-buffer cert-buffer
-                   (read-only-mode -1)
-                   (insert (nth cert-index pems))
-                   (goto-char (point-min))
-                   (read-only-mode))
-                 (setq show-details t))
-
-                (?b
-                 ;; Scroll down.
-                 (with-selected-window (get-buffer-window buf)
-                   (with-current-buffer buf
-                     (ignore-errors (scroll-down)))))
-
-                (?f
-                 ;; Scroll up.
-                 (with-selected-window (get-buffer-window buf)
-                   (with-current-buffer buf
-                     (ignore-errors (scroll-up)))))
-
-                (?n
-                 ;; "No" or "next certificate".
-                 (if show-details
-                     (with-current-buffer cert-buffer
-                       (read-only-mode -1)
-                       (erase-buffer)
-                       (setq cert-index (mod (1+ cert-index) (length pems)))
-                       (insert (nth cert-index pems))
-                       (goto-char (point-min))
-                       (read-only-mode))
-                   (setq done t)))
-
-                (?a
-                 ;; "Always"
-                 (setq done t))
-
-                (?s
-                 ;; "Session only"
-                 (setq done t))
-
-                (?p
-                 ;; Previous certificate.
+      (let* ((pems (cl-loop for cert in certs
+                            collect (gnutls-format-certificate
+                                     (plist-get cert :pem))))
+             (cert-index 0)
+             show-details answer buf)
+        (while (not done)
+          (setq answer (if show-details
+                           (read-multiple-choice "Viewing certificate:"
+                                                 details-choices)
+                         (read-multiple-choice "Continue connecting?"
+                                               accept-choices)))
+          (setq buf (if show-details cert-buffer buffer))
+
+          (cl-case (car answer)
+            (?q
+             ;; Exit the details window.
+             (set-window-buffer (get-buffer-window cert-buffer) buffer)
+             (setq show-details nil))
+
+            (?d
+             ;; Enter the details window.
+             (set-window-buffer (get-buffer-window buffer) cert-buffer)
+             (with-current-buffer cert-buffer
+               (read-only-mode -1)
+               (insert (nth cert-index pems))
+               (goto-char (point-min))
+               (read-only-mode))
+             (setq show-details t))
+
+            (?b
+             ;; Scroll down.
+             (with-selected-window (get-buffer-window buf)
+               (with-current-buffer buf
+                 (ignore-errors (scroll-down)))))
+
+            (?f
+             ;; Scroll up.
+             (with-selected-window (get-buffer-window buf)
+               (with-current-buffer buf
+                 (ignore-errors (scroll-up)))))
+
+            (?n
+             ;; "No" or "next certificate".
+             (if show-details
                  (with-current-buffer cert-buffer
                    (read-only-mode -1)
                    (erase-buffer)
-                   (setq cert-index (mod (1- cert-index) (length pems)))
+                   (setq cert-index (mod (1+ cert-index) (length pems)))
                    (insert (nth cert-index pems))
                    (goto-char (point-min))
-                   (read-only-mode)))))
-            ;; Return the answer.
-            (cadr answer))
-        (kill-buffer cert-buffer)
-        (kill-buffer buffer)))))
+                   (read-only-mode))
+               (setq done t)))
+
+            (?a
+             ;; "Always"
+             (setq done t))
+
+            (?s
+             ;; "Session only"
+             (setq done t))
+
+            (?p
+             ;; Previous certificate.
+             (with-current-buffer cert-buffer
+               (read-only-mode -1)
+               (erase-buffer)
+               (setq cert-index (mod (1- cert-index) (length pems)))
+               (insert (nth cert-index pems))
+               (goto-char (point-min))
+               (read-only-mode)))))
+        ;; Return the answer.  (We leave `buffer' and `cert-buffer'
+        ;; around, in case the user wants to go back and get any
+        ;; information from them.)
+        (cadr answer)))))
 
 (defun nsm-save-host (host port status what problems permanency)
   (let* ((id (nsm-id host port))
-- 
2.43.0

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Sun, 17 Dec 2023 13:02:16 -0600
> 
> What do people think of the attached behavior change?

It must be optional, probably off by default, and if it's on by
default, there must be a way to get back old behavior.

Thanks.

P.S. And please wait for enough people who know about this more than I
do to chime in, before you conclude that you've heard enough.

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 17 Dec 2023, Eli Zaretskii wrote:
>It must be optional, probably off by default, and if it's on by
>default, there must be a way to get back old behavior.
>[...]
>P.S. And please wait for enough people who know about this more 
>than I
>do to chime in, before you conclude that you've heard enough.

On 17 Dec 2023, Andreas Schwab wrote:
>How about adding a command to (re-)display the cert info?

I think both of these changes would add more complexity than 
solving the problem is worth.

But there's another route that might be a better solution:

One can enter a recursive edit from the `read-multiple-choice' 
prompt.  However, the availability of recursive edit is not 
obvious from the prompt.  The `read-multiple-choice' doc string 
does say something about it (though of course when the user is 
facing the prompt they aren't reading this doc string):

  > If the user enters ‘edit’, the function starts a recursive
  > edit.  When the user exit the recursive edit, the
  > multiple-choice prompt gains focus again.

It turns out that typing C-r at the prompt is how one "enters 
`edit'".  But I had to guess that -- nothing in the 
`read-multiple-choice' prompt indicates it.  (And I don't know 
what the word "`edit'" means in the context in which it is used in 
that doc string -- I infer that there's some convention I'm 
ignorant of, but if so it's not likely to be a convention that 
most users know about either.)

Fortunately, there *is* a "?" option built in to the 
`read-multiple-choice' prompt.  One can see that extra "?"  option 
by evaluating this code, for example:

  (read-multiple-choice
   "Take some action?"
   '((?o "once" "Just this one time")
     (?s "session" "For the remainder of this Emacs session")
     (?a "always")
     (?n "no")
     (?v "never" "Not now, not ever, and don't ask again")))

So, how about we change lisp/emacs-lisp/rmc.el:`rmc--show-help' to 
display how to enter a recursive edit?  That is, when the user 
types "?" at the prompt, the resultant "*Multiple Choice Help*" 
buffer would always show this extra piece of information about how 
to enter a recursive edit, in addition to all the options 
specified in the CHOICES list argument to `read-multiple-choice'.

That would solve the problem not only for `nsm-query-user', but 
for all callers of `read-multiple-choice'.

Thoughts?

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Sun, 17 Dec 2023 17:27:46 -0600
> 
> So, how about we change lisp/emacs-lisp/rmc.el:`rmc--show-help' to 
> display how to enter a recursive edit?

We don't advertise that key for a reason, so I don't think this is a
good idea.

I actually don't understand why you rejected the tow ideas proposed to
you.  Personally, I think Andreas's idea is the better one, and not
too hard to implement.  It also has the nice advantage that it solves
the exact problem you had and nothing else.

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 18 Dec 2023, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Sun, 17 Dec 2023 17:27:46 -0600
>> 
>> So, how about we change lisp/emacs-lisp/rmc.el:`rmc--show-help' 
>> to 
>> display how to enter a recursive edit?
>
>We don't advertise that key for a reason, so I don't think this 
>is a
>good idea.

Okay.  I'm curious what that reason is, if you have time to 
explain, but I'm fine accepting this decision as a given.

>I actually don't understand why you rejected the tow ideas 
>proposed to
>you.  Personally, I think Andreas's idea is the better one, and 
>not
>too hard to implement.  It also has the nice advantage that it 
>solves
>the exact problem you had and nothing else.

My problem with Andreas's idea...

>How about adding a command to (re-)display the cert info?

...is that I don't see how the user is likely to know about the 
existence of this new command.  It's already kind of rare to get 
prompted for cert info at all (it only happens to me every once in 
a while, usually when I'm starting to use on a new machine).

Remember, the cert or server info *is* already being displayed to 
the user when the `read-multiple-choice' prompt happens -- the 
info is right there in a displayed buffer.  The problem is that 
it's not obvious how to get out of the minibuffer and into that 
displayed buffer, for example to grab the info into the kill ring, 
or save it to a file, so that one can go back and use the info 
after the prompt cycle is done.

Now, it turns out that one *can* get out of the minibuffer, by 
entering a recursive edit with C-r, but nothing in the 
`read-multiple-choice' prompt indicates this, so the user would 
have to "just know" about this possibility.

If `C-x o' would just work at the `read-multiple-choice' prompt, 
and enable one to leave the minibuffer to travel around to other 
windows, that would also be a fine solution.  Actually, probably 
it would be the best solution, now that I think about it.

Are there reasons why `read-multiple-choice' disallows this by 
default?  I don't know much about the constraints and requirements 
of that function; I just know how it's been treating me lately 
:-).

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[tomas]

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

On Mon, Dec 18, 2023 at 06:00:59PM -0600, Karl Fogel wrote:

[...]

> If `C-x o' would just work at the `read-multiple-choice' prompt, and enable
> one to leave the minibuffer to travel around to other windows, that would
> also be a fine solution.  Actually, probably it would be the best solution,
> now that I think about it.

I havent been in your situation, but I'm sure it would have made me furious.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Dec 2023 18:00:59 -0600
> 
> On 18 Dec 2023, Eli Zaretskii wrote:
> >
> >We don't advertise that key for a reason, so I don't think this 
> >is a good idea.
> 
> Okay.  I'm curious what that reason is, if you have time to 
> explain, but I'm fine accepting this decision as a given.

The reason is simple: what you see is a side effect of how the user
interaction was implemented in this case.  Look at the code, and you
will see it clearly.  If we ever decide to change the details of the
implementation, C-r will most probably stop working.  We don't want to
advertise "features" that can disappear without advance warning.

> My problem with Andreas's idea...
> 
> >How about adding a command to (re-)display the cert info?
> 
> ...is that I don't see how the user is likely to know about the 
> existence of this new command.

We can have a reference to it in the doc string(s) of commands and
variables which are related.  There's also the various Apropos
commands and the manual.

More generally, are you saying that any feature that is not directly
into user's face is not discoverable?  If so, I don't think I agree.
We go a long way in Emacs to provide discovery features and
cross-references, for this very reason, and anyway it is impractical
to expect that ever obscure option will always be staring the user in
the face.  And even if it were, how many users will immediately know
that entering recursive edit will allow them to see the stuff you
wanted to see?  How many users even know about recursive edit in
Emacs?

Re: [PATCH] Keep network security info buffers after use

[tomas]

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

On Tue, Dec 19, 2023 at 02:34:07PM +0200, Eli Zaretskii wrote:
> > From: Karl Fogel <kfogel@red-bean.com>
> > Cc: emacs-devel@gnu.org
> > Date: Mon, 18 Dec 2023 18:00:59 -0600
> > 
> > On 18 Dec 2023, Eli Zaretskii wrote:
> > >
> > >We don't advertise that key for a reason, so I don't think this 
> > >is a good idea.
> > 
> > Okay.  I'm curious what that reason is, if you have time to 
> > explain, but I'm fine accepting this decision as a given.
> 
> The reason is simple: what you see is a side effect of how the user
> interaction was implemented in this case [...]

That would be C-r. What impedes the (for this "dumb user" here) "most
obvious" path, i.e. changing to that buffer with C-o and copy things
into the kill buffer to inspect them later at ease?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> Date: Tue, 19 Dec 2023 13:50:14 +0100
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> From:  <tomas@tuxteam.de>
> 
> On Tue, Dec 19, 2023 at 02:34:07PM +0200, Eli Zaretskii wrote:
> > > From: Karl Fogel <kfogel@red-bean.com>
> > > Cc: emacs-devel@gnu.org
> > > Date: Mon, 18 Dec 2023 18:00:59 -0600
> > > 
> > > On 18 Dec 2023, Eli Zaretskii wrote:
> > > >
> > > >We don't advertise that key for a reason, so I don't think this 
> > > >is a good idea.
> > > 
> > > Okay.  I'm curious what that reason is, if you have time to 
> > > explain, but I'm fine accepting this decision as a given.
> > 
> > The reason is simple: what you see is a side effect of how the user
> > interaction was implemented in this case [...]
> 
> That would be C-r.

The question was about C-r, so that's what I answered.

> What impedes the (for this "dumb user" here) "most
> obvious" path, i.e. changing to that buffer with C-o and copy things
> into the kill buffer to inspect them later at ease?

The fact that rmc.el is a modal dialog, AFAIU.

Re: [PATCH] Keep network security info buffers after use

[Andreas Schwab]

On Dez 19 2023, Eli Zaretskii wrote:

>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 18 Dec 2023 18:00:59 -0600
>> 
>> On 18 Dec 2023, Eli Zaretskii wrote:
>> >
>> >We don't advertise that key for a reason, so I don't think this 
>> >is a good idea.
>> 
>> Okay.  I'm curious what that reason is, if you have time to 
>> explain, but I'm fine accepting this decision as a given.
>
> The reason is simple: what you see is a side effect of how the user
> interaction was implemented in this case.

That is not true.  read-multiple-choice documents that it uses the edit
binding from query-replace-map, thus it is not a side effect, but an
explicit choice.

> If we ever decide to change the details of the implementation, C-r
> will most probably stop working.

That would be a regression.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
> Date: Wed, 20 Dec 2023 23:43:24 +0100
> 
> On Dez 19 2023, Eli Zaretskii wrote:
> 
> > The reason is simple: what you see is a side effect of how the user
> > interaction was implemented in this case.
> 
> That is not true.  read-multiple-choice documents that it uses the edit
> binding from query-replace-map, thus it is not a side effect, but an
> explicit choice.

Ah, right.  But in that case, C-r (and a plethora of other key
bindings) are already documented, albeit implicitly via the link, so
we don't need to mention that explicitly.

Re: [PATCH] Keep network security info buffers after use

[Andreas Schwab]

How about adding a command to (re-)display the cert info?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Keep network security info buffers after use

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Summary: after the user is prompted about whether to accept a 
  > remote cert, the buffer(s) with information about the cert should 
  > stay around, instead of being killed like they currently are.

If this would be an improvement, should we go further and preserve
this information in the file system for logging even after the Emacs
process is killed?  Perhaps in the user's .emacs.d directory?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 18 Dec 2023, Richard Stallman wrote:
>  > Summary: after the user is prompted about whether to accept a 
>  > remote cert, the buffer(s) with information about the cert 
>  > should 
>  > stay around, instead of being killed like they currently are.
>
>If this would be an improvement, should we go further and 
>preserve
>this information in the file system for logging even after the 
>Emacs
>process is killed?  Perhaps in the user's .emacs.d directory?

I think it would be sufficient to just let the user temporarily 
leave the `read-multiple-choice' prompt and go into the displayed 
buffer that contains the cert info.  If the user then wants to 
save that information somehow, she can do so.

If we were to always save the information, unconditionally, then 
we would have to decide where to save it, and come up with a way 
to inform the user of where it is saved.  And in most cases the 
user probably does not need it to be saved for later examination 
anyway.

In other words, just giving the user agency at the critical moment 
would be the best solution, I think.

I'm still waiting to hear if there is approval for, or concern 
about, the idea of letting `C-x o' depart (presumably temporarily) 
from a `read-multiple-choice' prompt.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Dec 2023 23:56:03 -0600
> 
> I'm still waiting to hear if there is approval for, or concern 
> about, the idea of letting `C-x o' depart (presumably temporarily) 
> from a `read-multiple-choice' prompt.

I think read-multiple-choice is intentionally programmed to implement
a modal dialog.  That's why "C-x o" is disallowed.

Once again, I think a special command for getting the cert info is the
best solution to your problem: it is relatively simple, it is
unintrusive, and it doesn't affect functionalities unrelated to that
particular problem.  By contrast, making significant changes in rmc.el
just to cater to this use case sounds wrong to me.

Re: [PATCH] Keep network security info buffers after use

[tomas]

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

On Tue, Dec 19, 2023 at 02:51:21PM +0200, Eli Zaretskii wrote:
> > From: Karl Fogel <kfogel@red-bean.com>
> > Cc: emacs-devel@gnu.org
> > Date: Mon, 18 Dec 2023 23:56:03 -0600
> > 
> > I'm still waiting to hear if there is approval for, or concern 
> > about, the idea of letting `C-x o' depart (presumably temporarily) 
> > from a `read-multiple-choice' prompt.
> 
> I think read-multiple-choice is intentionally programmed to implement
> a modal dialog.

Ouch. Thanks for the explanation.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 19 Dec 2023, Eli Zaretskii wrote:
>I think read-multiple-choice is intentionally programmed to 
>implement
>a modal dialog.  That's why "C-x o" is disallowed.
>
>Once again, I think a special command for getting the cert info 
>is the
>best solution to your problem: it is relatively simple, it is
>unintrusive, and it doesn't affect functionalities unrelated to 
>that
>particular problem.  By contrast, making significant changes in 
>rmc.el
>just to cater to this use case sounds wrong to me.

How about an option that allows `C-x o' to escape from the modal 
dialog of `read-multiple-choice'?

This could be either enabled by an argument to 
`read-multiple-choice' (then `nsm-query-user' could pass that 
argument; existing callers of `read-multiple-choice' would be 
unaffected, unless they start passing that argument too), or by a 
user-customizable variable (`read-multiple-choice-strict-modal' or 
something, defaulting to `t' but a user could set it to nil if 
they wanted a less-strict modal dialog).

In general, I do not think it's good when modal dialogs to 
strictly block the user from taking outside action during the 
dialog.  A user who types `C-x o' while in the minibuffer knows 
what they are doing.  And I can't think of any reason why 
`read-multiple-choice' *should* block this: what harm is being 
prevented, to justify interfering with the user's desire to do a 
particular thing?

Users are more familiar with a common command like `C-x o' than 
with entering a recursive edit (and anyway, as you said: "If we 
ever decide to change the details of the implementation, C-r will 
most probably stop working.  We don't want to advertise 'features' 
that can disappear without advance warning.").

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 19 Dec 2023 12:57:04 -0600
> 
> How about an option that allows `C-x o' to escape from the modal 
> dialog of `read-multiple-choice'?

That dialog was AFAIU intentionally designed not to allow any such
escapes.

Once again: let's fix the particular problem you had, and that problem
was not with read-multiple-choice.

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 19 Dec 2023, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: rms@gnu.org,  emacs-devel@gnu.org
>> Date: Tue, 19 Dec 2023 12:57:04 -0600
>> 
>> How about an option that allows `C-x o' to escape from the 
>> modal 
>> dialog of `read-multiple-choice'?
>
>That dialog was AFAIU intentionally designed not to allow any 
>such
>escapes.
>
>Once again: let's fix the particular problem you had, and that 
>problem
>was not with read-multiple-choice.

Fixing (i.e., reducing) the strictness of Emacs's 
`read-multiple-choice' modal dialog would be worth the effort for 
me.  However, you don't agree that the current strictness is a 
problem.

Meanwhile, implementing a mechanism (re)display the cert info from 
`nsm-query-user' is not worth the effort for me (maybe someone 
else might find it worth doing).  It's already quite rare that 
users are even presented with cert info; it would be even more 
rare that a user who is presented with that info then takes the 
steps needed to discover that there's a way to redisplay the cert 
info (heck, very few users even check certs in the first place -- 
most people just hit "a"ccept at the prompt and continue).  The 
ratio of effort to user's-lives-improved is not high enough to 
cross the implementation threshold for me here.

Thanks for talking through the possibilities.  We disagree about 
modal dialog behavior, but being maintainer means making decisions 
sometimes, and it's helpful that you've made one here.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Jens Schmidt]

On 2023-12-19  21:18, Karl Fogel wrote:

> Thanks for talking through the possibilities.  We disagree about modal
> dialog behavior, but being maintainer means making decisions sometimes,
> and it's helpful that you've made one here.

Sorry for chiming in here, but this issue intrigued me.  So I tried some
other command where read-multiple-choice is used, namely `kill-buffer'
hen you try to kill a modified buffer.  And in that case, I could very
well C-x o out of the multiple choice prompt.  For example, to save the
buffer currently being killed with C-x C-s behind the back of the prompt.

So it seems that in principle read-multiple-choice should be able to do
that.  Probably it needs to be called this way or that way to allow that,
I don't know.

Re: [PATCH] Keep network security info buffers after use

[Andreas Schwab]

On Dez 20 2023, Jens Schmidt wrote:

> Sorry for chiming in here, but this issue intrigued me.  So I tried some
> other command where read-multiple-choice is used, namely `kill-buffer'
> hen you try to kill a modified buffer.  And in that case, I could very
> well C-x o out of the multiple choice prompt.  For example, to save the
> buffer currently being killed with C-x C-s behind the back of the prompt.

The diffence is the LONG-FORM optional argument.  In the case of
kill-buffer, it is controlled by use-short-answers.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> Date: Wed, 20 Dec 2023 22:34:22 +0100
> Cc: emacs-devel@gnu.org
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> 
> On 2023-12-19  21:18, Karl Fogel wrote:
> 
> > Thanks for talking through the possibilities.  We disagree about modal
> > dialog behavior, but being maintainer means making decisions sometimes,
> > and it's helpful that you've made one here.
> 
> Sorry for chiming in here, but this issue intrigued me.  So I tried some
> other command where read-multiple-choice is used, namely `kill-buffer'
> hen you try to kill a modified buffer.  And in that case, I could very
> well C-x o out of the multiple choice prompt.  For example, to save the
> buffer currently being killed with C-x C-s behind the back of the prompt.
> 
> So it seems that in principle read-multiple-choice should be able to do
> that.  Probably it needs to be called this way or that way to allow that,
> I don't know.

kill-buffer--possibly-save uses a different form of calling
read-multiple-choice, which presents a slightly different UI, see the
doc string of read-multiple-choice where it describes the LONG-FORM
argument.  One side effect of this way of invoking
read-multiple-choice is that the users must type long responses,
i.e. they cannot just press a single key; this would be annoying if
nsm used it.  Another side effect is that GUI dialogs cannot be used,
which I think would be a UX problem with nsm.  It's also slightly less
clear in the prompt text it shows.

Once again, the nsm prompt is AFAIU intentionally programmed to work
like it does, for more than one reason.  I don't think it's TRT to
change the way we call read-multiple-choice in this case, since the
nsm prompt could appear several time during fetching a URL, and being
able to press a single key is a huge bonus.

The best solution to the original problem suggested so far is what
Andreas suggested: a special command to show the information.  Patches
to that effect, as well as other ideas that don't affect how
read-multiple-choice works, are welcome.

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 21 Dec 2023, Eli Zaretskii wrote:
>Once again, the nsm prompt is AFAIU intentionally programmed to 
>work
>like it does, for more than one reason.  I don't think it's TRT 
>to
>change the way we call read-multiple-choice in this case, since 
>the
>nsm prompt could appear several time during fetching a URL, and 
>being
>able to press a single key is a huge bonus.

We would keep the ability to press a single key and have it 
respond instantly -- obviously that's an important part of the 
current user experience.

I was merely proposing that `C-x o' also work, so that the user 
has a familiar way to break temporarily out of the "next keypress 
is responded to instantly" mode and go do something in the window 
that is currently displaying the information on which the rmc 
prompt's question is based.

(The user already could do this by entering a recursive edit, but 
that way is much less familiar to many users than `C-x o' is.)

Making `C-x o' work does not imply breaking any of the current rmc 
behavior, unless there's something that I'm missing.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Andreas Schwab]

On Dez 21 2023, Karl Fogel wrote:

> (The user already could do this by entering a recursive edit, but that way
> is much less familiar to many users than `C-x o' is.)

Moving out of a short-form r-m-c requires entering a recursive edit,
otherwise there would be nothing that executes the keys.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 21 Dec 2023, Andreas Schwab wrote:
> On Dez 21 2023, Karl Fogel wrote:
>
>> (The user already could do this by entering a recursive edit, 
>> but that way
>> is much less familiar to many users than `C-x o' is.)
>
> Moving out of a short-form r-m-c requires entering a recursive 
> edit,
> otherwise there would be nothing that executes the keys.

Could we please establish first what we *want* the user experience 
to be?

Obviously `read-multiple-choice' needs to keep the "read a key and 
respond instantly" behavior that it has right now (in the calling 
configuration used by `nsm-query-user', that is).  To change that 
UX would be a major regression, and I'm not proposing to change 
it.  I'm merely proposing that `C-x o' do what the user expects -- 
because that key sequence is the obvious gateway to accomplishing 
a thing the user sometimes wants to accomplish.

If it turns out that there's simply no way to implement this 
behavior, then so be it -- I'll discover that when I go to 
implement it.  But generally it's possible to get Emacs to do what 
we want.  The question here is just determining what we want.

Take it on faith, for now, that we could make this happen.  Let's 
just discuss whether we *want* it, assuming we can have it.  If we 
decide we want it, I'll try to implement it, and I'll ask for help 
if I don't see the way.  If in the end we can't do it, fine, then 
we would be in exactly the situation we're now anyway.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Jens Schmidt
>  <jschmidt4gnu@vodafonemail.de>,  emacs-devel@gnu.org
> Date: Thu, 21 Dec 2023 17:10:49 -0600
> 
> On 21 Dec 2023, Andreas Schwab wrote:
> > On Dez 21 2023, Karl Fogel wrote:
> >
> >> (The user already could do this by entering a recursive edit, 
> >> but that way
> >> is much less familiar to many users than `C-x o' is.)
> >
> > Moving out of a short-form r-m-c requires entering a recursive
> > edit, otherwise there would be nothing that executes the keys.
> 
> Could we please establish first what we *want* the user experience 
> to be?

In the case in point, where read-multiple-choice is invoked by nsm for
the reasons of connection security, we _want_ the user to be able to
respond with one of the provided single-key options, and with nothing
else.

> Obviously `read-multiple-choice' needs to keep the "read a key and 
> respond instantly" behavior that it has right now (in the calling 
> configuration used by `nsm-query-user', that is).  To change that 
> UX would be a major regression, and I'm not proposing to change 
> it.  I'm merely proposing that `C-x o' do what the user expects -- 
> because that key sequence is the obvious gateway to accomplishing 
> a thing the user sometimes wants to accomplish.

If read-multiple-choice expects a single key, then we cannot allow
"C-x o", because those are two keys, not one.

> If it turns out that there's simply no way to implement this 
> behavior, then so be it -- I'll discover that when I go to 
> implement it.  But generally it's possible to get Emacs to do what 
> we want.  The question here is just determining what we want.

read-multiple-choice _does_ have a way of accepting responses longer
than one key -- that's what the LONG-FORM argument is for -- but that
comes with a price, and in the case in point we don't want to pay that
price.  In other cases, if a non-modal dialog is desired, the caller
should use LONG-FORM.

> Take it on faith, for now, that we could make this happen.  Let's 
> just discuss whether we *want* it, assuming we can have it.  If we 
> decide we want it, I'll try to implement it, and I'll ask for help 
> if I don't see the way.  If in the end we can't do it, fine, then 
> we would be in exactly the situation we're now anyway.

You have already heard from me what we want (and I repeat that above).
So I'm not sure why we still need to discuss that particular issue.

Re: [PATCH] Keep network security info buffers after use

[Stefan Kangas]

Karl Fogel <kfogel@red-bean.com> writes:

> What do people think of the attached behavior change?
>
> Summary: after the user is prompted about whether to accept a
> remote cert, the buffer(s) with information about the cert should
> stay around, instead of being killed like they currently are.

It would be useful, yes.  I'm not bit by this often, but it happened to
me this week, and it's pretty frustrating.  The only workaround I know
of is to manually type in the information into some other program.

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 22 Dec 2023 02:00:38 -0800
> 
> Karl Fogel <kfogel@red-bean.com> writes:
> 
> > What do people think of the attached behavior change?
> >
> > Summary: after the user is prompted about whether to accept a
> > remote cert, the buffer(s) with information about the cert should
> > stay around, instead of being killed like they currently are.
> 
> It would be useful, yes.  I'm not bit by this often, but it happened to
> me this week, and it's pretty frustrating.  The only workaround I know
> of is to manually type in the information into some other program.

I agree that it could be useful in some cases.  Andreas suggested a
special command to show this information -- do you think this would be
a good solution for this situation?

Re: [PATCH] Keep network security info buffers after use

[Jens Schmidt]

On 2023-12-22  12:51, Eli Zaretskii wrote:
>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Fri, 22 Dec 2023 02:00:38 -0800
>>
>> Karl Fogel <kfogel@red-bean.com> writes:
>>
>>> What do people think of the attached behavior change?
>>
>> It would be useful, yes.  I'm not bit by this often, but it happened to
>> me this week, and it's pretty frustrating.  The only workaround I know
>> of is to manually type in the information into some other program.
> 
> I agree that it could be useful in some cases.  Andreas suggested a
> special command to show this information -- do you think this would be
> a good solution for this situation?

I share Karl's opinion here that this could be too complex for the
problem at hand.

How about the following variation of Karl's patch, which hopefully
meets his request for simplicity and hopefully also these requests of
yours (as long as you do not count the additional multiple choice
option as something that must be revertable by option):

> It must be optional, probably off by default, and if it's on by
> default, there must be a way to get back old behavior.


diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 09f7ac52537..27107edc1c5 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -825,6 +825,7 @@ nsm-query-user
            (?f "forward page" "See next page")
            (?n "next" "Next certificate")
            (?p "previous" "Previous certificate")
+           (?k "keep" "Keep certificate details for further inspection")
            (?q "quit" "Quit details view")))
         (done nil))
     (save-window-excursion
@@ -916,7 +917,28 @@ nsm-query-user
                    (setq cert-index (mod (1- cert-index) (length pems)))
                    (insert (nth cert-index pems))
                    (goto-char (point-min))
-                   (read-only-mode)))))
+                   (read-only-mode)))
+
+                (?k
+                 ;; Keep certificate details.
+                 (let ((bufname
+                        (format "*Certificate Details for %s*"
+                                (nsm-certificate-part
+                                 (plist-get (car certs) :subject) "CN" t)))
+                       begin)
+                   (with-current-buffer (get-buffer-create bufname)
+                     (read-only-mode -1)
+                     (goto-char (point-max))
+                     (setq begin (point))
+                     (dolist (cert certs)
+                       (insert (gnutls-format-certificate
+                                (plist-get cert :pem)))
+                       (ensure-empty-lines 1))
+                     (goto-char begin)
+                     (read-only-mode))
+                   (message "Details appended to buffer %s" bufname)
+                   (sit-for 2)))))
+
             ;; Return the answer.
             (cadr answer))
         (kill-buffer cert-buffer)

Re: [PATCH] Keep network security info buffers after use

[Jens Schmidt]

On 2023-12-22  22:58, Jens Schmidt wrote:

> How about the following variation of Karl's patch, which hopefully
> meets his request for simplicity and hopefully also these requests of
> yours (as long as you do not count the additional multiple choice
> option as something that must be revertable by option):

I forgot about the header information, revised patch:

diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 09f7ac52537..4cedf0be88a 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -825,6 +825,7 @@ nsm-query-user
            (?f "forward page" "See next page")
            (?n "next" "Next certificate")
            (?p "previous" "Previous certificate")
+           (?k "keep" "Keep certificate details for further inspection")
            (?q "quit" "Quit details view")))
         (done nil))
     (save-window-excursion
@@ -916,7 +917,32 @@ nsm-query-user
                    (setq cert-index (mod (1- cert-index) (length pems)))
                    (insert (nth cert-index pems))
                    (goto-char (point-min))
-                   (read-only-mode)))))
+                   (read-only-mode)))
+
+                (?k
+                 ;; Keep certificate details.
+                 (let ((bufname
+                        (format "*Certificate Details for %s*"
+                                (nsm-certificate-part
+                                 (plist-get (car certs) :subject) "CN" t)))
+                       begin)
+                   (with-current-buffer (get-buffer-create bufname)
+                     (read-only-mode -1)
+                     (goto-char (point-max))
+                     (setq begin (point))
+                     (when status
+                       (insert (nsm-format-certificate status)))
+                     (insert message)
+                     (ensure-empty-lines 1)
+                     (dolist (cert certs)
+                       (insert (gnutls-format-certificate
+                                (plist-get cert :pem)))
+                       (ensure-empty-lines 1))
+                     (goto-char begin)
+                     (read-only-mode))
+                   (message "Details appended to buffer %s" bufname)
+                   (sit-for 2)))))
+
             ;; Return the answer.
             (cadr answer))
         (kill-buffer cert-buffer)

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> Date: Fri, 22 Dec 2023 22:58:38 +0100
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> 
> > I agree that it could be useful in some cases.  Andreas suggested a
> > special command to show this information -- do you think this would be
> > a good solution for this situation?
> 
> I share Karl's opinion here that this could be too complex for the
> problem at hand.

Seriously? how is it more complex than what you propose below?  The
new command's body should basically be the same code as what you
propose to add.  (And adding an option not to kill the buffer,
something I proposed at the beginning, is even less complex: add a
defcustom, a single 'if', and an erase-buffer call.)

> How about the following variation of Karl's patch, which hopefully
> meets his request for simplicity and hopefully also these requests of
> yours (as long as you do not count the additional multiple choice
> option as something that must be revertable by option):

Your proposal will cause the mini-window be resized in many cases,
because your changes make the prompt wider than the (default) frame
width.  Thus, it will "punish" many people in many cases, although in
99% of cases this additional response is not needed.  So it's a step
in the wrong direction, from where I stand.

I can only suggest again to use one of the alternatives proposed
above.

P.S. I really don't understand this insistence on the original idea
that I said was unacceptable to me, where two acceptable alternatives
were already suggested.  Why not take one of those alternatives? why
keep pushing in the direction to which I said I object?

Re: [PATCH] Keep network security info buffers after use

[Jens Schmidt]

On 2023-12-23  08:15, Eli Zaretskii wrote:
>> Date: Fri, 22 Dec 2023 22:58:38 +0100
>> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
>> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>>
>>> I agree that it could be useful in some cases.  Andreas suggested a
>>> special command to show this information -- do you think this would be
>>> a good solution for this situation?
>>
>> I share Karl's opinion here that this could be too complex for the
>> problem at hand.
> 
> Seriously? how is it more complex than what you propose below?

With my (possibly limited) imagination I cannot see from where you
would get that information that you would like to display *after* the
fetch/logon/connection attempt has completed.  Other than by storing
it unconditionally in some temporary or log-like buffer, which I
understand is also off-limits to you.

> P.S. I really don't understand this insistence on the original idea
> that I said was unacceptable to me, where two acceptable alternatives
> were already suggested.  Why not take one of those alternatives? why
> keep pushing in the direction to which I said I object?

My patch does not touch rmc.el, and I thought *that* was your main/only
concern.

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

Jens Schmidt wrote:
>How about the following variation of Karl's patch, which 
>hopefully
>meets his request for simplicity and hopefully also these 
>requests of
>yours (as long as you do not count the additional multiple choice
>option as something that must be revertable by option):

FWIW, my request is not for simplicity but for discoverability.

If we have a new, separate command for getting access to cert info 
that has already passed by on the screen (during the 
`read-multiple-choice' prompt), I don't think most users are ever 
going to know that that command exists -- unless we somehow tell 
them about it *at the time when they need to know it*.

Getting prompted by `nsm-query-user' is already quite rare and is 
usually a surprise when it happens (because it's an unexpected 
interruption in what is normally a familiar UI interaction), so 
it's not a situation conducive to pre-emptive investment in an 
exploratory acquisition of knowledge.  Whatever guidance the user 
is going to get about how to handle the surprise is best provided 
in real time during the surprise itself.

Now, maybe a solution like this would work:

* During `nsm-query-user', preserve the cert info.

* After `nsm-query-user' is done, display a message saying
  something like "Use `M-x nsm-display-certificates' to view
  certificate information.".

That message would be logged in the "*Messages*" buffer, of 
course, and these days experienced users know to look there.

I don't know if the new message would be left in the minibuffer 
for long after `nsm-query-user' is done, because I don't know what 
other things typically happen immediately afterwards that might 
replace that message with their own messages in the minibuffer. 
But at least the new message would be in "*Messages*".

Thoughts?

Eli Zaretskii wrote:
> If read-multiple-choice expects a single key, then we cannot
> allow "C-x o", because those are two keys, not one.

Well, note that it already allows one to enter a recursive edit, 
which can be thought of as an arbitrary number of keys (since the 
r-m-c prompt doesn't end until after the recursive edit ends).

I think maybe I haven't really understood your objection.  I can't 
tell which of these objections you're making:

a) An implementation objection (we have no technical way to treat 
   `C-x o' specially -- it can't be done), or

b) A UX objection (the user expects the next keystroke to take 
   some final action, therefore we shouldn't confuse the user by
   doing something that breaks that pattern), or

c) A security objection (the question that `nsm-query-user' is 
   asking via r-m-c is a sensitive question, and we would open up
   new security vulnerabilities by treating `C-x o' specially).

You might be making more than one of these?

> read-multiple-choice _does_ have a way of accepting responses 
> longer
> than one key -- that's what the LONG-FORM argument is for -- but 
> that
> comes with a price, and in the case in point we don't want to 
> pay that
> price.  In other cases, if a non-modal dialog is desired, the 
> caller
> should use LONG-FORM.

I have never argued for using the LONG-FORM style in this case, 
and never argued for paying that price.

> > Take it on faith, for now, that we could make this happen. 
> > Let's 
> > just discuss whether we *want* it, assuming we can have it. 
> > If we 
> > decide we want it, I'll try to implement it, and I'll ask for 
> > help 
> > if I don't see the way.  If in the end we can't do it, fine, 
> > then 
> > we would be in exactly the situation we're now anyway.
> 
> You have already heard from me what we want (and I repeat that 
> above).

We have heard from you what *you* want.  As per above, I -- 
perhaps among others -- haven't really understood the reasons why 
you want the thing you want, and why you don't want the other 
thing I proposed.  My question above is meant to elicit that 
understanding.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Kangas <stefankangas@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 23 Dec 2023 17:57:22 -0500
> 
> Now, maybe a solution like this would work:
> 
> * During `nsm-query-user', preserve the cert info.
> 
> * After `nsm-query-user' is done, display a message saying
>   something like "Use `M-x nsm-display-certificates' to view
>   certificate information.".
> 
> That message would be logged in the "*Messages*" buffer, of 
> course, and these days experienced users know to look there.
> 
> I don't know if the new message would be left in the minibuffer 
> for long after `nsm-query-user' is done, because I don't know what 
> other things typically happen immediately afterwards that might 
> replace that message with their own messages in the minibuffer. 
> But at least the new message would be in "*Messages*".
> 
> Thoughts?

That was more-or-less your original proposal.  I wasn't really
objected, but I wanted a knob to disable this keeping of the
information.

Also, please keep in mind that (a) some of the information is inserted
into a buffer only when the user presses 'd' to the initial prompt,
and then presses 'n' to view all the certificates; and (b) the very
next network connection will overwrite this information with new one,
so the information will be available only until then.  (Of course, we
could arrange for the information to persists longer than that, but
then the solution _really_ becomes complex, as we'd need some
mechanism to decide what to keep, and some other mechanism for
expunging the information.)

> I think maybe I haven't really understood your objection.  I can't 
> tell which of these objections you're making:
> 
> a) An implementation objection (we have no technical way to treat 
>    `C-x o' specially -- it can't be done), or
> 
> b) A UX objection (the user expects the next keystroke to take 
>    some final action, therefore we shouldn't confuse the user by
>    doing something that breaks that pattern), or
> 
> c) A security objection (the question that `nsm-query-user' is 
>    asking via r-m-c is a sensitive question, and we would open up
>    new security vulnerabilities by treating `C-x o' specially).
> 
> You might be making more than one of these?

All of them.  Except that not all of them are relevant to all of the
proposals, of course.

> > You have already heard from me what we want (and I repeat that 
> > above).
> 
> We have heard from you what *you* want.

And I wonder why is that not enough.

> As per above, I -- perhaps among others -- haven't really understood
> the reasons why you want the thing you want, and why you don't want
> the other thing I proposed.

I explained every reason, so I'm not sure why it cannot be understood.
I realize that you disagree, but that doesn't mean you don't
understand.

> My question above is meant to elicit that understanding.

I hope it is now even more clear.

Re: [PATCH] Keep network security info buffers after use

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Fri, 22 Dec 2023 02:00:38 -0800
>>
>> Karl Fogel <kfogel@red-bean.com> writes:
>>
>> > What do people think of the attached behavior change?
>> >
>> > Summary: after the user is prompted about whether to accept a
>> > remote cert, the buffer(s) with information about the cert should
>> > stay around, instead of being killed like they currently are.
>>
>> It would be useful, yes.  I'm not bit by this often, but it happened to
>> me this week, and it's pretty frustrating.  The only workaround I know
>> of is to manually type in the information into some other program.
>
> I agree that it could be useful in some cases.  Andreas suggested a
> special command to show this information -- do you think this would be
> a good solution for this situation?

My use case is that I want to make sure that a certificate is valid
before accepting it.  This inevitably means some manual inspection.

If we have a command that shows the certificate after the fact, IIUC, I
would have to abort the current operation, run the command to display
the details, and after examination manually retry whatever it is that I
was doing.  I suppose that's fine, but it could perhaps be more
streamlined.

Personally, I'd probably prefer entering a recursive edit, inspect it,
and hit ´C-M-c' to go back.  But to be honest, I only realized that
`recursive-edit' works there from reading this thread.  If I didn't
realize that, maybe other people won't find it either.

Perhaps we could simply do more to make `recursive-edit' discoverable
here?

For example, we could bind a new key to `recursive-edit' and advertize
it.  Or we could perhaps even bind `C-x o' to `recursive-edit'.  Or
something else entirely: we could announce the key binding in the buffer
showing the certificate.

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 24 Dec 2023 05:52:48 -0800
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I agree that it could be useful in some cases.  Andreas suggested a
> > special command to show this information -- do you think this would be
> > a good solution for this situation?
> 
> My use case is that I want to make sure that a certificate is valid
> before accepting it.  This inevitably means some manual inspection.

That is already supported: you type 'd' at the prompt, and then you
are presented with a buffer with the details, and can page through it
with several keys.

> Personally, I'd probably prefer entering a recursive edit, inspect it,
> and hit ´C-M-c' to go back.  But to be honest, I only realized that
> `recursive-edit' works there from reading this thread.  If I didn't
> realize that, maybe other people won't find it either.
> 
> Perhaps we could simply do more to make `recursive-edit' discoverable
> here?

There's no need to do that, since inspection is already supported, see
above.  If that is not enough, please tell why.

Using recursive-edit might be a general thing to solve such
situations, but nsm was coded to provide the inspection as a built-in
feature, while recursive-edit is an advanced feature not known to many
users, and not possible from the minibuffer in many cases (since
enable-recursive-minibuffers is nil by default).

Re: [PATCH] Keep network security info buffers after use

[Karl Fogel]

On 24 Dec 2023, Eli Zaretskii wrote:
>> From: Stefan Kangas <stefankangas@gmail.com>
>> My use case is that I want to make sure that a certificate is
>> valid before accepting it.  This inevitably means some manual
>> inspection.
>
>That is already supported: you type 'd' at the prompt, and then
>you are presented with a buffer with the details, and can page
>through it with several keys.
>
>> Personally, I'd probably prefer entering a recursive edit,
>> inspect it, and hit ´C-M-c' to go back.  But to be honest, I
>> only realized that `recursive-edit' works there from reading
>> this thread.  If I didn't realize that, maybe other people
>> won't find it either.
>> 
>> Perhaps we could simply do more to make `recursive-edit'
>> discoverable here?
>
>There's no need to do that, since inspection is already
>supported, see above.  If that is not enough, please tell why.

The reason 'd' is not enough is that the process of inspecting the 
cert may involve (in my case, always involves) running more Emacs 
commands, usually from the buffer containing the cert info.

For example: grabbing the cert info into the isearch search ring, 
then switching to another buffer (perhaps via `find-file') that 
contains pre-recorded known-good cert info, and quickly searching 
for the same cert info to see if there's a match.

But that's just one way.  For certain certs, I have other, 
more-automated Emacs-based infrastructure for checking them.  When 
it comes to certs, I don't want to rely on quick human-eye 
comparisons.  I want to use the full power of Emacs.  But the 
current functionality from typing 'd' does not give me that.  (The 
recursive edit does, and now I know about it, but it's hard to 
discover and thus not of practical use to most users right now -- 
as Stefan pointed out, he only learned it from this thread.)

And even if one *were* relying purely on a human-eye comparison, 
the tool in which one would be likely to call up the known-good 
fingerprint, etc, for checking would be Emacs... which 'd' doesn't 
allow.  It just shows you the received cert info in a window, 
while leaving you trapped in the r-m-c modal prompt.

It's not really very useful.

>Using recursive-edit might be a general thing to solve such
>situations, but nsm was coded to provide the inspection as a
>built-in feature, while recursive-edit is an advanced feature
>not known to many users, and not possible from the minibuffer in
>many cases (since enable-recursive-minibuffers is nil by
>default).

"The inspection" can be an arbitrarily complex process, during 
which the user should have all the usual power of Emacs available.

Best regards,
-Karl

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Sun, 24 Dec 2023 10:34:32 -0500
> 
> "The inspection" can be an arbitrarily complex process, during 
> which the user should have all the usual power of Emacs available.

You always have the possibility of aborting the connection with C-g
and then doing all those arbitrarily complex processes.  There's a
limit to what a single command should allow as part of its supported
workflow. Besides, if those processes take a long time, the connection
will time out anyway.

So I think by trying to cater to some insanely complex and very rare
cases, we risk over-engineering this beyond any reason, and -- what's
worse -- will complicate everybody's life where 99% of cases the life
should be much simpler.

Let's not do that.

Re: [PATCH] Keep network security info buffers after use

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
>> Date: Sun, 24 Dec 2023 10:34:32 -0500
>> 
>> "The inspection" can be an arbitrarily complex process, during 
>> which the user should have all the usual power of Emacs available.
>
> You always have the possibility of aborting the connection with C-g
> and then doing all those arbitrarily complex processes.

But C-g dismisses the *Certificate Details* buffer, so that makes an
"arbitrarily complex" inspection somewhat hard to proceed with?

Sorry for butting in - no strong intuition re. what the better
UX/complexity tradeoff is between (a) letting the certificate buffers
linger after aborting (b) letting users enter recursive edits (TIL
that's a thing with rmc, neat) (c) adding a command to… do something.

All I can say is that the first time I met this prompt, my reflexes were

* C-x o                 - "Ah, right; rmc, can't do that"
* C-g; C-x b Cert TAB   - "Oh, drats; the buffer was killed"

So FWIW (a) would have had my vote, and FWIW² I'd have been fine with it
being optional & off by default.  But now that I know about rmc
leveraging query-replace-map and the C-r escape hatch, no strong
opinion.

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Karl Fogel <kfogel@red-bean.com>,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 25 Dec 2023 18:35:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Karl Fogel <kfogel@red-bean.com>
> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> >> Date: Sun, 24 Dec 2023 10:34:32 -0500
> >> 
> >> "The inspection" can be an arbitrarily complex process, during 
> >> which the user should have all the usual power of Emacs available.
> >
> > You always have the possibility of aborting the connection with C-g
> > and then doing all those arbitrarily complex processes.
> 
> But C-g dismisses the *Certificate Details* buffer, so that makes an
> "arbitrarily complex" inspection somewhat hard to proceed with?

Who said that those complex processes need those details?  No
specifics were brought up about those complex processes, so we are all
basically waving hands, and each one of us has some different mental
picture about what's involved.  This doesn't tend to lead towards
effective discussion with any useful outcome.

> All I can say is that the first time I met this prompt, my reflexes were
> 
> * C-x o                 - "Ah, right; rmc, can't do that"
> * C-g; C-x b Cert TAB   - "Oh, drats; the buffer was killed"

I guess you haven't read the prompt, because my reflex was to type 'd'
and read there.

> So FWIW (a) would have had my vote, and FWIW² I'd have been fine with it
> being optional & off by default.  But now that I know about rmc
> leveraging query-replace-map and the C-r escape hatch, no strong
> opinion.

Thanks for sharing, so I guess your personal conclusion is that
nothing needs to be done, yes?

Re: [PATCH] Keep network security info buffers after use

[Tomas Hlavaty]

On Mon 25 Dec 2023 at 20:51, Eli Zaretskii <eliz@gnu.org> wrote:
> I guess you haven't read the prompt, because my reflex was to type 'd'
> and read there.

the next step is to copy&paste the details somewhere and that does not
work if i remember correctly

Re: [PATCH] Keep network security info buffers after use

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> From: Karl Fogel <kfogel@red-bean.com>
>> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
>> >> Date: Sun, 24 Dec 2023 10:34:32 -0500
>> >> 
>> >> "The inspection" can be an arbitrarily complex process, during 
>> >> which the user should have all the usual power of Emacs available.
>> >
>> > You always have the possibility of aborting the connection with C-g
>> > and then doing all those arbitrarily complex processes.
>> 
>> But C-g dismisses the *Certificate Details* buffer, so that makes an
>> "arbitrarily complex" inspection somewhat hard to proceed with?
>
> Who said that those complex processes need those details?  No
> specifics were brought up about those complex processes, so we are all
> basically waving hands, and each one of us has some different mental
> picture about what's involved.  This doesn't tend to lead towards
> effective discussion with any useful outcome.

(Point taken)

>> All I can say is that the first time I met this prompt, my reflexes were
>> 
>> * C-x o                 - "Ah, right; rmc, can't do that"
>> * C-g; C-x b Cert TAB   - "Oh, drats; the buffer was killed"
>
> I guess you haven't read the prompt, because my reflex was to type 'd'
> and read there.

Apologies for not being clear enough; I did read "the prompt" (the
accept-choices one) and did immediately hit 'd'.  In my message, "this
prompt" referred to the details-choices prompt, when faced with the
*Certificate Details* buffer.

IOW my reflex when faced with this kind of infodump is moving point
there and highlighting stuff as I read through.  Full-screen paging back
and forth is not my preferred reading method, even for cursory skimming.

>> So FWIW (a) would have had my vote, and FWIW² I'd have been fine with it
>> being optional & off by default.  But now that I know about rmc
>> leveraging query-replace-map and the C-r escape hatch, no strong
>> opinion.
>
> Thanks for sharing, so I guess your personal conclusion is that
> nothing needs to be done, yes?

Right, though I'd still take an opt-in knob to let *Certificate Details*
linger post-quit over having to remember about recursive edits.

Apologies if a convincing counter-argument has been made against such a
knob; my attention to the list these past couple of days might not have
been as sharp as I would have wished.

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: kfogel@red-bean.com,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 26 Dec 2023 15:43:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> So FWIW (a) would have had my vote, and FWIW² I'd have been fine with it
> >> being optional & off by default.  But now that I know about rmc
> >> leveraging query-replace-map and the C-r escape hatch, no strong
> >> opinion.
> >
> > Thanks for sharing, so I guess your personal conclusion is that
> > nothing needs to be done, yes?
> 
> Right, though I'd still take an opt-in knob to let *Certificate Details*
> linger post-quit over having to remember about recursive edits.
> 
> Apologies if a convincing counter-argument has been made against such a
> knob; my attention to the list these past couple of days might not have
> been as sharp as I would have wished.

There were two suggestions that I'm okay with: either to have a user
option to control whether this information is kept (until the next
connection which needs a certificate confirmation, which will then
erase the information about the previous certificate), or adding a
separate command to reproduce these details in a buffer.  If someone
submits a patch along these lines, we could all be at least somewhat
happier.

Re: [PATCH] Keep network security info buffers after use

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> There were two suggestions that I'm okay with: either to have a user
> option to control whether this information is kept (until the next
> connection which needs a certificate confirmation, which will then
> erase the information about the previous certificate), or adding a
> separate command to reproduce these details in a buffer.  If someone
> submits a patch along these lines, we could all be at least somewhat
> happier.

Did you consider a change like this?

diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 09f7ac52537..e69b0557478 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -919,8 +919,8 @@ nsm-query-user
                    (read-only-mode)))))
             ;; Return the answer.
             (cadr answer))
-        (kill-buffer cert-buffer)
-        (kill-buffer buffer)))))
+        (bury-buffer cert-buffer)
+        (bury-buffer buffer)))))

 (defun nsm-save-host (host port status what problems permanency)
   (let* ((id (nsm-id host port))

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 26 Dec 2023 16:09:07 -0600
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There were two suggestions that I'm okay with: either to have a user
> > option to control whether this information is kept (until the next
> > connection which needs a certificate confirmation, which will then
> > erase the information about the previous certificate), or adding a
> > separate command to reproduce these details in a buffer.  If someone
> > submits a patch along these lines, we could all be at least somewhat
> > happier.
> 
> Did you consider a change like this?

Yes, it's basically one of the two I described above.  It was already
proposed here:

  https://lists.gnu.org/archive/html/emacs-devel/2023-12/msg00690.html

where I also mentioned some of the caveats that will need to be taken
care of.

Re: [PATCH] Keep network security info buffers after use

[Tomas Hlavaty]

On Mon 25 Dec 2023 at 18:35, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
> Sorry for butting in - no strong intuition re. what the better
> UX/complexity tradeoff is between (a) letting the certificate buffers
> linger after aborting (b) letting users enter recursive edits (TIL
> that's a thing with rmc, neat) (c) adding a command to… do something.

another option: There should not be modal UI that constrains my options
vi-style.  The whole process is sequential so it could display the
information in the same output buffer, and clear the buffer at the
beginning of each step.

> * C-x o                 - "Ah, right; rmc, can't do that"
> * C-g; C-x b Cert TAB   - "Oh, drats; the buffer was killed"

i find it also very frustrating

Re: [PATCH] Keep network security info buffers after use

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, stefankangas@gmail.com,
> 	emacs-devel@gnu.org
> Date: Mon, 25 Dec 2023 21:18:53 +0100
> 
> On Mon 25 Dec 2023 at 18:35, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
> > Sorry for butting in - no strong intuition re. what the better
> > UX/complexity tradeoff is between (a) letting the certificate buffers
> > linger after aborting (b) letting users enter recursive edits (TIL
> > that's a thing with rmc, neat) (c) adding a command to… do something.
> 
> another option: There should not be modal UI that constrains my options
> vi-style.  The whole process is sequential so it could display the
> information in the same output buffer, and clear the buffer at the
> beginning of each step.

I think this particular UI was intentionally made modal in the nsm
case.

> i find it also very frustrating

This is Emacs: you can easily code around your personal frustration.
Here, we are talking about what the garden-variety users should see.

RE: [External] : Re: [PATCH] Keep network security info buffers after use

[Drew Adams]

> Perhaps we could simply do more to make `recursive-edit' discoverable
> here?
> 
> For example, we could bind a new key to `recursive-edit' and advertize
> it.  Or we could perhaps even bind `C-x o' to `recursive-edit'.  Or
> something else entirely: we could announce the key binding in the buffer
> showing the certificate.

[CAVEAT: Not following this thread at all - just happened
to notice this part.]

Take a look at this tiny library/file.  It does what you
suggested (with a minor mode).  And it makes the levels
of recursive edit more evident (distinguished).  The key
it uses for entering is the same as the longstanding key
for exiting, `C-M-c'.

(I definitely recommend against (re)binding `C-x o', BTW.)

Code: 

https://www.emacswiki.org/emacs/download/rec-edit.el

Description (see also Commentary):

https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el

(If this or similar were added to vanilla Emacs, whether
to use a minor mode or just turn the behavior on would
be something for you to decide.)