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: Sun, 24 Dec 2023 11:37:55 +0100 Message-ID: <867cl3kh4p.fsf@aarsen.me> References: <8734vwq06i.fsf@aarsen.me> <83frzwhgre.fsf@gnu.org> <87jzp8of97.fsf@aarsen.me> <83bkakhe8s.fsf@gnu.org> <87msu4myau.fsf@aarsen.me> <83y1dnga7u.fsf@gnu.org> <87sf3vlqj1.fsf@aarsen.me> <871qbf4ocp.fsf@neverwas.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> 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="33422"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Damien Cassou , Eli Zaretskii , 67937@debbugs.gnu.org, "J.P." To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 24 11:53:25 2023 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 1rHM6m-0008Vr-Ie for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Dec 2023 11:53:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHM6M-00015o-Cr; Sun, 24 Dec 2023 05:52:58 -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 1rHM6K-00015X-IN for bug-gnu-emacs@gnu.org; Sun, 24 Dec 2023 05:52:56 -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 1rHM6K-00044u-A7 for bug-gnu-emacs@gnu.org; Sun, 24 Dec 2023 05:52:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rHM6P-0004Vg-Q9 for bug-gnu-emacs@gnu.org; Sun, 24 Dec 2023 05:53:01 -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: Sun, 24 Dec 2023 10:53:01 +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.170341513917280 (code B ref 67937); Sun, 24 Dec 2023 10:53:01 +0000 Original-Received: (at 67937) by debbugs.gnu.org; 24 Dec 2023 10:52:19 +0000 Original-Received: from localhost ([127.0.0.1]:51727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHM5i-0004Ue-N4 for submit@debbugs.gnu.org; Sun, 24 Dec 2023 05:52:19 -0500 Original-Received: from mout-p-102.mailbox.org ([80.241.56.152]:33780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rHM5g-0004UQ-LF for 67937@debbugs.gnu.org; Sun, 24 Dec 2023 05:52:17 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::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-102.mailbox.org (Postfix) with ESMTPS id 4SydC72574z9sbm; Sun, 24 Dec 2023 11:52:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1703415123; 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=iw7qyPG3Uw4hYup7hgoG9fgvynm99MXU8Iqk70JP20Y=; b=163uJxIW87XQNUFRLqV6dwaF5oswNA+Q2Zm5yHemGjZLKMA/VvyCVfrJkR/fOXDzxIpnhM s2yheEbQyvFMIwy0oQXDfxXSZ6xnnUrkdnErEhvt64EWgdgG4MtFPylVBY3rz0LdJWbzTu Ld6/f7X/+WEJ4DHjXUbUoyKyc2oz6MRcXdc/trROS29jQrY6X1MweQFuoFdQzKSB2Zc6fg RjFdR9U05ORcm8x4Ge0G/FnXWk3mjqUdupw9DfQUiKXHo4VKLPHz9wDEUQfF62pw/V7OM7 tD714LFOljVYCSeBk2+mek1gXHi590Z2GBCt+29DpGAIwzGWpSM1CKFh8pYDSA== In-reply-to: <87h6k8kk4l.fsf@gmx.de> X-Rspamd-Queue-Id: 4SydC72574z9sbm 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:276798 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, Michael Albinus writes: >> No. >> >> This patch/bug report addresses a real problem that exists independently >> of what triggered it in my case. > > The problem happens when epa-file-handler is removed from > file-name-handler-alist, and no other handler responsible for *.gpg > files is active. Understood. > > However, in normal use cases, nobody removes this handler. If I'm wrong, > I'd like to iunderstand those use cases. Based on observations during the last 24h I've noticed that many Emacs functions do, in fact, reset f-n-h-a to nil. I'm yet to spot the combination of calls that leaves epa-file not added back in. I know that it happens sporadically, though, and that it does not appear to be via a let-binding, following passwords failing to fetch correctly, I can't open PGP-encrypted files. The latter fact is how I initially figured to inspect auth-source-pass. > So we must document, that auth-source-pass.el depends on such a > handler. We could also add a check, that there is such a handler, and > return either nil if it is missing, or return an error. As a first step, > we could add a note in the manual, see (info "(auth) The Unix password st= ore") An error is preferable. IIRC, auth-source caches negatives too. > Just implementing an alternative doesn't sound the right way. This would > also increase maintainance burden, if something changes how *.gpg files > shall be handled. I see where you're coming from. I propose refactoring EPA to expose a function to insert encrypted file contents as if via i-f-c, but without requiring f-n-h-a as a solution to that issue. That could lead to a more consistent user experience, too. > As example, remote files won't work when tramp-file-name-handler is > removed from file-name-handler-alist. It would be a strange approach to > implement a Tramp alternative in packades depending on Tramp, just in cas= e. Correct. The difference here is that password store entries are by definition PGP-encrypted files. They are not by definition possibly remote files exposed via TRAMP. The latter working is a nicety of Emacs design. The former is crucial to interacting with the password store. >> Your gut's nearly certainly right here :-) I am still hunting for the >> cause of that issue. > > Good. > >> Regardless, what I said initially holds true ultimately: either epa-file >> should not be relied on, or a-s-p should ensure it is present. I >> gravitate towards the former, as it reduces the complexity of getting a >> password-store entry. > > I vote for the latter, because it simplifies overall maintainability. I disagree. I think that involving the f-n-h-a mechanism for handling PGP files ultimately introduces implicitly far more complexity, even if the code is slightly briefer, precisely because of this dependency. In addition, the user can't reasonably customize reading PGP files substantially without breaking the contract with the password store. This, to me, means that supporting that scenario isn't very useful, especially in a program like Emacs, where any component can be changed on the fly, leaving the user with the option of customizing more directly. Thanks, have a lovely day! =2D- Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZYgNRl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTfWUA/0DMe0T0WQYXM0U74+TbuXn9BdyJVJz5Ja1B JHCMhYYIAQDS3BL/ZqBR1HhAbpXcMTznnKXkEsn3PLJl8mo7mfcdBA== =qrLw -----END PGP SIGNATURE----- --=-=-=--