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: Mon, 18 Dec 2023 23:56:03 -0600 Message-ID: <87sf3ywxak.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> 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="14465"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 19 06:57:02 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 1rFT6E-0003Zu-6F for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Dec 2023 06:57:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFT5Q-0003jD-WC; Tue, 19 Dec 2023 00:56:13 -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 1rFT5N-0003ik-NB for emacs-devel@gnu.org; Tue, 19 Dec 2023 00:56:10 -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 1rFT5K-0004qg-Ve; Tue, 19 Dec 2023 00:56:09 -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=9XlRlyRbnQ5XT/A2rO5lxNEjK45+szMfHPdkPmdqav0=; t=1702965366; x=1704174966; b=daZdmsDlqlSWlaRQcNPy5fdxhzRwRv/pf8xVc7uR6U3CpPJLUWw9KqDD5EL/uiwd8ZEPOQibkS/ ZBqoJAeUsHMuoY3qKdf5GZIS2sNr3VMtkJYUS+yf709U0CfwqFRC7F0jEmHbozkepsgPk1HkwcJmw TEd9T5/jFuY4HOgWos/yaja31mdhQy6QBCPNe9ViZgEZ/4EFHbBzgWzwUx6q88dAVpYhjlFSPsExw 2HmoQNa9g3NQvnxIStR8l3NJplFrFPeX/kmUGuQU7BSv93s6qwq/VCEmQTHvExUaAoV+WZgwBc91i 2kuphqMQbfj6oGqO03R/8P+fsALYN+87pphQ==; Original-Received: from [2601:240:c400:76::5755] (port=37122 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 1rFT5J-008Jlt-0R; Tue, 19 Dec 2023 05:56:05 +0000 In-Reply-To: (Richard Stallman's message of "Mon, 18 Dec 2023 22:49:36 -0500") 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:313997 Archived-At: On 18 Dec 2023, Richard Stallman wrote: > > Summary: after the user is prompted about whether to accept a > > remote cert, the buffer(s) with information about the cert > > should > > stay around, instead of being killed like they currently are. > >If this would be an improvement, should we go further and >preserve >this information in the file system for logging even after the >Emacs >process is killed? Perhaps in the user's .emacs.d directory? I think it would be sufficient to just let the user temporarily leave the `read-multiple-choice' prompt and go into the displayed buffer that contains the cert info. If the user then wants to save that information somehow, she can do so. If we were to always save the information, unconditionally, then we would have to decide where to save it, and come up with a way to inform the user of where it is saved. And in most cases the user probably does not need it to be saved for later examination anyway. In other words, just giving the user agency at the critical moment would be the best solution, I think. I'm still waiting to hear if there is approval for, or concern about, the idea of letting `C-x o' depart (presumably temporarily) from a `read-multiple-choice' prompt. Best regards, -Karl