Is it possible to have gopass encrypt the file structure?

[Crown0815]

Is it possible to use gopass with pass-code?

I think gopass is a great tool to use git as a password storage, but I am a little on the fence about having my whole password structure, e.g., which websites I have accounts for, accessible through git.

I understand that the idea is to keep the repository itself hidden, but a difference to other password manager files is that they hide everything by default. So even if their file gets leaked it should require significant effort to extract any information from it.

The solution in pass and gopass also seems rather straight forward, encrypt the files and keep their structure in a separate file that is also encrypted. Such a solution was implemented in pass-code, a pass extension.

I wonder if such functionality is of interest for gopass as well? I would definitely prefer to have my password structure encrypted together with the actual passwords.

[kanielrkirby]

Hey there, @Crown0815. Though there are many contributors and maintainers keen on implementing something like this, there's a lot of concerns that make it not as straightforward as one would hope.

1. There's a lot of integrations built on top of Gopass that would break due to a feature like this.
2. The majority of users of Gopass utilize Git, and most encryption implementations don't play very well with Git. Even if we were to use something like Fossil SCM (still in early preview and without documentation), that's yet another thing that needs to be developed and tested.
3. The ideal future version of Gopass will likely not be using GPG as the default (see GPG Criticism), and while age has been implemented for a while now, it is still experimental.
4. Gopass is extremely focused on being cross-platform. This means that whichever back-end we use needs to provide "The same user experience on Linux, MacOS, *BSD or Windows". Bash scripts such as pass-code aren't well known for their compatibility with Windows, unfortunately, and would almost certainly expect the user to have previously set up WSL2.

There's discussions of varying length about this on #1974, #2275, #673, and most notably #1560, so if you have any input or opinions on the matter, it would be appreciated. Rest assured though, everyone wants this feature :)

[fetwar]

There's a lot of integrations built on top of Gopass that would break due to a feature like this.

Could a middleware layer for interacting with file names be added?

I haven't looked into the way that gopass extensions work, depending on whether they access the underlying files themselves directly or access via a gopass api this may allow for changes like this without breaking functionality.

---

The majority of users of Gopass utilize Git, and most encryption implementations don't play very well with Git.

If the on-disk file names are derivative from the human-readable file names instead of from the content within them, I believe git should be able to properly detect and play nicely with:

• content changes without changing the human-readable name
• renaming files without changing content

If someone uses gopass mv some-human-readable-name other-name this would be committed to VCS with it's own commit and so any content changes after that should be picked up the same as current without losing track of the file.

---

Alternate idea, locking and unlocking functionality for the password store, essentially just an encrypted tar file, similar to the pass-tomb extension, but rewritten in go for cross platform compatibility.

This would allow for securing the password store at rest on client devices, which is most likely the main point of compromise and would eliminate a large amount of the data leak issue. VCS would have to interact with the "unlocked" version of the files to function properly, so definitely not a perfect solution, but this is the most feasible that I can think of at the moment.