all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Karl Fogel <kfogel@red-bean.com>
Cc: jschmidt4gnu@vodafonemail.de, stefankangas@gmail.com,
	emacs-devel@gnu.org
Subject: Re: [PATCH] Keep network security info buffers after use
Date: Sun, 24 Dec 2023 08:14:07 +0200	[thread overview]
Message-ID: <83h6k8cekw.fsf@gnu.org> (raw)
In-Reply-To: <87plywedd9.fsf@red-bean.com> (message from Karl Fogel on Sat, 23 Dec 2023 17:57:22 -0500)

> 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	other threads:[~2023-12-24  6:14 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-17 19:02 [PATCH] Keep network security info buffers after use Karl Fogel
2023-12-17 19:27 ` Eli Zaretskii
2023-12-17 23:27   ` Karl Fogel
2023-12-18 17:36     ` Eli Zaretskii
2023-12-19  0:00       ` Karl Fogel
2023-12-19  5:31         ` tomas
2023-12-19 12:34         ` Eli Zaretskii
2023-12-19 12:50           ` tomas
2023-12-19 13:05             ` Eli Zaretskii
2023-12-20 22:43           ` Andreas Schwab
2023-12-21  6:45             ` Eli Zaretskii
2023-12-17 21:03 ` Andreas Schwab
2023-12-19  3:49 ` Richard Stallman
2023-12-19  5:56   ` Karl Fogel
2023-12-19 12:51     ` Eli Zaretskii
2023-12-19 13:10       ` tomas
2023-12-19 18:57       ` Karl Fogel
2023-12-19 19:08         ` Eli Zaretskii
2023-12-19 20:18           ` Karl Fogel
2023-12-20 21:34             ` Jens Schmidt
2023-12-20 22:26               ` Andreas Schwab
2023-12-21  6:29               ` Eli Zaretskii
2023-12-21 17:38                 ` Karl Fogel
2023-12-21 18:43                   ` Andreas Schwab
2023-12-21 23:10                     ` Karl Fogel
2023-12-22  7:29                       ` Eli Zaretskii
2023-12-22 10:00 ` Stefan Kangas
2023-12-22 11:51   ` Eli Zaretskii
2023-12-22 21:58     ` Jens Schmidt
2023-12-22 22:10       ` Jens Schmidt
2023-12-23  7:15       ` Eli Zaretskii
2023-12-23 10:46         ` Jens Schmidt
2023-12-23 22:57       ` Karl Fogel
2023-12-24  6:14         ` Eli Zaretskii [this message]
2023-12-24 13:52     ` Stefan Kangas
2023-12-24 14:51       ` Eli Zaretskii
2023-12-24 15:34         ` Karl Fogel
2023-12-24 16:28           ` Eli Zaretskii
2023-12-25 17:35             ` Kévin Le Gouguec
2023-12-25 18:51               ` Eli Zaretskii
2023-12-25 20:23                 ` Tomas Hlavaty
2023-12-26 14:43                 ` Kévin Le Gouguec
2023-12-26 17:01                   ` Eli Zaretskii
2023-12-26 22:09                     ` Stefan Kangas
2023-12-27 12:54                       ` Eli Zaretskii
2023-12-25 20:18               ` Tomas Hlavaty
2023-12-27 12:35                 ` Eli Zaretskii
2023-12-24 18:42       ` [External] : " Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h6k8cekw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jschmidt4gnu@vodafonemail.de \
    --cc=kfogel@red-bean.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.