Re: possible? less restrictive file permissions

Raulo Olapodrido writes: and have all users directly work in that directory, git aside. This currently is not possible, because new files (for example generated via "pass insert") are getting a file permission mask of 0600, and no other user than its creator can read its contents. The

Re: possible? less restrictive file permissions

William Morris writes: I'd like to see an automatic `push` config or command option in `pass`. The most straightforward way to achieve this would be to install a post-commit hook to fetch, merge/rebase and then push after a commit, or am I missing something? Kind regards, SR --

Re: Security Vulnerability: Faulty GPG Signature Checking

Tobias Girstmair writes: > On Thu, Jun 14, 2018 at 05:09:35PM +0200, Jason A. Donenfeld wrote: >> Our recommendations for authenticity and integrity continue to be to >> enable git commit signing, which pass has built-in support for. > Maybe this should be mentioned/explained on

Re: [PATCH] Follow symlinks when adding changes to git

Hello Lars, Lars Flitter writes: > + git -C "$INNER_GIT_DIR" add "$(readlink -f "$1")" || return Since the patch doesn’t explicitly mention the motivation: I suppose this is meant to cover the case where you are using a symlink as an alias to another pass

Re: encrypted file and directory names?

Adam Spiers writes: > I got the impression that the point of pass was to provide an > additional line of defence above what the filesystem already provides. > If the filesystem can be trusted to keep things secure then you could > simply store all your credentials in it in

Re: encrypted file and directory names?

Marin Usalj writes: > There's still syncing those passwords over the wire and across > different filesystems. I don't fully trust cloud VPS fs encryption > either. In that case you may want to consider the git-remote-gcrypt extension. This will allow you to encrypt the

Re: encrypted file and directory names?

Adam Spiers writes: > There is one feature which I consider pretty essential, and as far as > I can see, it's not supported by pass yet, which is to keep the entire > metadata encrypted, including the directory names and file names. > Without this it doesn't seem to provide

Re: [PATCH] Don’t reencrypt data not managed by pass.

Kjetil Torgrim Homme <kjetil.ho...@redpill-linpro.com> writes: > Den 25. jan. 2017 09:14, Sebastian Reuße skreiv: >> 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 t

[PATCH] Don’t reencrypt data not managed by pass.

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

[pass] [PATCH] Don’t reencrypt data not managed by pass.

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