Support for pass-code

[ghomasHudson]

Is your feature request related to a problem? Please describe.
There are definitely cases where it's important to keep even the fact that you have a password for a particular site secret. In normal pass this cannot be hidden.

Describe the solution you'd like
I saw the issue raised #329 about the difficulties implementing pass-tomb, and thought pass-code might be a simpler alternative without adding any extra encryption layers, packages etc.

pass-code is identical to normal pass but the filename for each entry is random, and a .passcode.gpg file contains the mapping between the real site name and this random string. It's deliberately designed to be 99% identical to normal pass (and passes all but 2 of the pass tests).

It would easily be compatible with existing pass repos - if an entry is not in .passcode.gpg, it's assumed to have a plaintext site name. If there's no .passcode.gpg you don't even do anything.

Describe alternatives you've considered
pass-tomb has been previously considered and rejected due to the complexity.

[msfjarvis]

This is going to make the app prohibitively slow to launch, because it'll need to do a full decryption cycle for the .passcode file before it can populate the password list. It makes file names a useless concept, which complicates a lot of things like Autofill. It'll also make search either completely useless, or extremely slow, neither of which options I'm comfortable with even if the user willingly wants that experience.

Sorry, pass-code is not going to be implemented.

[ghomasHudson]

This is going to make the app prohibitively slow to launch, because it'll need to do a full decryption cycle for the .passcode file before it can populate the password list. It makes file names a useless concept, which complicates a lot of things like Autofill. It'll also make search either completely useless, or extremely slow, neither of which options I'm comfortable with even if the user willingly wants that experience.

Sorry, pass-code is not going to be implemented.

Thanks for your response @msfjarvis - Fair enough. I didn't know decrypting a single gpg encrypted file was so prohibitively slow on launch. If that's true, then of course the other problems you identify are certainly dealbreakers. I assume creating some cached version of the mapping is not acceptable either.

I really hope that one day we find a solution to this. It's a real problem that genuinely needs solving, and is a shame there doesn't seem to be any approach that works from a speed/android library perspective.

[msfjarvis]

This is going to make the app prohibitively slow to launch, because it'll need to do a full decryption cycle for the .passcode file before it can populate the password list. It makes file names a useless concept, which complicates a lot of things like Autofill. It'll also make search either completely useless, or extremely slow, neither of which options I'm comfortable with even if the user willingly wants that experience.
Sorry, pass-code is not going to be implemented.

I didn't know decrypting a single gpg encrypted file was so prohibitively slow on launch.

It's a direct result of relying on OpenKeychain where inter-process communication (IPC) is required for a successful decryption, adding significant overhead, on top of which there is throttling from the Android framework on how many IPC calls can be made by an app. You can notice this with just Autofill, where some fill-in operations will seemingly just hang for an extra second or two every so often.

[...] I assume creating some cached version of the mapping is not acceptable either.

It'd solve some problems, but having an externally maintained copy of the mapping file means that we no longer work with the actual source of truth, which makes a lot of the application logic harder to reason about.

I really hope that one day we find a solution to this. It's a real problem that genuinely needs solving, and is a shame there doesn't seem to be any approach that works from a speed/android library perspective.

Indeed, these are all problems that I want to tackle on a longer timeframe, but for now my goal is improving the core architecture. I had hoped that our migration to gopenpgp (#1441) would net us some performance benefits but that hasn't been the case from my personal observation. It however does crucially fix a major bottleneck: there's no IPC involved, so operations cannot be throttled. This unlocks the ability to do batch operations akin to pass init which re-encrypts the entire store to a new PGP key. All in due time though :)

[ghomasHudson]

This is going to make the app prohibitively slow to launch, because it'll need to do a full decryption cycle for the .passcode file before it can populate the password list. It makes file names a useless concept, which complicates a lot of things like Autofill. It'll also make search either completely useless, or extremely slow, neither of which options I'm comfortable with even if the user willingly wants that experience.
Sorry, pass-code is not going to be implemented.

I didn't know decrypting a single gpg encrypted file was so prohibitively slow on launch.

It's a direct result of relying on OpenKeychain where inter-process communication (IPC) is required for a successful decryption, adding significant overhead, on top of which there is throttling from the Android framework on how many IPC calls can be made by an app. You can notice this with just Autofill, where some fill-in operations will seemingly just hang for an extra second or two every so often.

[...] I assume creating some cached version of the mapping is not acceptable either.

It'd solve some problems, but having an externally maintained copy of the mapping file means that we no longer work with the actual source of truth, which makes a lot of the application logic harder to reason about.

I really hope that one day we find a solution to this. It's a real problem that genuinely needs solving, and is a shame there doesn't seem to be any approach that works from a speed/android library perspective.

Indeed, these are all problems that I want to tackle on a longer timeframe, but for now my goal is improving the core architecture. I had hoped that our migration to gopenpgp (#1441) would net us some performance benefits but that hasn't been the case from my personal observation. It however does crucially fix a major bottleneck: there's no IPC involved, so operations cannot be throttled. This unlocks the ability to do batch operations akin to pass init which re-encrypts the entire store to a new PGP key. All in due time though :)

Thanks for your detailed response @msfjarvis - that makes perfect sense. I've sent a few bucks your way to help the project.