From tino.calancha at gmail.com Fri Dec 1 10:07:01 2023 From: tino.calancha at gmail.com (Tino Calancha) Date: Fri, 1 Dec 2023 11:07:01 +0100 (CET) Subject: [PATCH] emacs: Fix bug in clipboard management In-Reply-To: <20231127175717.2984-1-dooleyn@gmail.com> References: <20231127175717.2984-1-dooleyn@gmail.com> Message-ID: On Mon, 27 Nov 2023, Niall Dooley wrote: > Prior to this the password/secret was cleared from the kill ring but > remained in the system clipboard after the timeout expired. This > ensures the system clipboard is cleared as well. > --- > contrib/emacs/password-store.el | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) Thank you very much for your patch, Niall! This was indeed a long-standing issue, and I'm glad you came up with a fix. I have pushed your fix. Much appreciated! Tino From dooleyn at gmail.com Mon Dec 4 18:26:39 2023 From: dooleyn at gmail.com (Niall Dooley) Date: Mon, 4 Dec 2023 19:26:39 +0100 Subject: [PATCH] emacs: Group similar expressions together In-Reply-To: <20231127143814.38520-1-dooleyn@gmail.com> References: <20231127143814.38520-1-dooleyn@gmail.com> Message-ID: Any thoughts on this? I ask as I'm working on another patch and as part of that would like to separate the code into sections (which could be navigated by outline-mode). From kfogel at red-bean.com Sun Dec 17 19:22:06 2023 From: kfogel at red-bean.com (Karl Fogel) Date: Sun, 17 Dec 2023 13:22:06 -0600 Subject: [PROPOSAL] Fallback if extension not in PASSWORD_STORE_EXTENSIONS_DIR. Message-ID: <87jzpciqht.fsf@red-bean.com> In current 'pass' [1], if the PASSWORD_STORE_EXTENSIONS_DIR environment variable is set, then pass won't look in ~/.password-store/.extensions/ for extensions at all. Is that the desired behavior? Here is the behavior that I expected instead: If the env var is set, then pass would look for EXT_NAME.bash in ${PASSWORD_STORE_EXTENSIONS_DIR} first. But if the extension is not there (or if the directory doesn't exist at all), then pass would *next* try ~/.password-store/.extensions/EXT_NAME.bash (which is what pass defaults to if PASSWORD_STORE_EXTENSIONS_DIR is unset in the first place). I'd be happy to submit a patch to implement this behavior. But first I wanted to ask if there would even be interest in such a patch. Thoughts? Best regards, -Karl [1] As of commit b5e965a838b. From kfogel at red-bean.com Sun Dec 17 22:45:52 2023 From: kfogel at red-bean.com (Karl Fogel) Date: Sun, 17 Dec 2023 16:45:52 -0600 Subject: [PROPOSAL] Fallback if extension not in PASSWORD_STORE_EXTENSIONS_DIR. In-Reply-To: <28CC2408-B927-4F01-92A3-4916D0BB696B@gmail.com> ("HacKan || =?utf-8?Q?Iv=C3=A1n=22's?= message of "Sun, 17 Dec 2023 14:56:42 -0500") References: <87jzpciqht.fsf@red-bean.com> <28CC2408-B927-4F01-92A3-4916D0BB696B@gmail.com> Message-ID: <87r0jkfnxb.fsf@red-bean.com> On 17 Dec 2023, HacKan || Iv?n wrote: >Yes, that is the desired behavior. The env replaces entirely the >defaults, they are not additive. (Quoting Iv?n's accidentally-private reply with permission.) Thanks for this information. If there is already a consensus that this is the right behavior, then so be it. However, if the behavior might be reconsidered, then I'd like to propose such a reconsideration. Many programs behave the other way: an extension can be installed in a user-specific location or in a system location or both, and the user-specific location always shadows the system location. That is, if extension X exists in the user-specific location, then X is loaded from there. Even if X also exists in the system location, it is ignored there. This makes it easy for someone to try out a newer version, or their development version, of an extension, for example. I *think* it's somewhat unusual for a program to have the "fully replace the default extension folder" behavior that 'pass' currently has. (Though this is anecdotal -- I haven't done a formal survey; I'm just relying on my own experience.) I'm not sure what the advantage(s) of the current 'pass' way are, but of course it's possible that there are advantages that I'm just not thinking of. Best regards, -Karl >On December 17, 2023 2:22:06?p.m. EST, Karl Fogel > wrote: > > In current 'pass' [1], if the PASSWORD_STORE_EXTENSIONS_DIR > environment variable is set, then pass won't look in > ~/.password-store/.extensions/ for extensions at all. > > Is that the desired behavior? > > Here is the behavior that I expected instead: > > If the env var is set, then pass would look for EXT_NAME.bash > in ${PASSWORD_STORE_EXTENSIONS_DIR} first. But if the > extension is not there (or if the directory doesn't exist at > all), then pass would *next* try > ~/.password-store/.extensions/EXT_NAME.bash (which is what > pass defaults to if PASSWORD_STORE_EXTENSIONS_DIR is unset in > the first place). > > I'd be happy to submit a patch to implement this behavior. > But first I wanted to ask if there would even be interest in > such a patch. > > Thoughts? > > Best regards, > -Karl > > [1] As of commit b5e965a838b. > From minshall at umich.edu Mon Dec 18 00:04:38 2023 From: minshall at umich.edu (Greg Minshall) Date: Sun, 17 Dec 2023 16:04:38 -0800 Subject: [PROPOSAL] Fallback if extension not in PASSWORD_STORE_EXTENSIONS_DIR. In-Reply-To: <87r0jkfnxb.fsf@red-bean.com> References: <87jzpciqht.fsf@red-bean.com> <28CC2408-B927-4F01-92A3-4916D0BB696B@gmail.com> <87r0jkfnxb.fsf@red-bean.com> Message-ID: <38436.1702857878@archlinux> Karl, > Many programs behave the other way: an extension can be installed in a > user-specific location or in a system location or both, and the > user-specific location always shadows the system location. i don't know if this was the original thinking, but i think because this is a security program, one wants to be extra careful that the user doesn't (too (*)) inadvertently turns on possibly risky features. cheers, Greg (*) there are never guarantees. From kfogel at red-bean.com Mon Dec 18 03:47:22 2023 From: kfogel at red-bean.com (Karl Fogel) Date: Sun, 17 Dec 2023 21:47:22 -0600 Subject: [PROPOSAL] Fallback if extension not in PASSWORD_STORE_EXTENSIONS_DIR. In-Reply-To: <38436.1702857878@archlinux> (Greg Minshall's message of "Sun, 17 Dec 2023 16:04:38 -0800") References: <87jzpciqht.fsf@red-bean.com> <28CC2408-B927-4F01-92A3-4916D0BB696B@gmail.com> <87r0jkfnxb.fsf@red-bean.com> <38436.1702857878@archlinux> Message-ID: <871qbkdved.fsf@red-bean.com> On 17 Dec 2023, Greg Minshall wrote: >> Many programs behave the other way: an extension can be >> installed in a >> user-specific location or in a system location or both, and the >> user-specific location always shadows the system location. > >i don't know if this was the original thinking, but i think >because this >is a security program, one wants to be extra careful that the >user >doesn't (too (*)) inadvertently turns on >possibly risky features. > >cheers, Greg > >(*) there are never guarantees. *nod* Yeah, I get the general principle. So (thinking aloud here) the idea is: If the user has set PASSWORD_STORE_EXTENSIONS_DIR, we interpret that as the user saying that it's the one and only place where they want extensions to come from. Therefore 'pass' shouldn't fall back to looking in "${PASSWORD_STORE_DIR}/.extensions" or in "${HOME}/.password-store/.extensions" to find an extension -- that could potentially be a surprising behavior, and the user might not have been careful about (for example) what old versions of extensions, or what experimental extensions, are lying around in those other directories. I can understand being cautious by default. This decision might be worth documenting in the script. Attached is a patch that does so, in case you all want it. Best regards, -Karl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Document-non-fallback-behavior-for-extensions-dir.patch URL: