[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Keep network security info buffers after use
From: |
Karl Fogel |
Subject: |
Re: [PATCH] Keep network security info buffers after use |
Date: |
Sat, 23 Dec 2023 17:57:22 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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, (continued)
Re: [PATCH] Keep network security info buffers after use, Stefan Kangas, 2023/12/22
Re: [PATCH] Keep network security info buffers after use, Stefan Kangas, 2023/12/24
Re: [PATCH] Keep network security info buffers after use, Eli Zaretskii, 2023/12/24
Re: [PATCH] Keep network security info buffers after use, Karl Fogel, 2023/12/24
Re: [PATCH] Keep network security info buffers after use, Eli Zaretskii, 2023/12/24
Re: [PATCH] Keep network security info buffers after use, Kévin Le Gouguec, 2023/12/25
Re: [PATCH] Keep network security info buffers after use, Eli Zaretskii, 2023/12/25
Re: [PATCH] Keep network security info buffers after use, Tomas Hlavaty, 2023/12/25
Re: [PATCH] Keep network security info buffers after use, Kévin Le Gouguec, 2023/12/26
Re: [PATCH] Keep network security info buffers after use, Eli Zaretskii, 2023/12/26