From mail at maxkapral.com Fri Feb 3 07:03:07 2023 From: mail at maxkapral.com (Maxwell Kapral) Date: Thu, 2 Feb 2023 23:03:07 -0800 Subject: Pipefail in tail when copying passwords In-Reply-To: <16974c17-6448-075a-4180-d373024ac3f1@maxkapral.com> References: <16974c17-6448-075a-4180-d373024ac3f1@maxkapral.com> Message-ID: <2f7f1464-157b-3c64-90ed-a6d5d064e11a@maxkapral.com> Hello, I noticed that when using the -c option, some passwords with certain sequences of special characters would cause a pipe fail in the tail command. Attached is a git formatted patch that has resolved the issue for me. Hopefully this might help someone else too. Maxwell Kapral -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-prevent-pipefail-with-tail-when-copying-some-passwor.patch Type: text/x-patch Size: 1031 bytes Desc: not available URL: From judd at jpilot.org Fri Feb 3 15:46:52 2023 From: judd at jpilot.org (Judd Montgomery) Date: Fri, 03 Feb 2023 15:46:52 +0000 Subject: Pipefail in tail when copying passwords In-Reply-To: <2f7f1464-157b-3c64-90ed-a6d5d064e11a@maxkapral.com> References: <16974c17-6448-075a-4180-d373024ac3f1@maxkapral.com> <2f7f1464-157b-3c64-90ed-a6d5d064e11a@maxkapral.com> Message-ID: <24080ff6-3dee-9d9e-8f3d-76f146b8688c@jpilot.org> On 2/3/23 02:03, Maxwell Kapral wrote: > Hello, > > I noticed that when using the -c option, some passwords with certain > sequences of special characters would cause a pipe fail in the tail > command. Attached is a git formatted patch that has resolved the issue > for me. Hopefully this might help someone else too. > > > Maxwell Kapral That line of code caused problems if the secret had too many lines also.? Your change may fix that.? Please see if my proposed change works for you. https://lists.zx2c4.com/pipermail/password-store/2023-January/004716.html Judd From trice at posteo.net Fri Feb 3 23:58:58 2023 From: trice at posteo.net (Tim Rice) Date: Fri, 3 Feb 2023 23:58:58 +0000 Subject: Keep commit message header short In-Reply-To: References: Message-ID: >No worries, I can look at making a patch which will do this. Thanks for the feedback. Several months later, I finally found some time to dedicate to this :) I've attached another patch which moves the information about latest keys to lower in the commit messages. ~ Tim -------------- next part -------------- diff --git i/src/password-store.sh w/src/password-store.sh index 22e818f..41d99b5 100755 --- i/src/password-store.sh +++ w/src/password-store.sh @@ -346,9 +346,10 @@ cmd_init() { else mkdir -v -p "$PREFIX/$id_path" printf "%s\n" "$@" > "$gpg_id" - local id_print="$(printf "%s, " "$@")" + local id_print="$(printf "%s\n" "$@")" echo "Password store initialized for ${id_print%, }${id_path:+ ($id_path)}" - git_add_file "$gpg_id" "Set GPG id to ${id_print%, }${id_path:+ ($id_path)}." + commit_msg=$(printf "Set GPG ids%s\n\nNewest GPG ids:\n%s\n" "${id_path:+ in $id_path}" "${id_print}") + git_add_file "$gpg_id" "$commit_msg" if [[ -n $PASSWORD_STORE_SIGNING_KEY ]]; then local signing_keys=( ) key for key in $PASSWORD_STORE_SIGNING_KEY; do @@ -362,7 +363,8 @@ cmd_init() { fi reencrypt_path "$PREFIX/$id_path" - git_add_file "$PREFIX/$id_path" "Reencrypt password store using new GPG id ${id_print%, }${id_path:+ ($id_path)}." + commit_msg=$(printf "Reencrypt password store with updated GPG ids%s\n\nRecipient GPG ids:\n%s\n" "${id_path:+ in $id_path}" "${id_print}") + git_add_file "$PREFIX/$id_path" "$commit_msg" } cmd_show() { From meator.dev at gmail.com Sun Feb 5 21:26:21 2023 From: meator.dev at gmail.com (meator) Date: Sun, 5 Feb 2023 22:26:21 +0100 Subject: Problem with piping pass Message-ID: <7f8a52c5-8193-7266-3410-5c76a9ebf59e@gmail.com> Hello. I don't know if this behavior should be considered a bug but it is kind of strange and it broke my script. When You do 'pass show -c ', it outputs 'Copied to clipboard. Will clear in 45 seconds.' and then it exits. Or so I thought. If pass'es stdout is connected to a pseudoterminal, it sure exits right away. But if stdout is a pipe, it exits after 45 seconds. > time pass -c1 test | cat Copied test to clipboard. Will clear in 45 seconds. pass -c1 test 0.05s user 0.05s system 33% cpu 0.284 total cat 0.00s user 0.00s system 0% cpu 45.328 total > time pass -c1 test Copied test to clipboard. Will clear in 45 seconds. pass -c1 test 0.03s user 0.05s system 41% cpu 0.217 total > time unbuffer pass -c1 test | cat Copied test to clipboard. Will clear in 45 seconds. unbuffer pass -c1 test 0.05s user 0.05s system 14% cpu 0.729 total cat 0.00s user 0.00s system 0% cpu 0.728 total > time pass -c1 test > /dev/null pass -c1 test > /dev/null 0.02s user 0.03s system 30% cpu 0.188 total (unbuffer is a program that pretty much behaves like cat but with pseudoterminals. I learned this trick some time ago. It's surprisingly useful.) It's interesting that the > /dev/null one is still fast. I don't know if I'm just misunderstanding pipes but the first command should have exited right away as did all other ones in my opinion. Thank You in advance, meator -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1A14CB3464CBE5BF.asc Type: application/pgp-keys Size: 3780 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From meator.dev at gmail.com Mon Feb 6 07:42:16 2023 From: meator.dev at gmail.com (meator) Date: Mon, 6 Feb 2023 08:42:16 +0100 Subject: Problem with piping pass In-Reply-To: <7f8a52c5-8193-7266-3410-5c76a9ebf59e@gmail.com> References: <7f8a52c5-8193-7266-3410-5c76a9ebf59e@gmail.com> Message-ID: <4df5f463-5d95-b57f-c2f9-7a3e63ee5a37@gmail.com> I've tried to use the unbuffer program I have mentioned before to temporarily fix this problem for me. It printed 'Copied test to clipboard. Will clear in 45 seconds.', it exited right away but it didn't actually copy anything to the clipboard. Pass has cleared it instead. What the hell is pass doing with stdout? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x1A14CB3464CBE5BF.asc Type: application/pgp-keys Size: 3780 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From mortenkjarulff at gmail.com Mon Feb 13 21:03:35 2023 From: mortenkjarulff at gmail.com (=?UTF-8?Q?Morten_Kj=C3=A6rulff?=) Date: Mon, 13 Feb 2023 22:03:35 +0100 Subject: psfs - A very simple readonly FUSE filesystem on top of pass Message-ID: Hi, I made this https://gitlab.com/mortenkjarulff/psfs - A very simple readonly FUSE filesystem on top of pass. One usecase is to "move" my ~/.netrc to pass. Yes, I could rewrite all my scripts that rely on ~/.netrc, but I can fix them all with this. I would very much like some comments. Is it too simple and silly? Has it already been done? Any comments are wellcome! The goal is get an encrypted file, not to implement all pass commands via files. /Morten -- I'm a happy dreamer I believe in love From judd at jpilot.org Tue Feb 14 02:53:31 2023 From: judd at jpilot.org (Judd Montgomery) Date: Tue, 14 Feb 2023 02:53:31 +0000 Subject: psfs - A very simple readonly FUSE filesystem on top of pass In-Reply-To: References: Message-ID: <2cf9f5ce-f073-eb72-2bd0-82ab60f89727@jpilot.org> On 2/13/23 16:03, Morten Kj?rulff wrote: > Hi, > > I made this https://gitlab.com/mortenkjarulff/psfs - A very simple > readonly FUSE filesystem on top of pass. > One usecase is to "move" my ~/.netrc to pass. Yes, I could rewrite all > my scripts that rely on ~/.netrc, but I can fix them all with this. > > I would very much like some comments. > Is it too simple and silly? > Has it already been done? > Any comments are wellcome! > > The goal is get an encrypted file, not to implement all pass commands via files. > > /Morten > -- > I'm a happy dreamer > I believe in love On xubuntu 22.04 I get this when it is mounted at ~/psfs/ ~/psfs$ echo secret > secret bash: secret: Is a directory Are my pass secrets supposed to show up there? Judd From mortenkjarulff at gmail.com Tue Feb 14 08:19:54 2023 From: mortenkjarulff at gmail.com (=?UTF-8?Q?Morten_Kj=C3=A6rulff?=) Date: Tue, 14 Feb 2023 09:19:54 +0100 Subject: psfs - A very simple readonly FUSE filesystem on top of pass In-Reply-To: <2cf9f5ce-f073-eb72-2bd0-82ab60f89727@jpilot.org> References: <2cf9f5ce-f073-eb72-2bd0-82ab60f89727@jpilot.org> Message-ID: On Tue, Feb 14, 2023 at 3:55 AM Judd Montgomery wrote: > > On 2/13/23 16:03, Morten Kj?rulff wrote: > > Hi, > > > > I made this https://gitlab.com/mortenkjarulff/psfs - A very simple > > readonly FUSE filesystem on top of pass. > > One usecase is to "move" my ~/.netrc to pass. Yes, I could rewrite all > > my scripts that rely on ~/.netrc, but I can fix them all with this. > > > > I would very much like some comments. > > Is it too simple and silly? > > Has it already been done? > > Any comments are wellcome! > > > > The goal is get an encrypted file, not to implement all pass commands via files. > > > > /Morten > > -- > > I'm a happy dreamer > > I believe in love > > On xubuntu 22.04 I get this when it is mounted at ~/psfs/ > > ~/psfs$ echo secret > secret > bash: secret: Is a directory > > Are my pass secrets supposed to show up there? > > Judd It can only show your secrets already in pass, not insert/update/list. And you have to suffix the secret name with ?show. So, if you mount at ~/psfs and you have a secret called "mysecret", show it with cat ~/psfs/mysecret?show /Morten From tobast at tobast.fr Mon Feb 20 10:53:26 2023 From: tobast at tobast.fr (=?UTF-8?Q?Th=c3=a9ophile_Bastian?=) Date: Mon, 20 Feb 2023 11:53:26 +0100 Subject: [PATCH] Passmenu: follow symlinks Message-ID: <0f183a2e-054c-4436-644f-eaf9d6109834@tobast.fr> Bash's globstar option does not follow symlinks; however, symlinks can be useful to have multiple password-store repositories behaving like a single one (eg. for shared repositories). As passmenu is based on globstar to find all the password entries, it previously failed to follow symlinks and find those passwords. --- contrib/dmenu/passmenu | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contrib/dmenu/passmenu b/contrib/dmenu/passmenu index 76d92ab..c2ab1fc 100755 --- a/contrib/dmenu/passmenu +++ b/contrib/dmenu/passmenu @@ -1,7 +1,5 @@ #!/usr/bin/env bash -shopt -s nullglob globstar - typeit=0 if [[ $1 == "--type" ]]; then typeit=1 @@ -20,7 +18,7 @@ else fi prefix=${PASSWORD_STORE_DIR-~/.password-store} -password_files=( "$prefix"/**/*.gpg ) +password_files=( $(find -L "$prefix" -name '*.gpg' | sort) ) password_files=( "${password_files[@]#"$prefix"/}" ) password_files=( "${password_files[@]%.gpg}" ) -- 2.39.2 From tobast at tobast.fr Mon Feb 20 10:59:25 2023 From: tobast at tobast.fr (=?UTF-8?Q?Th=c3=a9ophile_Bastian?=) Date: Mon, 20 Feb 2023 11:59:25 +0100 Subject: [PATCH] Passmenu: follow symlinks In-Reply-To: <0f183a2e-054c-4436-644f-eaf9d6109834@tobast.fr> References: <0f183a2e-054c-4436-644f-eaf9d6109834@tobast.fr> Message-ID: <79b00da3-9f69-c31f-f0f3-bbd0618477b1@tobast.fr> Hello, I'm afraid my email client messed up the patch's leading spaces. Here is the file produced by `git format-patch` attached. Regards, -- Th?ophile -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Passmenu-follow-symlinks.patch Type: text/x-patch Size: 1183 bytes Desc: not available URL: