8 ms·

> Second, with all due respect to the original author zx2c4 (who is currently working on the very promising WireGuard project) Indeed I am working on WireGuard

by zx2c4 10y ago

> Second, with all due respect to the original author zx2c4 (who is currently working on the very promising WireGuard project) Indeed I am working on WireGuard. But I haven't forgotten pass. We're currently working on a new release. > the project proved to be a wild bunch of hotwired bash scripts that mostly looked like they were written as a one-off job I very much disagree with this silliness.

MetalMatze 10y ago
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.
- benologist 10y ago
  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.
- gmluke 10y ago
  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
  - johnnycarcin 10y ago
    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".
tex0 10y ago
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.
endymi0n 10y ago
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.
opmac 10y ago
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.
- e12e 10y ago
  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.
  - hackcasual 10y ago
    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).
kfrzcode 10y ago
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.

by zx2c4 10y ago

MetalMatze 10y ago

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.

benologist 10y ago
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.
gmluke 10y ago
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
- johnnycarcin 10y ago
  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".

tex0 10y ago

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.

endymi0n 10y ago

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.

opmac 10y ago

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.

e12e 10y ago
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.
- hackcasual 10y ago
  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).

kfrzcode 10y ago

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.