Re: possible? less restrictive file permissions

[Sebastian Reuße]

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 restrictive permission mask may be good practice, but seems 
to be unnessecary, because the content is already protected by 
the encryption. Furthermore, it disables the use of a commonly 
shared password store.


It looks like pass applies umask of 077 by default, but you can 
set a less restrictive mask by setting PASSWORD_STORE_UMASK to a 
value of your liking. E.g., «export PASSWORD_STORE_UMASK=007» 
should give full access to your user group for newly created 
files.


However, sharing a git repository and working directory among 
multiple users might cause you some problems (which you may 
already have considered). E.g., users might interact with the 
repository without using a permissive umask (either by not setting 
PASSWORD_STORE_UMASK or by using git directly with their default 
umask) or with their primary user group set to something 
unexpected.


Kind regards,

SR

--
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: possible? less restrictive file permissions

[Sebastian Reuße]

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

--
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Security Vulnerability: Faulty GPG Signature Checking

[Sebastian Reuße]

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 passwordstore.org
> (grepping for 'sign' didn't turn up anything useful)

Perhaps it would also make sense for Jason to refer to git-remote-gcrypt
[1], which, in addition to authenticity and integrity, also provides
confidentiality for file-system level metadata (password entry names and
the directory tree) on the remote side, something that has been
discussed here in the past.

[1] 

Kind regards,
SR

-- 
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

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

[Sebastian Reuße]

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 entry? In that case, running «pass edit foo» will
fail to commit the edited file. Good catch, I think I ran into this once
or twice.

Kind regards,

-- 
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Sebastian Reuße]

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 plaintext, and there would
> be no need for pass. Maybe I misunderstood something?

When using an encrypted container, you may very well store your
passwords in plain text and achieve the same level of defense for your
(non-meta) data as offered by pass and its GnuPG backend, at least if
you opt to re-lock the container after use. In this case, any sort of
metadata encryption built into pass would not offer any substantial
advantages.

Best regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Sebastian Reuße]

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 remote git repository end-to-end
using gpg, so there’s no need to trust the hosting provider.

Regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: encrypted file and directory names?

[Sebastian Reuße]

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 100% privacy protection, since
> for example it potentially exposes which websites you use. Is that
> right, or am I missing something?

This is already implemented as far as I see it. In order to protect your
local data, you can store the git repository on a fully-encrypted disk
or alternatively store it inside an encrypted container like ecryptfs.
To protect the data stored on remotes, use the git-remote-gcrypt
extension.

Kind regards,
SR
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

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

[Sebastian Reuße]

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 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.
>
> if someone had access in the past, they had access to make a clear
> text copy of everything if they wanted to. if you worry about this,
> you need to change all passwords, and who cares if they still have
> access to outdated passwords through old revisions of the repository.
> I don't think makes much sense to rewrite history.

In the case I was thinking of, you are not removing access from another
person’s key, but from your own key that you’re using on a different
machine. You’re not expiring the data because you fear that the key was
compromised, but because your trust in some machine is reduced (maybe
you’re traveling more, or you give the spouse access to the machine, you
simply don’t need the data there anymore, etc).

git-annex will allow you to abstain from rewriting history, because the
encrypted data was managed by git-annex and never committed to git (only
as a symlink). You then drop the copies of the .gpg file from the
machine and you’re good.

>> 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.
>
> I see no reason to look inside .git/ anyway, so by all means :)

Yeah. My other motivation for using git-annex in my pass repo was
performance when storing larger blobs, anyway.

Kind regards,

--
Sebastian Reuße
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

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

[Sebastian Reuße]

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.
---
 src/password-store.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/password-store.sh b/src/password-store.sh
index 081057a..e8948a1 100755
--- a/src/password-store.sh
+++ b/src/password-store.sh
@@ -127,7 +127,7 @@ reencrypt_path() {
mv "$passfile_temp" "$passfile" || rm -f 
"$passfile_temp"
fi
prev_gpg_recipients="${GPG_RECIPIENTS[*]}"
-   done < <(find "$1" -iname '*.gpg' -print0)
+   done < <(find "$1" -path '*/.git' -prune -o -iname '*.gpg' -print0)
 }
 check_sneaky_paths() {
local path
@@ -400,7 +400,7 @@ cmd_grep() {
passfile="${passfile##*/}"
printf "\e[94m%s\e[1m%s\e[0m:\n" "$passfile_dir" "$passfile"
echo "$grepresults"
-   done < <(find -L "$PREFIX" -iname '*.gpg' -print0)
+   done < <(find -L "$PREFIX" -path '*/.git' -prune -o -iname '*.gpg' 
-print0)
 }
 
 cmd_insert() {
-- 
2.11.0

___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

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

[Sebastian Reuße]

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.
---
 src/password-store.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/password-store.sh b/src/password-store.sh
index 63be840..de4cadc 100755
--- a/src/password-store.sh
+++ b/src/password-store.sh
@@ -111,7 +111,7 @@ reencrypt_path() {
mv "$passfile_temp" "$passfile" || rm -f 
"$passfile_temp"
fi
prev_gpg_recipients="${GPG_RECIPIENTS[*]}"
-   done < <(find "$1" -iname '*.gpg' -print0)
+   done < <(find "$1" -path '*/.git' -prune -o -iname '*.gpg' -print0)
 }
 check_sneaky_paths() {
local path
@@ -352,7 +352,7 @@ cmd_grep() {
passfile="${passfile##*/}"
printf "\e[94m%s\e[1m%s\e[0m:\n" "$passfile_dir" "$passfile"
echo "$grepresults"
-   done < <(find -L "$PREFIX" -iname '*.gpg' -print0)
+   done < <(find -L "$PREFIX" -path '*/.git' -prune -o -iname '*.gpg' 
-print0)
 }
 
 cmd_insert() {
-- 
2.7.2

___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store