| Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Emacs backup files add a duplicate entry, that is, if you have the two files,
foo.bar and foo.bar~, then you'd get two entries for `foo'.
* password-store.el (password-store-list): Delete duplicate entries. Bump
version to 2.0.2. Update Copyright notice.
|
|
Drop nil arguments in `password-store--run` and `password-store--run-1`. This
fixes an error running `password-store-generate`.
|
|
|
|
When using EXWM, if `password-store-get` is called and a pinentry
program needs to be executed, Emacs deadlocks. This happens becuase
Emacs blocks waiting for output from `gpg(1)`, which is blocked
waiting for output from the pinentry-program, which is blocked waiting
for Emacs to manage its window.
This updates `password-store-copy` to work asynchronously. This
should be fine, since its primary purpose is side-effecting, and it
doesn’t matter when its evaluation completes. The ability to call
`password-store-get` asynchronously with a callback has also been
added to support this usecase.
A new function has been added for general cases of async `pass`
commands where the output is needed, `password-store--run-1`. While
there is an existing `password-store--run-async`, it discards output
-- it’s only used for `pass edit`, where it’s not needed. The body of
`password-store--run` has been replacing it with one that uses
`--run-1` and a wait loop which blocks until it’s complete.
Supporting all this necessitated moving the file to lexical binding
and dropping Emacs 24 support. The latter requirement could be worked
around if there are concerns around it.
**SECURITY INTERLUDE**
I was unbelievably distressed to discover that the implementation of
`password-store--run` redirects the decrypted file contents to disk,
reads that into a buffer, then removes the file. This approach is
preposterous and may warrant a CVE, as it exposes users to numerous
conditions where their cleartext passwords could be recovered:
- If the user hits C-g, the Emacs function may not get to the point
of removing the file, leaving the password on disk.
- It’s not a safe assumption that `make-temp-file` is secure, and
even if it were, the time windows in play are likely to be very
large, opening race conditions where the file contents can be read
by an attacker before the file is removed.
- Even if the file is removed, it could be recovered by examining the
contents of deleted inodes.
Information this sensitive should NEVER be persisted in cleartext in
non-volatile storage. You may as well write it on a post-it and stick
it on your monitor.
re NicolasPetton/pass#25
|
|
|
|
"http://" was repeated, fix the second instance to read "https://".
|
|
Signed-off-by: Elan Ruusamäe <glen@pld-linux.org>
|
|
Signed-off-by: Elan Ruusamäe <glen@pld-linux.org>
|
|
|
|
|
|
Instead we're forced to base64 it, like we do with the clipboard.
|
|
Bash completion now allows usage of extension commands.
(see pass.bash-completion for details)
|
|
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.
|
|
Use the autocmd pattern to match the password filename rather than doing
it manually within the called function.
|
|
|
|
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>
|
|
Per debugging from Enno Nagel <enno.nagel+vim@gmail.com>, it's become
apparent to me that to have any degree of confidence that none of these
options have actually got any plaintext password data in them, we need
to disable the options globally when a password file is edited.
In particular, in the case of the 'viminfo' global option, it's not
possible to disable it per path, and not terribly meaningful either;
things like the last seach pattern or the contents of registers, i.e.
global state of the editor, are recorded. There's no sensible approach I
can see except to actually switch the feature off entirely by blanking
it.
I've therefore completely rewritten this, to make as thorough a check as
possible that the Vim user is editing a pass(1) file by calling `pass
edit`, and then to disable the "leaky" options globally, with an
explicit warning so that the user can see it's been done.
This plugin is also available as Vim script #5707:
<https://www.vim.org/scripts/script.php?script_id=5707>
Its homepage is here:
<https://sanctum.geek.nz/cgit/vim-redact-pass.git/about/>
|
|
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).
|
|
Fish completion spends most of the time in calls to `sed` in for loops over
entries and directories. This patch removes the repeated calls to `sed`.
Signed-off-by: Mathis Antony <sveitser@gmail.com>
|
|
|
|
|
|
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.
|
|
If IFS (Input Field Separator) is not emptied, read will actually strip
spaces and tabs at the beginning/end end of the "line".
|
|
|
|
This is important for filenames with special characters such as spaces
and parenthesis.
|
|
|
|
|
|
|
|
Instead of editing the password file directly using Emacs, "pass edit" is
run. This allows password-store's git change tracking to work.
This adds a dependency on the with-editor Emacs package.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
