From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Keep network security info buffers after use Date: Sun, 24 Dec 2023 08:14:07 +0200 Message-ID: <83h6k8cekw.fsf@gnu.org> References: <87plz4irev.fsf@red-bean.com> <83frzufo9x.fsf@gnu.org> <87plywedd9.fsf@red-bean.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29843"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jschmidt4gnu@vodafonemail.de, stefankangas@gmail.com, emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 07:15:19 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rHHlf-0007Zc-4F for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 07:15:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHHkh-0007sn-Al; Sun, 24 Dec 2023 01:14:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHHke-0007sJ-N9 for emacs-devel@gnu.org; Sun, 24 Dec 2023 01:14:16 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHHkd-0005v7-Kz; Sun, 24 Dec 2023 01:14:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=flVPNYFJuIZLOy7Ey08fBX7jgFhbXIAq5KuRbEtAikE=; b=rHAP+iLbzEv2 ZH+Skhrwevzi/aDrg10buuNSjtCyIj7lY1Y+kSv9hQAmW369wO/J7u1GrALGJicFvwwIjouma80rp XMyqN8ZSsFrnU/AP/MRJpGoX1ladtDcByRf0FeMoCiD7YZDA6mARYjgDTdxaHwlq5L2pCUlSC3hbi jhF+PiyGR8dGUsxgqhN9FovjE7qBmacQYvA5HnHs7u2e6iPfI6WOa+OpVsWF0VgD0QIvsabWZkK47 7sGYqp1Lgjktyn2+vHPt7q+S39FqOhqDbtcUhnsjmA2DPz7eotUFJyesjgc1Np9BLJuiQHlp3GYqE 39S1iuXNqdZ7ymQV3lAGAw==; In-Reply-To: <87plywedd9.fsf@red-bean.com> (message from Karl Fogel on Sat, 23 Dec 2023 17:57:22 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314114 Archived-At: > From: Karl Fogel > Cc: Eli Zaretskii , Stefan Kangas , > 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.