| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In MacOS Catalina, pass fails on accents with 'sed: RE error: illegal
byte sequence'.
|
|
I use a pass-specific gpg home directory. I tell pass about it by using
PASSWORD_STORE_GPG_OPTS="--homedir dir".
I also tell pass to sign files with PASSWORD_STORE_SIGNING_KEY.
However "pass init" returns "Signing of .gpg_id unsuccessful." because
we forgot to hand it GPG_OPTS. This patch fixes that oversight.
|
|
|
|
This patch makes sure that variables from the environment cannot
override e.g. the Git directory to operate on, as well as other critical
parts of Git operations. These variables are:
- GIT_DIR
- GIT_WORK_TREE
- GIT_NAMESPACE
- GIT_INDEX_FILE
- GIT_INDEX_VERSION
- GIT_OBJECT_DIRECTORY
- GIT_COMMON_DIR
If any of those are set, pass might end up operating on another
repository, and things would break.
I caught this having GIT_DIR set, but fortunately the other repository
had a .gitignore that would have ignored the file:
```
fishbowl~% echo $GIT_DIR
/home/madduck/.config/vcsh/repo.d/zsh.git
fishbowl~% pass generate test
The following paths are ignored by one of your .gitignore files:
.password-store/test.gpg
Use -f if you really want to add them.
The generated password for test is:
…
```
The result was an orphan file `test.gpg` in the password-store root.
Signed-off-by: Martin F. Krafft <madduck@madduck.net>
|
|
Some implementations of tr (notably the ones in Busybox and Toybox) do
not support the [:graph:] character class, but they do support
[:punct:] and [:alnum:]. This makes pass generate sane passwords
in such environments.
Discussed-on: https://lists.zx2c4.com/pipermail/password-store/2019-July/003702.html
|
|
When rotating encryption subkeys, and revoking the old one,
`pass init keyid` would re-encrypt your stored credentials to the
(now revoked) old subkey(s) in addition to the new one too.
It would also mistakenly encrypt to keys that have been disabled,
and keys that were never validly signed by their master (certify) key.
Fix all of these cases. It was decided NOT to also exclude expired
subkeys.
Signed-off-by: Aaron Jones <aaronmdjones@gmail.com>
|
|
|
|
|
|
|
|
Instead we're forced to base64 it, like we do with the clipboard.
|
|
Since commit 63ef32a (generate: use nice ansi colors instead.,
2014-05-08), generated passwords are highlighted to make them
distinguishable from the Git output.
However, setting the foreground color to white makes the password hardly
readable when a "black on white" color scheme is used. Drop the
hardcoded foreground color and use the bold attribute only instead.
Signed-off-by: Lukas Fleischer <lfleischer@lfos.de>
|
|
Bash sometimes writes these into temporary files, which isn't okay.
|
|
|
|
For the line-choosing case, this is actually a big deal since we weren't
passing the error code back to the user either.
|
|
While we do not expect any output on stdout from the background task,
keeping the file handle open means that anyone calling `pass` and
waiting for stdout to be closed, will have to wait (by default) for 45
seconds.
|
|
Some EDITORs, notably Linux vi(1), which is the fallback default in pass,
apparently send INT when they exit, and when pass is run under bash
(which is also its default)--if you have /dev/shm/ available--bash catches
this and cleans up your edited password file *before* it can be reencrypted
and saved.
This only happens with `pass edit`; none of the other commands combine
tmpdir and $EDITOR.
|
|
|
|
Fixes CVE-2018-12356.
Reported-by: Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de>
|
|
Allow grep options and arguments. Typical uses may be, for instance,
wanting to ignore case ('-i'), print a few lines of context around the
matched line, multiple patterns with '-e', etc.
(background: grep is deprecating GREP_OPTIONS, so eventually that will
stop working).
|
|
|
|
|
|
Otherwise this expands to a filename if one exists.
Suggested-by: izaberina@gmail.com
|
|
With the $path variable being passed directly to dirname, any pass-names
provided by the user that happened to look like options to dirname would
be processed as options rather than as the path to be split.
This results in a real mess when you happen to run one of:
pass edit --help
pass generate --help
pass insert --help
then in the cmd_foo() function, you have:
mkdir -p -v "$PREFIX/$(dirname --help)"
which (due to the -p option to mkdir) results in the creation of an
entire directory hierarchy made up of the slash-separated help text from
dirname.
|
|
|
|
|
|
|
|
GnuPG 2.2.19 added a warning when no command was given.
* src/password-store.sh (reencrypt_path): Add --decrypt to --list-only
* tests/t0300-reencryption.sh (gpg_keys_from_encrypted_file): same
https://bugs.gnupg.org/gnupg/msg9873
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=810adfd47801fc01e45fb71af9f05c91f7890cdb
https://bugzilla.suse.com/show_bug.cgi?id=1028867
|
|
|
|
|
|
|
|
|
|
|
|
Git worktree works with the normal .git directory instead being a
.git file with a reference to the primary git repository.
|
|
When keeping the password-store under git, it can make sense using a git
extension such as git-annex instead of the native git object store to
store the encrypted files. Inter alia, this allows one to selectively
expire old copies of the encrypted data, while otherwise, one would need
to recreate the complete repository when a key should no longer have
access to some of the data.
Since using the git-annex object store means that *.gpg files (and
directories named *.gpg) are kept under .git/… (non-writable), the
reencryption logic used by pass currently fails. To remedy this, we now
ignore everything kept under .git when looking for files to reencrypt or
when grepping.
|
|
|
|
|
|
|
|
|
|
|
|
Passing to tr using the "pick and discard" technique is more straight-
forwardly correct and less error-prone. It also allows users to
select their own character sets to be passed to tr.
|
|
|
|
This reverts commit fcb92ed69fc191e39379bad715371d8c28410885.
Needs more discussion.
|
|
|
|
|
|
|
|
|
|
Folks are lazy and don't want to type very much, so they'd like to have
a default password length to generate that can be configured via
environment variables per usual. I'm making the default 25.
If the user forbids the use of symbols, pwgen will use a-zA-Z0-9,
ensuring that at least one A-Z and at least one 0-9 is used. We want to
have a password of at least 128-bits, so factoring in the issue with "at
least one of this character type", 25 gets us there squarely.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
|
|
|