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: Sun, 24 Dec 2023 10:34:32 -0500 Message-ID: <87mstzwr5j.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> <83frzufo9x.fsf@gnu.org> <838r5jd56w.fsf@gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11301"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Kangas , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 16:35:36 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 1rHQVr-0002fL-VG for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 16:35:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHQUx-0003BL-CN; Sun, 24 Dec 2023 10:34:39 -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 1rHQUv-0003B1-Ct for emacs-devel@gnu.org; Sun, 24 Dec 2023 10:34:37 -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 1rHQUt-00006X-81; Sun, 24 Dec 2023 10:34:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Reply-To:References:In-Reply-To:Subject:Cc:To: From:Sender:Content-ID:Content-Description; bh=9AZs9eHK18XEhsFOsxUZz5lUC/NhDMJ1O5CRWDg9Y/4=; t=1703432074; x=1704641674; b=kR9NrBXP8OTK3fBVbqtyfSOC4PQPoP2xHMcW7BEwFCr6gNC7b2lcyR3OHXVM70qb23o1ZWuHl/+ EBB32i7Z0oct84unUjwvAU3cZFDjch8Jl0NqE0pwW4gXX8ASKO08pFC7NiPDsJ1NNkDvCEe1Niz05 WTTBjFsLN5FYzL9CwF41mCYVlAG5/0dwIGtc9GTw6rjSzclDsq83mrTKPC6th2bIQlEUV98H+omDz s78c6/DV6Q5S4eaPyO38GxONTzAyKOILUjjJOL4vYJ6qzxpfCeZCwRYf1bpO3K80BCwLkruvIu3eJ 2zRoImD+TJAF3QRdBYLdSYxN+Zgqh75eH+XQ==; Original-Received: from [207.38.173.55] (port=15537 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 1rHQUr-00HCF4-0Q; Sun, 24 Dec 2023 15:34:33 +0000 In-Reply-To: <838r5jd56w.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 24 Dec 2023 16:51:35 +0200") 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:314135 Archived-At: On 24 Dec 2023, Eli Zaretskii wrote: >> From: Stefan Kangas >> My use case is that I want to make sure that a certificate is >> valid before accepting it. This inevitably means some manual >> inspection. > >That is already supported: you type 'd' at the prompt, and then >you are presented with a buffer with the details, and can page >through it with several keys. > >> Personally, I'd probably prefer entering a recursive edit, >> inspect it, and hit =C2=B4C-M-c' to go back. But to be honest, I >> only realized that `recursive-edit' works there from reading >> this thread. If I didn't realize that, maybe other people >> won't find it either. >>=20 >> Perhaps we could simply do more to make `recursive-edit' >> discoverable here? > >There's no need to do that, since inspection is already >supported, see above. If that is not enough, please tell why. The reason 'd' is not enough is that the process of inspecting the=20 cert may involve (in my case, always involves) running more Emacs=20 commands, usually from the buffer containing the cert info. For example: grabbing the cert info into the isearch search ring,=20 then switching to another buffer (perhaps via `find-file') that=20 contains pre-recorded known-good cert info, and quickly searching=20 for the same cert info to see if there's a match. But that's just one way. For certain certs, I have other,=20 more-automated Emacs-based infrastructure for checking them. When=20 it comes to certs, I don't want to rely on quick human-eye=20 comparisons. I want to use the full power of Emacs. But the=20 current functionality from typing 'd' does not give me that. (The=20 recursive edit does, and now I know about it, but it's hard to=20 discover and thus not of practical use to most users right now --=20 as Stefan pointed out, he only learned it from this thread.) And even if one *were* relying purely on a human-eye comparison,=20 the tool in which one would be likely to call up the known-good=20 fingerprint, etc, for checking would be Emacs... which 'd' doesn't=20 allow. It just shows you the received cert info in a window,=20 while leaving you trapped in the r-m-c modal prompt. It's not really very useful. >Using recursive-edit might be a general thing to solve such >situations, but nsm was coded to provide the inspection as a >built-in feature, while recursive-edit is an advanced feature >not known to many users, and not possible from the minibuffer in >many cases (since enable-recursive-minibuffers is nil by >default). "The inspection" can be an arbitrarily complex process, during=20 which the user should have all the usual power of Emacs available. Best regards, -Karl