From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Keep network security info buffers after use Date: Sat, 23 Dec 2023 17:57:22 -0500 Message-ID: <87plywedd9.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> <83frzufo9x.fsf@gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1087"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Stefan Kangas , emacs-devel@gnu.org To: Jens Schmidt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 23 23:58: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 1rHAwk-00005S-Ko for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Dec 2023 23:58:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHAvz-0000zb-W9; Sat, 23 Dec 2023 17:57:32 -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 1rHAvy-0000zR-R8 for emacs-devel@gnu.org; Sat, 23 Dec 2023 17:57:30 -0500 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHAvx-00066C-1k; Sat, 23 Dec 2023 17:57:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID:Date: Reply-To:References:In-Reply-To:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=hXvUsXflLzWYqUXADxRBEMD7csKfmVuTSPLrs9l8xyg=; t=1703372246; x=1704581846; b=ax8wCY7+feA4VIb+KZkyV5hYjY/I0PKFLm2u0GXUtKS10CpOylVEShLAX6iEeMpDjBZ50XgTJ67 wHzZbS9O647c6VOzVI0fJP+zEc5LUOv7sNhpp2+0DkcsTbUrAkJwLylQSn44EruKIjpDCUWSHKVcp X/4pjjgHF3pGVcwCcH84E1KvrIDN+PcR6wv/meiDaxYUq9VZudbbdu6m0pHn0Hy8xgIssjHVjHrTI bqGN/Sz4W1QD3kCVww4s2rKq4wXJ3WU/FxrRo0igLAFSd0Dr94OD1s9LPMuF0dQjrYEOA1ThIjcYv IID2uayYWFnkFPaFpJJiCBVwye1OfJqWgL8A==; Original-Received: from [207.38.173.55] (port=42593 helo=libq) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rHAvr-00EnDn-Lt; Sat, 23 Dec 2023 22:57:23 +0000 In-Reply-To: (Jens Schmidt's message of "Fri, 22 Dec 2023 22:58:38 +0100") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:314108 Archived-At: 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