From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arsen =?UTF-8?Q?Arsenovi=C4=87?= via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled Date: Tue, 19 Nov 2024 13:33:03 +0100 Message-ID: <86wmgz769s.fsf@aarsen.me> References: <8734vwq06i.fsf@aarsen.me> <871qbflg53.fsf@aarsen.me> <87h6kbxgzl.fsf@neverwas.me> <87jzp6is0s.fsf@aarsen.me> <87ttoas466.fsf@neverwas.me> <878r5mm3el.fsf@gmx.de> <875y0qrmhj.fsf@neverwas.me> <871qbdmagw.fsf@gmx.de> <87bkahlzzp.fsf@neverwas.me> <868r5lszxm.fsf@aarsen.me> <87plywlus1.fsf@gmx.de> <86r0jcn100.fsf@aarsen.me> <87h6k8kk4l.fsf@gmx.de> <867cl3kh4p.fsf@aarsen.me> <83a5pzde0a.fsf@gnu.org> <86h6k77qco.fsf@aarsen.me> <87v88nk5md.fsf@gmx.de> <86y1dj4l71.fsf@aarsen.me> <87le9jjyu6.fsf@gmx.de> <8734vlflpf.fsf@aarsen.me> <87bka9ic18.fsf@gmx.de> Reply-To: Arsen =?UTF-8?Q?Arsenovi=C4=87?= Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40152"; mail-complaints-to="usenet@ciao.gmane.io" Cc: damien@cassou.me, Eli Zaretskii , 67937@debbugs.gnu.org, jp@neverwas.me To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 19 13:34:31 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tDNR9-000AE6-3b for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Nov 2024 13:34:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tDNQi-0007ga-Ax; Tue, 19 Nov 2024 07:34:04 -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 1tDNQg-0007fw-Q6 for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 07:34:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tDNQg-0005KL-HA for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 07:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=YoistzgNEZsBuaE72idawG1vrWElwTRVjHBnVmVowwk=; b=nxxlC0HXd0GABD41MpK+gQxX5wP34RyenrAcaFUjC3OtMDeroOzS5TlaexlYHGzbt+Nt3Xg6Qx4TizqVHo+Gf3QzZFX1zVAmTXirkh8fP8sXaLxu9SS6jt+V09DrIJMROUf/oiJckrzlT3X1x2RrM44Lo0erdbUqJC1+lnfEhZ8lEbJB0FC625lj2ZXCZJgdeMTT6abj9so0KuPs/TpUx0zRhHOV2/yZw52S/QOuN47b+SzMAse5YYw4l+2Dr+jJPVJRfm4Y8ZXHdt79pcxt2p7NCiL4BFX0qJiEXU0YjkMnTS3Tv6sfmchAauRrBSZrT4EvyklGIFP98Nctpko+BQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tDNQg-0003Q6-6s for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 07:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Arsen =?UTF-8?Q?Arsenovi=C4=87?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2024 12:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67937 X-GNU-PR-Package: emacs Original-Received: via spool by 67937-submit@debbugs.gnu.org id=B67937.173201962813120 (code B ref 67937); Tue, 19 Nov 2024 12:34:02 +0000 Original-Received: (at 67937) by debbugs.gnu.org; 19 Nov 2024 12:33:48 +0000 Original-Received: from localhost ([127.0.0.1]:41418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDNQR-0003PX-PM for submit@debbugs.gnu.org; Tue, 19 Nov 2024 07:33:48 -0500 Original-Received: from mout-p-101.mailbox.org ([80.241.56.151]:58854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDNQP-0003PJ-Hw for 67937@debbugs.gnu.org; Tue, 19 Nov 2024 07:33:46 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Xt3mz4XG2z9t8l; Tue, 19 Nov 2024 13:33:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1732019587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YoistzgNEZsBuaE72idawG1vrWElwTRVjHBnVmVowwk=; b=KmJ8I6Vun7rSJRsUN/Z1Arg29TZSbJ0ac8nZ9VS7TzVoylFSlfxzwFXqfBK9NjavJ3Fifb LbSDEqS0x0M653BF3/l2mTfvKZLy6AoCWONMlwim67nx4MIpnAnBS7uLUcTgsjc9tPVmBS fO+o09n+fGupu9B3w7eV+twITOAfH7sfHlqqHYNgUETheLbhdWiSGEi9mCJ5kfXtsnwHWa oZZ3OpxtK8nw01m7q3WMNpTZshrNhwIQGCVBCnuLsUs9i6s7ICz24i+YUmBuP18lpmptf9 vFkQJ0MdiTwknb47yoBC4fStRIsrKekg4tVAMIsfwejJVYKtXj6atZiMTRrWKQ== In-Reply-To: <87bka9ic18.fsf@gmx.de> (Michael Albinus's message of "Fri, 29 Dec 2023 10:38:27 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295632 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, Sorry for responding late. I'm yet to be able to catch whatever is triggering this bug. At this point, I suspect 'let' is simply broken somehow, and not undoing its work in some odd circumstances. I'd love to know how to efficiently create a trace every time file-name-handler-alist gets set to nil and never recovered without bogging down all of Emacs, but I've not had time to hack the Emacs core yet to do such a thing. I've attempted: =2D-8<---------------cut here---------------start------------->8--- (defvar arsen--watch-file-name-handler-alist-guard nil) (defvar arsen--watch-file-name-handler-alist-depth 0) (defun arsen--foo-el-log-buffer () (or (get-buffer "*FooEl*") (with-current-buffer (get-buffer-create "*FooEl*") (messages-buffer-mode) (current-buffer)))) (defun arsen--watch-file-name-handler-alist (symbol newval operation where) (setq arsen--watch-file-name-handler-alist-depth (+ arsen--watch-file-name-handler-alist-depth (pcase operation ('let 1) ('unlet -1) (otherwise 0)))) (if (or (member operation '(let unlet))) nil (with-current-buffer (arsen--foo-el-log-buffer) (let ((inhibit-read-only t) (standard-output (current-buffer))) (goto-char (point-max)) (if newval nil ;; (not newval), meaning it got set to nothing (insert "----------------- start ------------------\n") (insert (format "dpt %S op %S wh %S\n" arsen--watch-file-name-handler-alist-depth operation where)) (backtrace) (insert "----------------- end ------------------\n")))))) (add-variable-watcher 'file-name-handler-alist 'arsen--watch-file-name-handler-alist) =2D-8<---------------cut here---------------end--------------->8--- ... and various variants that I lost because they all take days or weeks to test, but to no avail (this variant isolates non un/let operations in order to catch if something is perhaps calling setq on file-name-handler-alist, but no useful results were hit anyway). Simply recording all changes to file-name-handler-alist in Lisp is too slow, of course, which is why I was thinking of hacking core to do it, and that is also why the above is so complex. Michael Albinus writes: > Could you pls just print a backtrace when epa-fle-handler isn't found? > Something like > > --8<---------------cut here---------------start------------->8--- > (message "%s" (with-output-to-string (backtrace))) > --8<---------------cut here---------------end--------------->8--- > > This would give us a backtrace to analyze. I've added this to the function now: =2D-8<---------------cut here---------------start------------->8--- (defun auth-source-pass--read-entry (entry) "Return a string with the file content of ENTRY." (with-temp-buffer (let ((fname (format "%s.gpg" entry))) (if (not (find-file-name-handler fname 'insert-file-contents)) (progn (message "%s" (with-output-to-string (backtrace))) (debug))) (insert-file-contents (expand-file-name fname auth-source-pass-filename)) (buffer-substring-no-properties (point-min) (point-max))))) =2D-8<---------------cut here---------------end--------------->8--- I am afraid it won't find useful results. I've checked the backtrace after this error happens. When it does, file-name-handler-alist is nil and the trace is akin to: =2D-8<---------------cut here---------------start------------->8--- Debugger entered: nil funcall-interactively(debug) command-execute(debug record) execute-extended-command(nil "debug" #("debug" 0 5 (ws-butler-chg chg))) funcall-interactively(execute-extended-command nil "debug" #("debug" 0 5 = (ws-butler-chg chg))) command-execute(execute-extended-command) =2D-8<---------------cut here---------------end--------------->8--- ... so it seems to me that this happens "outside" of any interesting context. I'll report back when the above fires (which, I must stress, could take days or weeks). >> I believe that the check utilized below is correct for the >> check-and-error solution. >> >> diff --git a/lisp/auth-source-pass.el b/lisp/auth-source-pass.el >> index 0f51755a250..4da15a65259 100644 >> --- a/lisp/auth-source-pass.el >> +++ b/lisp/auth-source-pass.el >> @@ -195,10 +195,13 @@ auth-source-pass--get-attr >> (defun auth-source-pass--read-entry (entry) >> "Return a string with the file content of ENTRY." >> (with-temp-buffer >> - (insert-file-contents (expand-file-name >> - (format "%s.gpg" entry) >> - auth-source-pass-filename)) >> - (buffer-substring-no-properties (point-min) (point-max)))) >> + (let ((fname (format "%s.gpg" entry))) >> + (if (not (find-file-name-handler fname 'insert-file-contents)) >> + (error "auth-source-pass requires a handler for .gpg files")) >> + (insert-file-contents (expand-file-name >> + fname >> + auth-source-pass-filename)) >> + (buffer-substring-no-properties (point-min) (point-max))))) >> >> (defun auth-source-pass-parse-entry (entry) >> "Return an alist of the data associated with ENTRY. > > Nope. find-file-name-handler shows the next file name handler to be > applied. It could be epa-file-handler, but if it is removed from > file-name-handler-alist, another file name handler could be returned, > like tramp-file-name-handler. So if you want to use > find-file-name-handler, you must check something like > > --8<---------------cut here---------------start------------->8--- > (eq (find-file-name-handler fname 'insert-file-contents) 'epa-file-handle= r) > --8<---------------cut here---------------end--------------->8--- But if we're requiring that it be specifically epa-file-handler, this seems like a more roundabout and ineffective (because it can error for seemingly no reason) way to do what I initially proposed, which was not relying on epa-file at all, and just using EPA/EPG - whichever is correct - directly (unsure if the patch is right, mind you): https://debbugs.gnu.org/cgi/bugreport.cgi?filename=3D0001-auth-source-pass-= don-t-rely-on-epa-file-bug-67937.patch;bug=3D67937;msg=3D23;att=3D1 There was concern about losing TRAMP support if the above patch is merged. This is a legitimate concern, and it can be supported (I just tried it - insert-file-contents-literally will use TRAMP but not decrypt even with epa-file enabled, so we can use (epa-decrypt-string (buffer-substring-no-properties (point-min) (point-max))) to handle that part of the work even with epa-file disabled, and insert-file-contents-literally to get file contents properly). This was argued against as the user should be able to customize how auth-source-pass opens .gpg files, but what you propose prevents that anyway. I disagree with this argument for two reasons: 1) they can already just redefine the function 2) there's no other reasonable file handler for pass entries. I'd not expect users to be able to change the address family of TCP sockets to AF_UNIX via some customizable variable either In fact, I could've done the former and completely patched out this issue by running the updated defun from the patch above. I didn't, because I suspect something else is afoot (as I mentioned initially). I'll let you know when I get that backtrace. In the meanwhile, I'd like to understand your opinion on my conclusion from the above: if epa-file-handler is the only reasonable handler for the .gpg filenames in a pass store, there's no reason to rely on the file-name handler system. I think this holds, and draw the conclusion that we should use insert-file-contents-literally and epa-decrypt-string like so: =2D-8<---------------cut here---------------start------------->8--- (defun auth-source-pass--read-entry (entry) "Return a string with the file content of ENTRY." (with-temp-buffer (let ((fname (format "%s.gpg" entry))) (insert-file-contents-literally (expand-file-name fname auth-source-pass-filename)) (let ((context (epg-make-context 'OpenPGP))) (epg-decrypt-string context (buffer-substring-no-properties (point-min) (point-max))))))) =2D-8<---------------cut here---------------end--------------->8--- (the above is untested) Thanks, have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZzyFf18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTadYA/RjToyefikfqmdoF74rMiQfxdQNBtRxbB8U9 aVuGsfN/AQDFZ+54A/IEu2p0PYpo5hQAT7VG3PPdqiI+iN875RbdBA== =ft7O -----END PGP SIGNATURE----- --=-=-=--