Jason, my apologies - that passage was me and at second look, written much more confrontatively than neccessary or sensible (I'll probably edit it as soon as I'm on a workstation). As they say, you can't argue about taste. Thanks for all your hard work, especially on pass.

Hey I dig pass and will try gopass but either way... thank you for doing what I was going to do myself, years before I tried to do it.

People like you are the reason people like me are in this business.

Fuck, I love the Internet.

First of all: Thank you for pass! We've been using it a lot internally and just because pass is so awesome, we decided to start gopass.

We use Go for almost everything at JustWatch and that's why we decided to rewrite it in Go as this would allow us to add even more features with better abstraction in the future. Bash just didn't feel like the right fit for that.

I looked at the code for pass recently, and thought it was a nice example of something where bash is absolutely adequate.

You point out (in discussing the design of pass):

> There is one slight drawback to all the simplicity, and that is an information disclosure inherent to the design: pass stores all folder and file names in clear text, so even if you fully trust GPG, you should probably not put this repo into a public place like Github, because this may expose your account names and other metadata.

What's not completely obvious from a cursory read is whether gopass improves upon that. Also, the multiple stores feature looks like it might be quite nice, but a lengthier example would be very helpful!

Edit: improve clarity

I was just thinking the same thing and was wondering if I missed that? I have been working on a similar project for keeping bookmarks and haven't found (yet) an easy way to obfuscate directory and file names in a way that doesn't make the tree structure look like a mess but still makes it difficult for the majority of people to "crack".

That's exciting, because now we get to find out how big a problem is a tool you use being in a language you don't. It might actually be a good idea if the original one is waning cause you only need to make a competitive version of any one of those tools or businesses.

Comment about pass... (looks like a great tool btw) you mention in the man page that

> Multiple gpg-ids may be specified, in order to encrypt each password with multiple ids.

That should technically reduce security, when encrypting the same secret with multiple IDs, as it gives a potential attacker more data to work with.

I suggest adding some randomness when encrypting with each key and having pass hide it from the end user when decrypting.

You're aware of an attack on RSA that weakens it when a short random string is encrypted with a handful of RSA keys as opposed to a single key?

Afaik supplying multiple ids to gpg simply re-encryps the same symmetric key for multiple recipients - the plaintext is turned into a single cipher text.

There is an attack against RSA if you encrypt very small values with a small exponent and insecure padding. GPG generates a large symmetric encryption key, and uses that to encrypt the message, uses 65537 (as is considered good practice) as its exponent, and uses a cryptographically appropriate PKCS#1v1.5 padding scheme

As far as I'm aware, there's no reduction in security by encrypting to multiple public keys (other than increased risk of compromising one of the keys).

Everyone should be free to choose how he handles his personal matters. This is one of the reasons why we wanted to keep full pass compatibility. So anyone using either pass implementation can switch at any time.

But I don't want to spend my time writing bash and sending patches by mail.