From wiktor at metacode.biz Mon Mar 1 13:28:38 2021 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 1 Mar 2021 14:28:38 +0100 Subject: Substituting gpg program in pass Message-ID: <0b5c0a89-8150-d38d-b58c-c6ed584f2a8d@metacode.biz> Hello pass folks, I'm writing a small application that encrypts and decrypts OpenPGP data using TPMs and would like to instruct pass to use it instead of the default gpg / gpg2. I see that pass already has logic to use either gpg or gpg2 if available: https://git.zx2c4.com/password-store/tree/src/password-store.sh?id=07b169ec32ad6961ed8625a0b932a663abcb01d2#n10 But I'm thinking of something like the "gpg.program" config variable [0] that git uses. It can be used to point to a different binary that has the same command line interface as GnuPG and this binary is then used for signing and verification. [0]: https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgprogram Another use case would be using other wrapper scripts in the wild such as Qubes' Split GPG [1]. [1]: https://www.qubes-os.org/doc/split-gpg/ If currently there is no way to do that but this feature sounds like something that fits pass I could contribute a patch to add it. Thank you for your time! Kind regards, Wiktor From max+passwordstore at familie-goerner.eu Mon Mar 8 20:06:07 2021 From: max+passwordstore at familie-goerner.eu (Max =?iso-8859-1?Q?G=F6rner?=) Date: Mon, 8 Mar 2021 21:06:07 +0100 Subject: How to encrypt the file names Message-ID: Dear password-store collaborators, first I want to thank you for the great password manager. I use it extensively, even in Bash aliases and enjoy its great user interface. However, one issue is nagging me since I noticed it. Its that the entire password structure is unencrypted. While the content of the files is encrypted, the file names itself are not. I strongly dislike this leakage of information. Now everyone who can access the repository can see which bank I use, which servers I maintain and some of the websites I surf. Probably the least invasive option would be to encrypt the names of the files and the folders. Unfortunately, I could not find how to get a short one-line encryption using GPG. Has someone considered this information leak and could point me to a discussion? Does someone know how to implement a one-line encryption? I would like to try out to implement that and maybe contribute the feature back to password-store. Thank you very much. Sincerely Max G?rner From nils at nilsand.re Tue Mar 9 00:21:25 2021 From: nils at nilsand.re (Nils Andre) Date: Tue, 9 Mar 2021 00:21:25 +0000 Subject: How to encrypt the file names In-Reply-To: References: Message-ID: <20210309002125.3rp3zetgzn6idqpj@nixos> Never used it, but I think what you need is pass-tomb[0]. [0]: https://github.com/roddhjav/pass-tomb On Mon, Mar 08, 2021 at 09:06:07PM +0100, Max G?rner wrote: > Dear password-store collaborators, > > first I want to thank you for the great password manager. I use it > extensively, even in Bash aliases and enjoy its great user interface. > > However, one issue is nagging me since I noticed it. Its that the entire > password structure is unencrypted. While the content of the files is > encrypted, the file names itself are not. I strongly dislike this leakage of > information. Now everyone who can access the repository can see which bank I > use, which servers I maintain and some of the websites I surf. > > Probably the least invasive option would be to encrypt the names of the files > and the folders. Unfortunately, I could not find how to get a short one-line > encryption using GPG. > > Has someone considered this information leak and could point me to a > discussion? > Does someone know how to implement a one-line encryption? I would like to try > out to implement that and maybe contribute the feature back to password-store. > > Thank you very much. > > > Sincerely > > Max G?rner From max+passwordstore at familie-goerner.eu Thu Mar 11 07:41:19 2021 From: max+passwordstore at familie-goerner.eu (Max =?iso-8859-1?Q?G=F6rner?=) Date: Thu, 11 Mar 2021 08:41:19 +0100 Subject: How to encrypt the file names In-Reply-To: <20210309002125.3rp3zetgzn6idqpj@nixos> References: <20210309002125.3rp3zetgzn6idqpj@nixos> Message-ID: Am 21-03-09 00:21:25 schrieb Nils Andre: >Never used it, but I think what you need is pass-tomb[0]. > >[0]: https://github.com/roddhjav/pass-tomb Thank you very much. This definitely looks interesting. However, at first glimpse I am not too enthusiastic. If I followed the docs correctly, you directly start with a 10MB binary blob and stick to it. I fear that this interferes with tracking changes through Git, since changes now have do be tracked using a binary diff, not on a per-file level. Thank you for that pointer. Maybe its a better compromise than what I have now. Best regards Max From frank.gruellich at gmail.com Thu Mar 11 09:32:29 2021 From: frank.gruellich at gmail.com (Frank =?iso-8859-1?Q?Gr=FCllich?=) Date: Thu, 11 Mar 2021 10:32:29 +0100 Subject: How to encrypt the file names In-Reply-To: References: Message-ID: Hi, On Mon, Mar 08, 2021 at 09:06:07PM +0100, Max G?rner wrote: > However, one issue is nagging me since I noticed it. Its that the entire > password structure is unencrypted. While the content of the files is > encrypted, the file names itself are not. I strongly dislike this leakage of > information. Now everyone who can access the repository can see which bank I > use, which servers I maintain and some of the websites I surf. When it comes to git... which repository are you exactly concerned with? If it is only the remote one but you are okay with a readable local repo (you have your local repo on encrypted storage anyways, don't you?), you can git push to an encrypted remote. I used to use git remote gcrypt (https://github.com/spwhitton/git-remote-gcrypt) for that. It encrypts the entire remote repository with GnuPG. All you see there are hashed file names with encrypted content. HTH. Kind regards, Frank. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From lists.trs-80 at isnotmyreal.name Fri Mar 12 19:20:22 2021 From: lists.trs-80 at isnotmyreal.name (TRS-80) Date: Fri, 12 Mar 2021 14:20:22 -0500 Subject: How to encrypt the file names In-Reply-To: References: <20210309002125.3rp3zetgzn6idqpj@nixos> Message-ID: <5ec8a0951993bff379b9d9f2a113296f@isnotmyreal.name> On 2021-03-11 02:41, Max G?rner wrote: > Am 21-03-09 00:21:25 schrieb Nils Andre: >> Never used it, but I think what you need is pass-tomb[0]. >> >> [0]: https://github.com/roddhjav/pass-tomb > > Thank you very much. This definitely looks interesting. > > However, at first glimpse I am not too enthusiastic. If I followed > the docs correctly, you directly start with a 10MB binary blob and > stick to it. I fear that this interferes with tracking changes > through Git, since changes now have do be tracked using a binary > diff, not on a per-file level. > > Thank you for that pointer. Maybe its a better compromise than what > I have now. > > > Best regards > > Max This tradeoff is exactly what is keeping me from using pass. I want to use it, I even subscribed to the mailing list hoping to learn something. But I keep getting stuck at this point. Cheers, TRS-80 From arden at pm.me Fri Mar 19 05:40:09 2021 From: arden at pm.me (Arden Zhan) Date: Fri, 19 Mar 2021 05:40:09 +0000 Subject: easier selection of passwords In-Reply-To: <5e52372fe60709e8f64731d6b165f2f236494544.camel@connell.tech> References: <5e52372fe60709e8f64731d6b165f2f236494544.camel@connell.tech> Message-ID: > On Sat, 2021-02-20 at 14:18 -0500, Alec Hill wrote: > > On Wed, Feb 17, 2021 at 11:39 AM Matt Connell wrote: > > > On Wed, 2021-02-17 at 11:28 -0500, Alec Hill wrote: > > > > Optimally, the shell completion would allow me to omit the directories > > > > and just the password file name to be able to then `tab` through the > > > > results and select the desired one. > > > > > > My pass tab completion does this... and as I recall I didn't do > > > anything in particular to make that happen, it just always worked that > > > way. > > > > Oh that's interesting. Are you using bash shell? I'm using zsh, and > > my completion requires me to enter the directories. > > I am using bash. I do have a package installed called app-shells/bash- > completion (Gentoo) that may be providing this functionality. Not > sure. Never used a machine that I didn't install it on :) But other > distros should offer something similar. I also can't get tab completion in bash without specifying the sub directory with neither app-shells/bash-completion nor pass's built in bash completion. For me the best alternative is to use fzf and a custom fuzzy completion [1]. This example uses code from pass's zsh completion helper [2]. _fzf_complete_pass() { _fzf_complete +m -- "$@" < <( local prefix prefix="${PASSWORD_STORE_DIR:-$HOME/.password-store}" command find -L "$prefix" \ -name "*.gpg" -type f | \ sed -e "s#${prefix}/\{0,1\}##" -e 's#\.gpg##' -e 's#\\#\\\\#' | sort ) } `pass **` to trigger the completion, search and Ctrl+J/K to select the entry. Setting up a dedicated completion key [3] makes the flow a little faster. Just saw that this same discussion happened a few years ago too [4]. [1] https://github.com/junegunn/fzf/wiki/Examples-(completion) [2] https://git.zx2c4.com/password-store/tree/src/completion/pass.zsh-completion#n127 [3] https://github.com/junegunn/fzf/wiki/Configuring-fuzzy-completion [4] https://lists.zx2c4.com/pipermail/password-store/2015-September/001745.html From mail at maciej.szmigiero.name Sat Mar 20 11:52:08 2021 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Sat, 20 Mar 2021 12:52:08 +0100 Subject: explicit GPG subkey for a subdir causes the whole subdir to be reencrypted when password is moved there Message-ID: Hi, When an explicit GPG subkey is set for a particular subdirectory pass will reencrypt every password in that subdirectory each time a password file is moved to that subdirectory. Example: $ gpg -K --with-subkey-fingerprint -------------------- sec rsa3072 2021-03-20 [SC] [expires: 2023-03-20] 516D78BC5D57C26F9CE377F5B95E1094B5C79F48 uid [ultimate] Testkey ssb rsa3072 2021-03-20 [E] [expires: 2023-03-20] 703A13EF8D0F5F4991703CE0F1C59A5C51C33BC0 ssb rsa3072 2021-03-20 [E] [expires: 2023-03-20] BE9F1A1A9DFC99381EA1B408E99DED808FC9DABC There are two encryption subkeys for this PGP key, BE9F1A1A9DFC99381EA1B408E99DED808FC9DABC is younger so gpg will use it by default, but 703A13EF8D0F5F4991703CE0F1C59A5C51C33BC0 can be used, too, if it is explicitly selected. $ pass init 516D78BC5D57C26F9CE377F5B95E1094B5C79F48 Password store initialized for 516D78BC5D57C26F9CE377F5B95E1094B5C79F48 $ pass init -p Subdir '703A13EF8D0F5F4991703CE0F1C59A5C51C33BC0!' Password store initialized for 703A13EF8D0F5F4991703CE0F1C59A5C51C33BC0! (Subdir) Now the password store contains two directories: root set to the default encryption subkey of key 516D78BC5D57C26F9CE377F5B95E1094B5C79F48, that is, subkey E99DED808FC9DABC, and subdirectory "Subdir" explicitly set to the encryption subkey 703A13EF8D0F5F4991703CE0F1C59A5C51C33BC0 (or shorter: F1C59A5C51C33BC0). $ pass add Subdir/Test1 Enter password for Subdir/Test1: Retype password for Subdir/Test1: $ pass add Subdir/Test2 Enter password for Subdir/Test2: Retype password for Subdir/Test2: $ pass add MainDirPass Enter password for MainDirPass: Retype password for MainDirPass: So far so good. Now let's try to move MainDirPass password file to Subdir: $ pass mv MainDirPass Subdir/ renamed '/tmp/pass/MainDirPass.gpg' -> '/tmp/pass/Subdir/MainDirPass.gpg' Subdir/Test1: reencrypting to E99DED808FC9DABC F1C59A5C51C33BC0 Subdir/Test2: reencrypting to E99DED808FC9DABC F1C59A5C51C33BC0 Subdir/MainDirPass: reencrypting to E99DED808FC9DABC F1C59A5C51C33BC0 One can see that the existing password files in "Subdir" are being reencrypted, too, and, for some reason, using both E99DED808FC9DABC and F1C59A5C51C33BC0 encryption keys even though only F1C59A5C51C33BC0 is actually set for that subdirectory. Thankfully, the actual gpg command line is correct in this case and the password files are actually reencrypted only to key F1C59A5C51C33BC0 and not both of the keys. But still, these existing password files should not be getting reencrypted at all as they are using the right key already. It is worth noting that this behavior does not happen if a subdirectory uses a different PGP key (rather than just a different subkey). The above reencryption will happen every time a password file is moved to such subdirectory, making the moving process O(n^2). Thanks, Maciej From dacoda.strack at gmail.com Sat Mar 20 23:56:12 2021 From: dacoda.strack at gmail.com (Dacoda Strack) Date: Sat, 20 Mar 2021 16:56:12 -0700 Subject: Bash completion breaks with single-quote Message-ID: I am curious if anyone else has had issues with single-quotes in filenames. For example, consider the following directory: ``` # tree ~/.password-store/Quote\ Example/ /home/dacoda/.password-store/Quote Example/ ??? Alice's ??? ??? Very Secret.gpg ??? Mine ??? Very Secret.gpg 2 directories, 2 files ``` When I attempt to autocomplete `pass -c Quote\ Example/Mi`, it works brilliantly and completes me all the way down to: `Quote\ Example/Mine/Very\ Secret` On the other hand, with Alice, attempting to autocomplete similarly with `pass -c Quote\ Example/Alice\'s/` fails out. I noticed that passing this `-o default` option to compgen helps me here, though I am unsure of other ramifications. Please see below an excerpt from the bash man page, and a thread from the bash mailing list regarding other people's reckoning of the issue. Has this issue already been discussed in the mailing lists? Any comments or insight would be greatly appreciated. Thank you for the excellent tool. ``` -o comp-option The comp-option controls several aspects of the compspec's behavior beyond the simple generation of completions. comp-option may be one of: ... default Use readline's default filename completion if the compspec generates no matches. ``` https://lists.gnu.org/archive/html/bug-bash/2011-10/msg00059.html -- >8 -- Subject: [PATCH] pass '-o default' to compgen to properly handle single-quotes --- src/completion/pass.bash-completion | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/completion/pass.bash-completion b/src/completion/pass.bash-completion index 95d3e1e..4e921cf 100644 --- a/src/completion/pass.bash-completion +++ b/src/completion/pass.bash-completion @@ -11,7 +11,7 @@ _pass_complete_entries () { local autoexpand=${1:-0} local IFS=$'\n' - local items=($(compgen -f $prefix$cur)) + local items=($(compgen -o default -f $prefix$cur)) # Remember the value of the first item, to see if it is a directory. If # it is a directory, then don't add a space to the completion -- 2.29.2 From rm at wyz.biz Thu Mar 25 13:59:43 2021 From: rm at wyz.biz (Roderik Muit) Date: Thu, 25 Mar 2021 14:59:43 +0100 Subject: Fix bash completion with colons Message-ID: <2638c25696ab8d863bc93c795d9d84db@localhost> I started using zsh yesterday, and my command completion broke. It happens at least with filenames containing colons. The details of the breakage are: "the completion suggestions are all weird so they are useless". (I haven't looked at further details.) The completion command contains a $@, and I my first guess was maybe trying to quote it would help. Lo and behold, it did! So I stopped trying to understand much about zsh completion after that. Here's the patch that worked for me. -------------- next part -------------- diff --git a/src/completion/pass.zsh-completion b/src/completion/pass.zsh-completion index 27ce15a..cc8c39f 100644 --- a/src/completion/pass.zsh-completion +++ b/src/completion/pass.zsh-completion @@ -124,7 +124,7 @@ _pass_complete_entries_helper () { local IFS=$'\n' local prefix zstyle -s ":completion:${curcontext}:" prefix prefix || prefix="${PASSWORD_STORE_DIR:-$HOME/.password-store}" - _values -C 'passwords' ${$(find -L "$prefix" \( -name .git -o -name .gpg-id \) -prune -o $@ -print 2>/dev/null | sed -e "s#${prefix}/\{0,1\}##" -e 's#\.gpg##' -e 's#\\#\\\\#' | sort):-""} + _values -C 'passwords' ${$(find -L "$prefix" \( -name .git -o -name .gpg-id \) -prune -o "$@" -print 2>/dev/null | sed -e "s#${prefix}/\{0,1\}##" -e 's#\.gpg##' -e 's#\\#\\\\#' | sort):-""} } _pass_complete_entries_with_subdirs () { From fleskywood at gmail.com Thu Mar 25 18:15:56 2021 From: fleskywood at gmail.com (asdfasdfasdfasdf) Date: Thu, 25 Mar 2021 13:15:56 -0500 Subject: [PATCH] Adds tree -d to cmd_show(){} Message-ID: >From 2208fda74260d7d07e38c51b58087bf7cff7a532 Mon Sep 17 00:00:00 2001 From: Beethoven Date: Mon, 22 Mar 2021 16:33:52 -0500 Subject: [PATCH] Adds tree -d to cmd_show(){} tree is used, so tree -d should follow suit. this patch adds a -d argument to cmd_show() to show only your folders. might try and add regular ls support later if that's a thing i can do, so that large amounts of folders take up less lines on a terminal --- src/password-store.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/password-store.sh b/src/password-store.sh index 77f3eda..4fe79f1 100755 --- a/src/password-store.sh +++ b/src/password-store.sh @@ -365,12 +365,13 @@ cmd_init() { cmd_show() { local opts selected_line clip=0 qrcode=0 - opts="$($GETOPT -o q::c:: -l qrcode::,clip:: -n "$PROGRAM" -- "$@")" + opts="$($GETOPT -o q::c::d:: -l qrcode::,clip:: -n "$PROGRAM" -- "$@")" local err=$? eval set -- "$opts" while true; do case $1 in -q|--qrcode) qrcode=1; selected_line="${2:-1}"; shift 2 ;; -c|--clip) clip=1; selected_line="${2:-1}"; shift 2 ;; + -d|--dir) dir=1; selected_line="${2:-1}"; shift 2 ;; --) shift; break ;; esac done @@ -400,6 +401,7 @@ cmd_show() { else echo "${path%\/}" fi + [[ $dir -eq 1 ]] && tree -C -l -d --noreport "$PREFIX/$path" | tail -n +2 | sed -E 's/\.gpg(\x1B\[[0-9]+m)?( ->|$)/\1\2/g' && exit # use -d to tree -d your password store tree -C -l --noreport "$PREFIX/$path" | tail -n +2 | sed -E 's/\.gpg(\x1B\[[0-9]+m)?( ->|$)/\1\2/g' # remove .gpg at end of line, but keep colors elif [[ -z $path ]]; then die "Error: password store is empty. Try \"pass init\"." -- 2.31.0 From minshall at acm.org Fri Mar 26 06:35:25 2021 From: minshall at acm.org (Greg Minshall) Date: Fri, 26 Mar 2021 09:35:25 +0300 Subject: option for no highlighting on output In-Reply-To: Your message of "Tue, 24 Sep 2019 06:09:22 +0300." <82938.1569294562@apollo2.minshall.org> Message-ID: <1138837.1616740525@apollo2.minshall.org> hi. i wonder if i could put in a renewed plug for my own request from a while back? it would be great (for me, anyway) to see this in the main code base. cheers, and thanks for all those secrets, Greg ---- From: Greg Minshall To: password-store at lists.zx2c4.com Subject: option for no highlighting on output Date: Tue, 24 Sep 2019 06:09:22 +0300 hi. i wanted to edit those of my files that matched a certain pattern, and tried: ---- for i in $(pass grep -iw user | grep ':$' | sed s/://); do pass tailedit $i; done ---- but, i got files with names like: ---- tfxPMA-^[[94mbank-hsbc-^[[1mhesab.txt ---- where the characters preceding the initial dash ('-') are to be expected, but the escape sequences ('^[[m' [*]) are pass generating highlighting for display on the terminal. similar to a patch from a few months ago (4 Jun 2019) by Gonzalo Matheu i modified pass to optionally disable such escape sequences. i use the non-null existence of an environmental variable PASSWORD_STORE_NOHIGHLIGHT to activate this behavior. i also unconditionally (laziness?) take the "--color=always" argument off the grep command line, replacing it with ${GREPOPTIONS}. a patch follows. i would, of course, love to see it added to the base package. cheers, Greg ---- [*] here is a sequence of digits, like '94', '1', '0'; note: i've manually substituted the character string '^[' for the actual escapes in the file names ---- --- src/password-store.sh | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/password-store.sh b/src/password-store.sh index 284eabf..b3b5e8b 100755 --- a/src/password-store.sh +++ b/src/password-store.sh @@ -143,6 +143,12 @@ check_sneaky_paths() { done } +high() { # highlight (or not) + if [[ -z ${PASSWORD_STORE_NOHIGHLIGHT} ]]; then + printf "\e[%dm" $* + fi +} + # # END helper functions # @@ -418,14 +424,14 @@ cmd_grep() { [[ $# -lt 1 ]] && die "Usage: $PROGRAM $COMMAND [GREPOPTIONS] search-string" local passfile grepresults while read -r -d "" passfile; do - grepresults="$($GPG -d "${GPG_OPTS[@]}" "$passfile" | grep --color=always "$@")" + grepresults="$($GPG -d "${GPG_OPTS[@]}" "$passfile" | grep ${GREPOPTIONS} "$@")" [[ $? -ne 0 ]] && continue passfile="${passfile%.gpg}" passfile="${passfile#$PREFIX/}" local passfile_dir="${passfile%/*}/" [[ $passfile_dir == "${passfile}/" ]] && passfile_dir="" passfile="${passfile##*/}" - printf "\e[94m%s\e[1m%s\e[0m:\n" "$passfile_dir" "$passfile" + printf "%s%s%s%s%s:\n" "$(high 94)" "$passfile_dir" "$(high 1)" "$passfile" "$(high 0)" echo "$grepresults" done < <(find -L "$PREFIX" -path '*/.git' -prune -o -iname '*.gpg' -print0) } @@ -555,7 +561,7 @@ cmd_generate() { elif [[ $qrcode -eq 1 ]]; then qrcode "$pass" "$path" else - printf "\e[1mThe generated password for \e[4m%s\e[24m is:\e[0m\n\e[1m\e[93m%s\e[0m\n" "$path" "$pass" + printf "%sThe generated password for %s%s%s is:%s\n%s%s%s%s\n" "$(high 1)" "$(high 4)" "$path" "$(high 24)" "$(high 0)" "$(high 1)" "$(high 93)" "$pass" "$(high 0)" fi } -- 2.23.0 From minshall at acm.org Fri Mar 26 18:28:37 2021 From: minshall at acm.org (Greg Minshall) Date: Fri, 26 Mar 2021 21:28:37 +0300 Subject: option for no highlighting on output In-Reply-To: Your message of "Fri, 26 Mar 2021 06:44:36 -0700." <7CB8C32A-A362-44A8-9F0C-CB40F2152F06@gmail.com> Message-ID: <1194018.1616783317@apollo2.minshall.org> Oliver, > I like the env var but wouldn?t it also be good to detect if pass is > being piped or outputting to the terminal? That would be a good > default behavior, which you could override with env variable. that would be great. cheers, Greg From minshall at umich.edu Sun Mar 28 14:16:56 2021 From: minshall at umich.edu (Greg Minshall) Date: Sun, 28 Mar 2021 17:16:56 +0300 Subject: option for no highlighting on output In-Reply-To: Your message of "Fri, 26 Mar 2021 21:28:37 +0300." <1194018.1616783317@apollo2.minshall.org> Message-ID: <138699.1616941016@apollo2.minshall.org> Oliver, > that would be great. (sorry, i should have said this initially.) if this would be of interest to add to the source, i'd be happy to produce a candidate patch. cheers, Greg