emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: [PATCH] Keep network security info buffers after use
Date: Sun, 24 Dec 2023 08:14:07 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]