From nathan at nixpulvis.com Mon Nov 1 18:37:59 2021 From: nathan at nixpulvis.com (Nathan Lilienthal) Date: Mon, 1 Nov 2021 14:37:59 -0400 Subject: Pass Generate Hidden Message-ID: Is there an option (or could there be) for `pass generate ...` to not print the new password? I always like to test the decoding anyway, plus it would be more secure. - N8 From marcus.hildum at gmail.com Tue Nov 2 22:15:34 2021 From: marcus.hildum at gmail.com (Marcus Hildum) Date: Tue, 2 Nov 2021 15:15:34 -0700 Subject: [PATCH] Add ENV variable to force qrcode rendering in terminal Message-ID: I prefer to have my qrcodes rendered in the terminal and currently pass defaults to using feh, graphicsmagick, or imagemagick (in that order) to render qrcodes if they're installed. Given that many other parts of pass are customized with environment variables I figured that was a good way to force terminal rendering if the user so chose. --- man/pass.1 | 3 +++ src/password-store.sh | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/man/pass.1 b/man/pass.1 index a555dcb..8507997 100644 --- a/man/pass.1 +++ b/man/pass.1 @@ -463,6 +463,9 @@ upper-case fingerprint in this variable. If multiple fingerprints are specified, separated by a whitespace character, then signatures must match at least one. The \fBinit\fP command will keep signatures of \fB.gpg-id\fP files up to date. .TP +.I PASSWORD_FORCE_TERMINAL_QRCODE +If this environment variable is set, then qrencode will render to the terminal using utf8 +.TP .I EDITOR The location of the text editor used by \fBedit\fP. .SH SEE ALSO diff --git a/src/password-store.sh b/src/password-store.sh index aef8d72..1d54fb1 100755 --- a/src/password-store.sh +++ b/src/password-store.sh @@ -19,6 +19,7 @@ CLIP_TIME="${PASSWORD_STORE_CLIP_TIME:-45}" GENERATED_LENGTH="${PASSWORD_STORE_GENERATED_LENGTH:-25}" CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:punct:][:alnum:]}" CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}" +FORCE_TERMINAL_QRCODE="${PASSWORD_FORCE_TERMINAL_QRCODE}" unset GIT_DIR GIT_WORK_TREE GIT_NAMESPACE GIT_INDEX_FILE GIT_INDEX_VERSION GIT_OBJECT_DIRECTORY GIT_COMMON_DIR export GIT_CEILING_DIRECTORIES="$PREFIX/.." @@ -198,7 +199,7 @@ clip() { } qrcode() { - if [[ -n $DISPLAY || -n $WAYLAND_DISPLAY ]]; then + if [[ ( -n $DISPLAY || -n $WAYLAND_DISPLAY ) && -z $FORCE_TERMINAL_QRCODE ]]; then if type feh >/dev/null 2>&1; then echo -n "$1" | qrencode --size 10 -o - | feh -x --title "pass: $2" -g +200+200 - return -- 2.32.0 From minshall at umich.edu Tue Nov 2 07:47:57 2021 From: minshall at umich.edu (Greg Minshall) Date: Tue, 02 Nov 2021 10:47:57 +0300 Subject: Pass Generate Hidden In-Reply-To: References: Message-ID: <1487046.1635839277@apollo2.minshall.org> Nathan, > Is there an option (or could there be) for `pass generate ...` to not > print the new password? I always like to test the decoding anyway, > plus it would be more secure. maybe i'm misunderstanding, but i always do `pass generate -c ...`. cheers, Greg From amitsaha.in at gmail.com Sat Nov 6 23:13:46 2021 From: amitsaha.in at gmail.com (Amit Saha) Date: Sun, 7 Nov 2021 10:13:46 +1100 Subject: Linux: pass show not showing the secret Message-ID: Hi all, a fairly new user of pass. I am using a git store for my passwords. I started using MacOS and have been using it on a single computer. Now, I have set pass up on a second system (Linux), and using the 1.7.3 version on Ubuntu, when I do "pass show" one of the existing passwords, the Gpg dialog pops up, I put in the password, then there is no output. However, I can "pass insert" a new password on the same system, and then "pass show" shows the secret. I can go back to the other computer, and I can see the secret I created on the Linux system. I have used my existing gpg keys to encrypt and decrypt a file successfully. Not sure how to best debug. Any suggestions would be helpful. Thanks, Amit. From amitsaha.in at gmail.com Sat Nov 6 23:37:57 2021 From: amitsaha.in at gmail.com (Amit Saha) Date: Sun, 7 Nov 2021 10:37:57 +1100 Subject: Linux: pass show not showing the secret In-Reply-To: References: Message-ID: On Sun, Nov 7, 2021 at 10:13 AM Amit Saha wrote: > > Hi all, a fairly new user of pass. I am using a git store for my > passwords. I started using MacOS and have been using it on a single > computer. > > Now, I have set pass up on a second system (Linux), and using the > 1.7.3 version on Ubuntu, when I do "pass show" one of the existing > passwords, the Gpg dialog pops up, I put in the password, then there > is no output. However, I can "pass insert" a new password on the same > system, and then "pass show" shows the secret. > > I can go back to the other computer, and I can see the secret I > created on the Linux system. > > I have used my existing gpg keys to encrypt and decrypt a file successfully. > > > Not sure how to best debug. Any suggestions would be helpful. I tried using --clip: $ pass show --clip There is no password to put on the clipboard at line 1. So, I suppose the decryption process is not working? > > Thanks, > Amit. From lee at leeball.dev Sat Nov 6 23:50:25 2021 From: lee at leeball.dev (Lee Ball) Date: Sat, 6 Nov 2021 16:50:25 -0700 Subject: Linux: pass show not showing the secret In-Reply-To: References: Message-ID: <15b73960-9ef3-a03a-98e6-2e2b712778c9@leeball.dev> Sorry to spam you here Amit- I forgot to put the list on the To: line in case the info is helpful to anyone else: --- > Oh, I forgot to mention in my previous email-- here's a list of the > gpg-agent options: > > https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html > > And you can reload your gpg agent to pick up new configs with: > > $ gpg-connect-agent reloadagent /bye > > All the best, > Cat Lee Ball > > > On 11/6/21 4:41 PM, Lee Ball wrote: >> Hi Amit, >> >> >> To get a little more debug info, you might want to try adding debug >> flags to gpg-agent. Usually, those live in ~/.gnupg/gpg-agent.conf >> >> You could try something like: >> >> >> $ cat ~/.gnupg/gpg-agent.conf >> debug 1024 >> debug-level advanced >> debug-pinentry >> >> >> One wild guess is that maybe the pinentry prompt isn't spawning. You >> can tell it to use a specific pinentry program in your gpg-agent.conf >> too. >> >> >> $ cat ~/.gnupg/gpg-agent.conf >> pinentry-program /usr/bin/pinentry-curses >> >> >> Make sure you have pinentry-curses installed first if you copy the >> above line verbatim. :) >> >> >> Wishing you luck! >> Cat Lee Ball --- All the best, Cat Lee Ball On 11/6/21 4:37 PM, Amit Saha wrote: > On Sun, Nov 7, 2021 at 10:13 AM Amit Saha wrote: >> >> Hi all, a fairly new user of pass. I am using a git store for my >> passwords. I started using MacOS and have been using it on a single >> computer. >> >> Now, I have set pass up on a second system (Linux), and using the >> 1.7.3 version on Ubuntu, when I do "pass show" one of the existing >> passwords, the Gpg dialog pops up, I put in the password, then there >> is no output. However, I can "pass insert" a new password on the same >> system, and then "pass show" shows the secret. >> >> I can go back to the other computer, and I can see the secret I >> created on the Linux system. >> >> I have used my existing gpg keys to encrypt and decrypt a file successfully. >> >> >> Not sure how to best debug. Any suggestions would be helpful. > > I tried using --clip: > > $ pass show --clip > There is no password to put on the clipboard at line 1. > > So, I suppose the decryption process is not working? > > >> >> Thanks, >> Amit. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xF6E4A8DF1AC85DAE.asc Type: application/pgp-keys Size: 2060 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From amitsaha.in at gmail.com Sun Nov 7 00:30:34 2021 From: amitsaha.in at gmail.com (Amit Saha) Date: Sun, 7 Nov 2021 11:30:34 +1100 Subject: Linux: pass show not showing the secret In-Reply-To: <15b73960-9ef3-a03a-98e6-2e2b712778c9@leeball.dev> References: <15b73960-9ef3-a03a-98e6-2e2b712778c9@leeball.dev> Message-ID: On Sun, Nov 7, 2021 at 10:50 AM Lee Ball wrote: > > Sorry to spam you here Amit- I forgot to put the list on the To: line in > case the info is helpful to anyone else: All good, thanks for sharing the tips. This is what I have now. My Gpg agent is running via a systemd user service: [Unit] Description=GnuPG cryptographic agent and passphrase cache Documentation=man:gpg-agent(1) Requires=gpg-agent.socket [Service] ExecStart=/usr/bin/gpg-agent --supervised --debug-all ExecReload=/usr/bin/gpgconf --reload gpg-agent My config files: $ cat ~/.gnupg/gpg.conf # pinentry-mode loopback (I had to comment that out since otherwise "pass" gives this error: gpg: Sorry, we are in batchmode - can't get input) My gpg-agent.conf is now: $ cat ~/.gnupg/gpg-agent.conf debug 1024 debug-level advanced debug-pinentry pinentry-program /usr/bin/pinentry-curses log-file gpg-agent.log display :0 When I do a "pass show ", it asks me for the passphrase, if i enter the wrong pass phrase, it does come back with an error saying bad passphrase. So it seems to me that the gpg decryption is happening, but then something is getting lost. If i look at the gpg-agent.log file (after i have once successfully entered my pass phrase), i see this when i do a "pass show ": 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK Pleased to meet you, process 2671 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION ttyname=/dev/pts/1 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION ttytype=xterm-256color 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION display=:0.0 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION xauthority=/home/echorand/.Xauthority 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION lc-ctype=en_AU.UTF-8 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION lc-messages=en_AU.UTF-8 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- GETINFO version 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> D 2.2.19 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION allow-pinentry-notify 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION agent-awareness=2.1.0 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEY 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Amit+Saha+%22%0A256-bit+ECDH+key,+ID+2936DD677ED4C323,%0Acreated+2021-10-02+(main+key+ID+2A18534CA9B35D2B).%0A 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- PKDECRYPT 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> S INQUIRE_MAXLEN 4096 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> INQUIRE CIPHERTEXT 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 34 3a 65 ...(105 byte(s) skipped) ] 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- END 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> [ 44 20 28 35 3a 76 61 6c 75 65 33 33 3a 40 8b 7a ...(31 byte(s) skipped) ] 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> OK 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 <- [eof] Appreciate any further debugging tips. Thanks, Amit. > > --- > > > Oh, I forgot to mention in my previous email-- here's a list of the > > gpg-agent options: > > > > https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html > > > > And you can reload your gpg agent to pick up new configs with: > > > > $ gpg-connect-agent reloadagent /bye > > > > All the best, > > Cat Lee Ball > > > > > > On 11/6/21 4:41 PM, Lee Ball wrote: > >> Hi Amit, > >> > >> > >> To get a little more debug info, you might want to try adding debug > >> flags to gpg-agent. Usually, those live in ~/.gnupg/gpg-agent.conf > >> > >> You could try something like: > >> > >> > >> $ cat ~/.gnupg/gpg-agent.conf > >> debug 1024 > >> debug-level advanced > >> debug-pinentry > >> > >> > >> One wild guess is that maybe the pinentry prompt isn't spawning. You > >> can tell it to use a specific pinentry program in your gpg-agent.conf > >> too. > >> > >> > >> $ cat ~/.gnupg/gpg-agent.conf > >> pinentry-program /usr/bin/pinentry-curses > >> > >> > >> Make sure you have pinentry-curses installed first if you copy the > >> above line verbatim. :) > >> > >> > >> Wishing you luck! > >> Cat Lee Ball > > --- > > All the best, > Cat Lee Ball > > > On 11/6/21 4:37 PM, Amit Saha wrote: > > On Sun, Nov 7, 2021 at 10:13 AM Amit Saha wrote: > >> > >> Hi all, a fairly new user of pass. I am using a git store for my > >> passwords. I started using MacOS and have been using it on a single > >> computer. > >> > >> Now, I have set pass up on a second system (Linux), and using the > >> 1.7.3 version on Ubuntu, when I do "pass show" one of the existing > >> passwords, the Gpg dialog pops up, I put in the password, then there > >> is no output. However, I can "pass insert" a new password on the same > >> system, and then "pass show" shows the secret. > >> > >> I can go back to the other computer, and I can see the secret I > >> created on the Linux system. > >> > >> I have used my existing gpg keys to encrypt and decrypt a file successfully. > >> > >> > >> Not sure how to best debug. Any suggestions would be helpful. > > > > I tried using --clip: > > > > $ pass show --clip > > There is no password to put on the clipboard at line 1. > > > > So, I suppose the decryption process is not working? > > > > > >> > >> Thanks, > >> Amit. From david at mandelberg.org Tue Nov 9 23:56:10 2021 From: david at mandelberg.org (David Mandelberg) Date: Tue, 9 Nov 2021 18:56:10 -0500 Subject: apply PASSWORD_STORE_SIGNING_KEY to password files too? Message-ID: <43ab6607-2b06-e825-15a7-b8bd0cc95058@mandelberg.org> Hi, From the manpage, it looks like PASSWORD_STORE_SIGNING_KEY doesn't apply to the files with passwords, just .gpg-id and non-system extensions. Is that right? Would it be possible to expand it to cover the password files too? If I'm understanding the way things work now, I think an attacker with write access to the password store and read access to the *public* key(s) could replace any password file with any contents they want, and it wouldn't be detectable. Replacing just a password isn't really a big deal, because the worst it could do is lock the user out of their account. Deleting the files would have that same effect, so there's no real reason to protect against it. Where I think this becomes more of a big deal is in combination with software that parses the files. E.g., https://github.com/browserpass/browserpass-extension#organizing-password-store looks like it parses usernames from the files. So if I have a password file that contains this text, encrypted: my-random-password login: dseomn And the attacker replaces it with a file that contains the encrypted version of this text: attackers-password login: dseonm The next time I go to log in, I could pretty easily log into an account controlled by the attacker. (Assuming I don't notice the swapped letters in the username, and either don't look at the password itself or don't notice that it's a different random password of the same length.) If I had logged in to that site in order to upload sensitive data to my account, the attacker would have gotten me to upload the data to their account instead. I just started looking into using pass yesterday, so it's entirely possible I'm missing something that would prevent that attack. But if not, would it be possible to get support for signing password files on write, and verifying them on read? From david at mandelberg.org Wed Nov 10 00:07:04 2021 From: david at mandelberg.org (David Mandelberg) Date: Tue, 9 Nov 2021 19:07:04 -0500 Subject: apply PASSWORD_STORE_SIGNING_KEY to password files too? In-Reply-To: <43ab6607-2b06-e825-15a7-b8bd0cc95058@mandelberg.org> References: <43ab6607-2b06-e825-15a7-b8bd0cc95058@mandelberg.org> Message-ID: <499ef014-4b99-d4c5-1c35-9d44c8fde13e@mandelberg.org> I just thought about one more thing. Would it be possible for the signature to include the relative path too? browserpass-extension uses the relative path to determine what site the password is for, so an attacker with write access could copy good-site.example.com.gpg to attacker-controlled.example.net.gpg, then collect the password on attacker-controlled.example.net. From alexander.kjall at gmail.com Wed Nov 10 07:48:25 2021 From: alexander.kjall at gmail.com (=?UTF-8?Q?Alexander_Kj=C3=A4ll?=) Date: Wed, 10 Nov 2021 08:48:25 +0100 Subject: apply PASSWORD_STORE_SIGNING_KEY to password files too? In-Reply-To: <499ef014-4b99-d4c5-1c35-9d44c8fde13e@mandelberg.org> References: <43ab6607-2b06-e825-15a7-b8bd0cc95058@mandelberg.org> <499ef014-4b99-d4c5-1c35-9d44c8fde13e@mandelberg.org> Message-ID: I tried sending a patch to fix this vulnerability last year but I don't think it was applied, and to be honest the patch needed more work from someone better at shell scripting than me. See https://blog.hackeriet.no/filename-rename-in-pass/ for my writeup of this. Den ons 10 nov. 2021 kl 01:07 skrev David Mandelberg : > > I just thought about one more thing. Would it be possible for the > signature to include the relative path too? > > browserpass-extension uses the relative path to determine what site the > password is for, so an attacker with write access could copy > good-site.example.com.gpg to attacker-controlled.example.net.gpg, then > collect the password on attacker-controlled.example.net. From nathan at nixpulvis.com Wed Nov 10 16:17:26 2021 From: nathan at nixpulvis.com (Nathan Lilienthal) Date: Wed, 10 Nov 2021 11:17:26 -0500 Subject: Pass Generate Hidden In-Reply-To: <1487046.1635839277@apollo2.minshall.org> References: <1487046.1635839277@apollo2.minshall.org> Message-ID: Oh nice, the -c option basically does what I want, thanks for pointing that out. If I really need to hide the output without copying, I can always redirect to /dev/null. I mainly just wanted to see some confirmation without the password. There is still some value to my request for a flag to suppress the password printing however, since, call me crazy but I really do like to perform a second call to pass so that I can decrypt the new password, thus ensuring it's saved correctly and that I know the master password for its store. My ideal workflow is this: pass generate # No password shown / leaked pass -c # Master password prompt # 's password copied This way I can choose to print it or not. Anyway, thanks again. - N8 On Tue, Nov 2, 2021 at 3:48 AM Greg Minshall wrote: > > Nathan, > > > Is there an option (or could there be) for `pass generate ...` to not > > print the new password? I always like to test the decoding anyway, > > plus it would be more secure. > > maybe i'm misunderstanding, but i always do `pass generate -c ...`. > > cheers, Greg From aml at lrmb.eu Sat Nov 13 01:43:16 2021 From: aml at lrmb.eu (Adrian Larumbe) Date: Sat, 13 Nov 2021 01:43:16 +0000 Subject: pass edit leaking secrets In-Reply-To: References: Message-ID: <20211113014316.irp5hexg37r4vxuv@sobremesa> A similar thing happened to me not long ago, when I realised Emacs was saving backups for every single password file I was editing manually after creation. This of course left me horrified, and the ensuing round of investigations as to how to stop it from generating backup files for my encrypted passwords yielded no fruits at all. Not a single Google search or asking in #emacs at libera.chat taught me how to stop this from happening. I didn't want to get rid of the automatic backup feature altogether, because it's saved my life quite a few times, but there seemed to be no way to tell Emacs not to backup password files when invoked as a client through its UNIX socket, maybe by matching filenames against a regular expression. In the end I gave up completely, and because I didn't want to touch my $EDITOR only for the password manager, I came up with the following wrapper, which I put into ~/sh/pass and then adding that directory to my PATH variable: #!/usr/bin/zsh -f export EDITOR=vim /usr/bin/pass $@ This does the trick, but making sure my old password file backups were gone for good meant I had to overwrite all remaining disc space with 0's. Cheers, Adrian On 21.07.2021 13:54, Patrik Keller wrote: > Dear all, > > it's probably no news for you, but running `pass edit secret` might leak > information to persistent storage if `$EDITOR` is not configured > properly. I got hit by this after switching from vim to neovim. The > latter defaults to storing swap, undo, and backup files in the user's > home directory [0]. > > My personal thoughts on this are: > 1. Neovim should not have changed the default. > 2. `pass edit` should warn about the potential leakage. > 3. I want to set the password editor independent of `$EDITOR`. > > I could imagine the following workflow for `pass edit`: > 1. Prefer `$PASS_EDITOR` over `$EDITOR` over `vi`. > 2. If `$PASS_EDITOR` is not set print a warning about the potential > leakage and ask for confirmation. > 3. Proceed as before. > > Do you know a better solution? Maybe one that works w/o changing pass? > > Best > Patrik > > 0: https://github.com/neovim/neovim/issues/4481 From amitsaha.in at gmail.com Sun Nov 14 01:54:01 2021 From: amitsaha.in at gmail.com (Amit Saha) Date: Sun, 14 Nov 2021 12:54:01 +1100 Subject: Linux: pass show not showing the secret In-Reply-To: References: <15b73960-9ef3-a03a-98e6-2e2b712778c9@leeball.dev> Message-ID: On Sun, Nov 7, 2021 at 11:30 AM Amit Saha wrote: > > On Sun, Nov 7, 2021 at 10:50 AM Lee Ball wrote: > > > > Sorry to spam you here Amit- I forgot to put the list on the To: line in > > case the info is helpful to anyone else: > > All good, thanks for sharing the tips. This is what I have now. > > My Gpg agent is running via a systemd user service: > > [Unit] > Description=GnuPG cryptographic agent and passphrase cache > Documentation=man:gpg-agent(1) > Requires=gpg-agent.socket > > [Service] > ExecStart=/usr/bin/gpg-agent --supervised --debug-all > ExecReload=/usr/bin/gpgconf --reload gpg-agent > > > > My config files: > > $ cat ~/.gnupg/gpg.conf > # pinentry-mode loopback > > (I had to comment that out since otherwise "pass" gives this error: > gpg: Sorry, we are in batchmode - can't get input) > > > My gpg-agent.conf is now: > > $ cat ~/.gnupg/gpg-agent.conf > debug 1024 > debug-level advanced > debug-pinentry > > pinentry-program /usr/bin/pinentry-curses > log-file gpg-agent.log > display :0 > > When I do a "pass show ", it asks me for the passphrase, if > i enter the wrong pass phrase, it does come back with an error saying > bad passphrase. > So it seems to me that the gpg decryption is happening, but then > something is getting lost. > > If i look at the gpg-agent.log file (after i have once successfully > entered my pass phrase), i see this when i do a "pass show > ": > > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK Pleased to meet > you, process 2671 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION ttyname=/dev/pts/1 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION > ttytype=xterm-256color > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION display=:0.0 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION > xauthority=/home/echorand/.Xauthority > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION > putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION lc-ctype=en_AU.UTF-8 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION > lc-messages=en_AU.UTF-8 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- GETINFO version > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> D 2.2.19 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION allow-pinentry-notify > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION agent-awareness=2.1.0 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEY > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEYDESC > Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Amit+Saha+%22%0A256-bit+ECDH+key,+ID+2936DD677ED4C323,%0Acreated+2021-10-02+(main+key+ID+2A18534CA9B35D2B).%0A > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- PKDECRYPT > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> S INQUIRE_MAXLEN 4096 > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> INQUIRE CIPHERTEXT > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- [ 44 20 28 37 3a > 65 6e 63 2d 76 61 6c 28 34 3a 65 ...(105 byte(s) skipped) ] > 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- END > 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> [ 44 20 28 35 3a > 76 61 6c 75 65 33 33 3a 40 8b 7a ...(31 byte(s) skipped) ] > 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> OK > 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 <- [eof] > > Appreciate any further debugging tips. Finally managed to work around it. After a bit of experimentation, I realized that it was mainly gpg failing to decrypt a file on my Linux system (gpg version 2.2.19) which I had encrypted with gpg 2.3.3 on my Mac. So..then i thought, let me try and upgrade to gpg 2.3.3 on Linux. So, I did what anyone who had already spent too much with this would do - I installed Manjaro Linux, hoping to get the 2.3.3 in any of the AURs. Fortunately, the installed version of 2.2.29 just fixed everything. So, here's the summary: Mac: gpg 2.3.3 - where i created my initial password store (git hosted) Linux 1: gpg 2.2.19 (Didn't work) Ubuntu: gpg (GnuPG) 2.2.19 libgcrypt 1.8.5 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/echorand/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cypher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Linux 2: gpg 2.2.29 (Worked) Manjaro: gpg (GnuPG) 2.2.29 libgcrypt 1.9.4-unknown Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/echorand/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 I am glad I can continue to use pass. Best Regards, -Amit. From amitsaha.in at gmail.com Sun Nov 14 03:26:33 2021 From: amitsaha.in at gmail.com (Amit Saha) Date: Sun, 14 Nov 2021 14:26:33 +1100 Subject: Linux: pass show not showing the secret In-Reply-To: References: <15b73960-9ef3-a03a-98e6-2e2b712778c9@leeball.dev> Message-ID: <8F36A8BF-89E7-44BE-9C4F-9066FB0E9CF7@gmail.com> > On 14 Nov 2021, at 12:54 pm, Amit Saha wrote: > > On Sun, Nov 7, 2021 at 11:30 AM Amit Saha wrote: >> >> On Sun, Nov 7, 2021 at 10:50 AM Lee Ball wrote: >>> >>> Sorry to spam you here Amit- I forgot to put the list on the To: line in >>> case the info is helpful to anyone else: >> >> All good, thanks for sharing the tips. This is what I have now. >> >> My Gpg agent is running via a systemd user service: >> >> [Unit] >> Description=GnuPG cryptographic agent and passphrase cache >> Documentation=man:gpg-agent(1) >> Requires=gpg-agent.socket >> >> [Service] >> ExecStart=/usr/bin/gpg-agent --supervised --debug-all >> ExecReload=/usr/bin/gpgconf --reload gpg-agent >> >> >> >> My config files: >> >> $ cat ~/.gnupg/gpg.conf >> # pinentry-mode loopback >> >> (I had to comment that out since otherwise "pass" gives this error: >> gpg: Sorry, we are in batchmode - can't get input) >> >> >> My gpg-agent.conf is now: >> >> $ cat ~/.gnupg/gpg-agent.conf >> debug 1024 >> debug-level advanced >> debug-pinentry >> >> pinentry-program /usr/bin/pinentry-curses >> log-file gpg-agent.log >> display :0 >> >> When I do a "pass show ", it asks me for the passphrase, if >> i enter the wrong pass phrase, it does come back with an error saying >> bad passphrase. >> So it seems to me that the gpg decryption is happening, but then >> something is getting lost. >> >> If i look at the gpg-agent.log file (after i have once successfully >> entered my pass phrase), i see this when i do a "pass show >> ": >> >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK Pleased to meet >> you, process 2671 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION ttyname=/dev/pts/1 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION >> ttytype=xterm-256color >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION display=:0.0 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION >> xauthority=/home/echorand/.Xauthority >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION >> putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION lc-ctype=en_AU.UTF-8 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION >> lc-messages=en_AU.UTF-8 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- GETINFO version >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> D 2.2.19 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION allow-pinentry-notify >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- OPTION agent-awareness=2.1.0 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- HAVEKEY >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- RESET >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEY >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- SETKEYDESC >> Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Amit+Saha+%22%0A256-bit+ECDH+key,+ID+2936DD677ED4C323,%0Acreated+2021-10-02+(main+key+ID+2A18534CA9B35D2B).%0A >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- PKDECRYPT >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> S INQUIRE_MAXLEN 4096 >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 -> INQUIRE CIPHERTEXT >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- [ 44 20 28 37 3a >> 65 6e 63 2d 76 61 6c 28 34 3a 65 ...(105 byte(s) skipped) ] >> 2021-11-07 11:28:28 gpg-agent[2614] DBG: chan_10 <- END >> 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> [ 44 20 28 35 3a >> 76 61 6c 75 65 33 33 3a 40 8b 7a ...(31 byte(s) skipped) ] >> 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 -> OK >> 2021-11-07 11:28:29 gpg-agent[2614] DBG: chan_10 <- [eof] >> >> Appreciate any further debugging tips. > > Finally managed to work around it. After a bit of experimentation, I > realized that it was mainly gpg failing to decrypt a file on my Linux > system (gpg version 2.2.19) which I had encrypted with gpg 2.3.3 on my > Mac. So..then i thought, let me try and upgrade to gpg 2.3.3 on Linux. > So, I did what anyone who had already spent too much with this would > do - I installed Manjaro Linux, hoping to get the 2.3.3 in any of the > AURs. Fortunately, the installed version of 2.2.29 just fixed > everything. > > So, here's the summary: > > Mac: gpg 2.3.3 - where i created my initial password store (git hosted) > > Linux 1: gpg 2.2.19 (Didn't work) > > Ubuntu: > > gpg (GnuPG) 2.2.19 > libgcrypt 1.8.5 > Copyright (C) 2019 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/echorand/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cypher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > Linux 2: gpg 2.2.29 (Worked) > > Manjaro: > > gpg (GnuPG) 2.2.29 > libgcrypt 1.9.4-unknown > Copyright (C) 2021 Free Software Foundation, Inc. > License GNU GPL-3.0-or-later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/echorand/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > And MacOS: % gpg --version gpg (GnuPG) 2.3.3 libgcrypt 1.9.4 Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /Users/echorand/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 AEAD: EAX, OCB Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 > I am glad I can continue to use pass. > > Best Regards, > -Amit. From quoiceehoh-20180826 at yxejamir.net Mon Nov 15 08:26:55 2021 From: quoiceehoh-20180826 at yxejamir.net (Amir Yalon) Date: Mon, 15 Nov 2021 10:26:55 +0200 Subject: pass edit leaking secrets In-Reply-To: <20211113014316.irp5hexg37r4vxuv@sobremesa> References: <20211113014316.irp5hexg37r4vxuv@sobremesa> Message-ID: <4997a89b-96c2-4192-be36-373fe66f2c50@www.fastmail.com> FWIW, my setup includes: export EDITOR=~/bin/custom-editor Where ~/bin/custom-editor contains: #!/bin/sh if [ $# = 1 ] && [ -z "${1##*/pass.*/*.txt}" ]; then exec vim --cmd 'source /usr/share/doc/pass/examples/vim/redact_pass.vim' "$1" fi exec /usr/bin/editor (Change /usr/bin/editor to your preferred editor.) From alessandro at pellegrini.tk Wed Nov 24 08:37:45 2021 From: alessandro at pellegrini.tk (Alessandro Pellegrini) Date: Wed, 24 Nov 2021 09:37:45 +0100 Subject: [PATCH] Port passmenu to macOS Message-ID: <8953BE1C-389E-4F7A-B41D-8DB4F54FD49B@pellegrini.tk> Hi! I have made some changes to passmenu to allow it to run on macOS. I am contributing the changes to the attached patch. Please let me know if this is acceptable as-is by the community or if some changes should be made to the patch (which is anyhow quite simple). Best, Alessandro -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Port-passmenu-to-macOS.patch Type: application/octet-stream Size: 2282 bytes Desc: not available URL: From paul.d.erickson at gmail.com Fri Nov 26 18:33:52 2021 From: paul.d.erickson at gmail.com (Paul Erickson) Date: Fri, 26 Nov 2021 12:33:52 -0600 Subject: [PATCH] allow user to "pepper", or add to password during retrieval Message-ID: I wonder if anyone else would find this feature useful? If you're not familiar with the practice, this guy explains it well: https://youtu.be/boj9q26gadE The gist is: even though using a weak, recycled, memorized password alone is not secure, _adding_ one to a strong, generated, persisted password enhances security by mitigating the risk that the contents of the password store are exposed. He calls it double-blind password management; I have also heard the terms password splitting, secret salting, and peppering. These last two are often used in a cryptographic context, but are nonetheless applicable here, and I figured "pepper" was short and simple enough for a flag. If you add the `--pepper` or `-p` flag to `show`, then GPG pinentry will prompt you for a string/password/pepper?optionally remembering it for the session?and append it to the password being retrieved. Obviously, this cannot mitigate the risk from password-store itself, plugins, or clipboard snooping, but I like the convenience of securely caching the pepper string and copy-pasting both parts together. Not done: - browserpass integration - config option to cache one pepper for all entries rather than one per entry Cheers, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-show-allow-user-to-pepper-or-add-to-password-during-.patch Type: text/x-patch Size: 6082 bytes Desc: not available URL: