4 ms·

Thanks for pointing out `pass`! I've been manually merging a set of Password-Safe-format password files (one for each of my many computers) and I've been think

Thanks for pointing out `pass`! I've been manually merging a set of Password-Safe-format password files (one for each of my many computers) and I've been thinking about alternatives for a long while. I was actually thinking about how I could combine encrypted files with Git to get history and painless merging – I'm glad to know that someone else had the same ideas!

drdaeman 11y ago
Pass has one limitation - having filenames in plaintext. This could or could not be an issue for local repositories, but this is definitely an issue for remotes. Sadly, Android client (which is quite good otherwise) doesn't support git-remote-gcrypt.
- aeorgnoieang 11y ago
  > having filenames in plaintext Why is this a limitation? Are you stating that each file in the 'repo' is encrypted separately? I figured it was the entire repo as a directory, in which case, when it's 'at rest', the whole thing is encrypted as a blob.
  - drdaeman 11y ago
    > the whole thing is encrypted as a blob No, it's not. With pass (just to be sure - we're talking about zx2c4's one, right?), the store contains a bunch of independent gpg-encrypted text files. However, the filenames are not encrypted or obfuscated by any means. This has pros and cons. On the good side, you don't have to decrypt anything (which means, actually use your GPG key, which is best kept on an unplugged HSM) to just check if the credential's in the store (think auto-fill suggestion). Also, this architecture allows dead-simple (plain rsync or git!) approach for synchronization when there are no entry-level conflicts. On the bad side, anyone who has access to the filenames (local filesystem access or a clone of git repo) can figure out which resources you have credentials for. That's the price of the simplicity. I.e. what you see in the very first example at https://www.passwordstore.org/ https://www.passwordstore.org/ in the "Using the password store" section are the actual at-rest filenames. Run `ls -lR ~/.password-store` if you don't believe me ;) Use of ecryptfs/encfs or git-remote-gcrypt was suggested to mitigate this, but those aren't perfect. Well, everything depends on the threat scenarios you consider.
    - aeorgnoieang 10y ago
      Sorry if this is too late to not be annoying. What're the downsides or limitations of ecryptfs/encfs or git-remote-gcrypt – I was looking over Pass again and realized all of what you stated. I figured ecryptfs/encfs would work well enough to encrypt the Pass repo itself.

drdaeman 11y ago

Pass has one limitation - having filenames in plaintext. This could or could not be an issue for local repositories, but this is definitely an issue for remotes. Sadly, Android client (which is quite good otherwise) doesn't support git-remote-gcrypt.

aeorgnoieang 11y ago
> having filenames in plaintext Why is this a limitation? Are you stating that each file in the 'repo' is encrypted separately? I figured it was the entire repo as a directory, in which case, when it's 'at rest', the whole thing is encrypted as a blob.
- drdaeman 11y ago
  > the whole thing is encrypted as a blob No, it's not. With pass (just to be sure - we're talking about zx2c4's one, right?), the store contains a bunch of independent gpg-encrypted text files. However, the filenames are not encrypted or obfuscated by any means. This has pros and cons. On the good side, you don't have to decrypt anything (which means, actually use your GPG key, which is best kept on an unplugged HSM) to just check if the credential's in the store (think auto-fill suggestion). Also, this architecture allows dead-simple (plain rsync or git!) approach for synchronization when there are no entry-level conflicts. On the bad side, anyone who has access to the filenames (local filesystem access or a clone of git repo) can figure out which resources you have credentials for. That's the price of the simplicity. I.e. what you see in the very first example at https://www.passwordstore.org/ https://www.passwordstore.org/ in the "Using the password store" section are the actual at-rest filenames. Run `ls -lR ~/.password-store` if you don't believe me ;) Use of ecryptfs/encfs or git-remote-gcrypt was suggested to mitigate this, but those aren't perfect. Well, everything depends on the threat scenarios you consider.
  - aeorgnoieang 10y ago
    Sorry if this is too late to not be annoying. What're the downsides or limitations of ecryptfs/encfs or git-remote-gcrypt – I was looking over Pass again and realized all of what you stated. I figured ecryptfs/encfs would work well enough to encrypt the Pass repo itself.