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.
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.
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.
I'm pretty excited about this actually. Thank-you so much for your efforts.
I've been using pass for awhile now, and I really love what it does, but it's a case where it feels 90% finished.
I have one desperate request; colour output as an option.
Every time there is an update to pass (or I need to reinstall) I need to edit the file and change the options from " tree -C " to " tree -n "
This is a pain in the ass.
I am visually impaired. The 'default' dark-blue that tree uses for directories is unreadable to me.
My two choices for dealing with this are to use DIRCOLORS or edit the pass executable. I'd prefer to not muck about with my environment settings. (as I do not normally see any colour output)
I just created an issue for that. Shouldn't be that hard to support it. Feel free to subscribe to the issue on github or comment any thing that's missing. Thanks!
> 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.
This is my concern with pass. It's an awesome tool, but it really needs to figure out a way to hide the filenames. I think this is doable (after all, encfs has the same need, and does it well), but I don't know if the pass team have the will to do it.
> First, the project is curated in a traditional mailing-list based approach that was pretty unapproachable compared to a modern Github based workflow.
Sigh, not this again. I think that I prefer email vice a proprietary, centralised single point of failure like GitHub, and I know that I'd rather not work with someone who considers email unapproachable.
If your email account is unmanageable, fix it. Email's a really, really valuable tool; don't let go of it.
> Sigh, not this again. I think that I prefer email vice a proprietary, centralised single point of failure like GitHub, and I know that I'd rather not work with someone who considers email unapproachable.
That's a fair debate in general, and I think you're right that there are some advantages to mailing-list driven approaches when they're done really well.
But after being subscribed to the pass list the last few months (and having seen similar situations on other projects in the past), I've been a bit underwhelmed with the actual execution there. There seems to be a lack of transparency around how to submit, what to submit, if/when/how it's considered or evaluated for incorporation, and when that might actually make it to a release. As a result there seems to be (even in this fairly short time) lots of repeated conversations about similar fixes/features/ideas and duplicate and overlapping patches around them.
I get that it seems to be a one-person show, and maybe not his/her top priority, and don't mean this as a criticism of the project (which I use and love.) But I think it's valuable to note that mail based models do really need active and engaged maintainers on the list all the time to make them work out well. If they aren't able or willing to do so, and want to be a bit more hands-off, I think github or something like it perhaps is a better model.
I don't see how GitHub is a single point of failure, the tool was developed on an internal Gitlab instance and then just pushed to GitHub. In case anything happens to GitHub you'd just have to push it to some new service and update the website. Nothing will be lost.
It's just more exposure to put it on GitHub right now because most people bookmark/star there repositories there and don't want to bookmark different cgit/Gitlab/gogs/gitea links. I don't think anyone is abandoning emails just because they don't want to email patches around and manually apply them.
I use git-remote-gcrypt[1] for configuring remotes for all of my local Pass repos. I just point the 'gcrypt' remote to a file in Dropbox and voila, a fully encrypted Git repo for syncing all of my individual Pass repos.
Shameless self plug, I actually build a project called passgo, modeled after Jason's pass project as well. I'm a huge fan of pass' simplicity, but I really dislike managing keys:
The difference is mine does not use PGP and is instead password based, but the command line interface is almost identical. I now use passgo to encrypt and manage my ssh keys, etc.
I've used QTPass. It provides support to encrypt password directories to multiple keys. It allows for multiple profiles as well, so one can have a team password store as well as a private one. It can also auto push/pull. Plus it has a nice cross platform gui.
Can you elaborate on the differences between how gopass and QTPass accomplish these things and why one might want to choose gopass instead?
Should tab completion work with gopass? Seems pretty unusable to me as a general purpose password manager without it, but it doesn't work for me out of the box with a `go get` source install.
I've been using `pass` for a very long time, and in combination with dmenu or rofi, it has proven to improve my workflow accessing passphrases a lot.
For 'teams' (and serv{er, ices}) I've started implementing some stuff via. vault-project [0]. The project looks really promising, sadly never got up-voted on HN so far.
The basic concept of vault is a centralized storage of secrets, managed via. Access-Control-Lists (ACLs) and accessible via. REST.
Because the secrets are only accessible from a single point, you'll also have an overview of who did access which secret (called audit log). It's also possible to implement replacing all necessary secrets whenever someone has left/changed the group that got access to the secrets.
Vault also makes integration in certain provisioning tools possible (though, that's something you need to spend more development in).
Vault provides many database-backends [1], but also various other things (like ssh [2]).
Really weird that there's no mention of 1Password and its flexibility through both 1Password for Teams and 1Password Shared Vaults. I work with 2 different teams that share passwords like this and one of them has a shared vault that syncs through Dropbox for everyone while the other one is managed through 1Password for Teams so that we can update passwords and access at our discretion.
I'm very curious to see how this will stack up against those solutions because, to be honest, there is very little room for improvement from 1Password, in my eyes. They have a very, very solid and secure product and the UI is fantastic.
Not viable until they support Linux which they've put zero effort into doing even though it's been requested for years. I used to use it in Wine which was decent but the Chrome extension couldn't talk to the app which makes using it a terrible UX (open app, search for pass, copy, paste, over and over).
Literally the only reason I currently use OSX. A password manager...
Instead they've become a SAAS Lastpass competitor which literally nobody asked for, in fact people were trying to leave LastPass due it it's forced-online nature (which naturally frightens people, having your passwords stored online somewhere).
I was using Bruce Schneier's Password Safe (and various compatible apps: pwSafe on Mac and iOS and Password Gorilla on an older Mac and Linux boxes) and the big pain for me was merging changes.
I'd found that trying to use a single 'safe' via Dropbox was a recipe for disaster because some of the programs wouldn't cleanly close the safe file, or at least one of them would occasionally complain about the state of the file. So I created a copy of the safe for each of my computers and devices. Then every 6 months or so I'd merge all of the safe files into a single file and recreate all of the device-specific files as copies of that single file.
But merging in Password Safe sucked. There was no way to review the differences between entries in different safes, other than manually inspecting entries. I don't believe either of the two versions (Mac and iOS) of pwSafe (both version 1) supported merging at all. Password Gorilla was actually the best among the bunch as it had a nice 'diff' window with which you could explicitly pick which version of several fields for an entry you wanted to retain. But sometimes I couldn't get its 'diff' window to fit on my screen so I'd have to plug my laptop into a larger monitor.
Using Pass with Git is so much easier.
I've also been using git-remote-gcrypt[1] to push my local Pass repos to a shared 'remote' file stored in Dropbox. It works great.
The only painful aspects of Pass now is the weird behavior of `gpg` on Windows in Cygwin and the clunkiness of my current multi-repo setup. Hopefully running Pass under "Bash on Ubuntu on Windows" will mitigate the former. Given that Pass is written in Bash and that the various repo config settings are read from environment variables, it doesn't seem likely that the latter will get much better than my current setup, which involves sourcing a script to switch the relevant environment variables.
I know the pain of managing the synchronization of your password store. That's exactly why we enable git by default now and auto commit all you changes like pass did before. For me it works great personally, but also with a team it's awesome.
It just feels like working with people that know git on something not encrypted.
Regard the windows support we would be happy to get as much feedback on that as possible. Nobody of us uses windows with gopass. If you have any idea how to improve the experience please let us know. Thanks!
This looks great, I've been toying with something similar built on top of Keybase that I just use for personal passwords, but using KBFS means it should be simple to extend it to shared passwords, since you just store it in the `private/me,you` directory instead of `private/me`.
My concern with using something like this or pass is that I have to manage the distribution/backup of the store/vault/db myself - whereas I can throw my laptop off a cliff, buy a new one, login to Keybase, and my passwords are still there.
Pretty neat, and addresses a space where no tools seem to exist.
Would be cool if it could leverage a GitHub public repo for password updates. Something like using the list of collaborators on a repo, iterate over their GH public keys, and push new encrypted files for each collaborator on the repo.
I suppose though, this would leak a lot of metadata on how the tool is being used, and would tie it too closely to GitHub vs just git.
You can use a public repo - we just wouldn't recommend it at this point in time, for the obvious reason of metadata leakage. We're currently thinking hard about how to enable this while still leaving the nice properties of git merges alone - might be some kind of shadow mode with hashed identifiers in the end.
Yep. I'm using that extension on Chrome everyday with gopass in the background. Works great!
Now that we published gopass I wanted to take another look at the source of browserpass in the coming days. Maybe we can try to support both pass & gopass (with the new features).
We're happy to include Windows as well (shouldn't be that hard to integrate thanks to Go), but there's simply nobody using Windows in the team at this point. Feel free to contribute - this project is meant to be the rock solid base of a very versatile password manager ecosystem.
[+] [-] zx2c4|9 years ago|reply
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.
[+] [-] endymi0n|9 years ago|reply
[+] [-] kfrzcode|9 years ago|reply
People like you are the reason people like me are in this business.
Fuck, I love the Internet.
[+] [-] MetalMatze|9 years ago|reply
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.
[+] [-] opmac|9 years ago|reply
> 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.
[+] [-] tex0|9 years ago|reply
But I don't want to spend my time writing bash and sending patches by mail.
[+] [-] VA3FXP|9 years ago|reply
I have one desperate request; colour output as an option. Every time there is an update to pass (or I need to reinstall) I need to edit the file and change the options from " tree -C " to " tree -n "
This is a pain in the ass. I am visually impaired. The 'default' dark-blue that tree uses for directories is unreadable to me.
My two choices for dealing with this are to use DIRCOLORS or edit the pass executable. I'd prefer to not muck about with my environment settings. (as I do not normally see any colour output)
Anyway; awesome project!
[+] [-] MetalMatze|9 years ago|reply
I just created an issue for that. Shouldn't be that hard to support it. Feel free to subscribe to the issue on github or comment any thing that's missing. Thanks!
[+] [-] zeveb|9 years ago|reply
This is my concern with pass. It's an awesome tool, but it really needs to figure out a way to hide the filenames. I think this is doable (after all, encfs has the same need, and does it well), but I don't know if the pass team have the will to do it.
> First, the project is curated in a traditional mailing-list based approach that was pretty unapproachable compared to a modern Github based workflow.
Sigh, not this again. I think that I prefer email vice a proprietary, centralised single point of failure like GitHub, and I know that I'd rather not work with someone who considers email unapproachable.
If your email account is unmanageable, fix it. Email's a really, really valuable tool; don't let go of it.
[+] [-] abeyer|9 years ago|reply
That's a fair debate in general, and I think you're right that there are some advantages to mailing-list driven approaches when they're done really well.
But after being subscribed to the pass list the last few months (and having seen similar situations on other projects in the past), I've been a bit underwhelmed with the actual execution there. There seems to be a lack of transparency around how to submit, what to submit, if/when/how it's considered or evaluated for incorporation, and when that might actually make it to a release. As a result there seems to be (even in this fairly short time) lots of repeated conversations about similar fixes/features/ideas and duplicate and overlapping patches around them.
I get that it seems to be a one-person show, and maybe not his/her top priority, and don't mean this as a criticism of the project (which I use and love.) But I think it's valuable to note that mail based models do really need active and engaged maintainers on the list all the time to make them work out well. If they aren't able or willing to do so, and want to be a bit more hands-off, I think github or something like it perhaps is a better model.
[+] [-] dewey|9 years ago|reply
It's just more exposure to put it on GitHub right now because most people bookmark/star there repositories there and don't want to bookmark different cgit/Gitlab/gogs/gitea links. I don't think anyone is abandoning emails just because they don't want to email patches around and manually apply them.
[+] [-] aeorgnoieang|9 years ago|reply
[1]: https://spwhitton.name/tech/code/git-remote-gcrypt/
[+] [-] ejcx|9 years ago|reply
https://github.com/ejcx/passgo
The difference is mine does not use PGP and is instead password based, but the command line interface is almost identical. I now use passgo to encrypt and manage my ssh keys, etc.
[+] [-] MetalMatze|9 years ago|reply
> The difference is mine does not use PGP and is instead password based...
And we still wanted to use PGP because crypto is hard. :)
[+] [-] endymi0n|9 years ago|reply
[+] [-] danjoc|9 years ago|reply
Can you elaborate on the differences between how gopass and QTPass accomplish these things and why one might want to choose gopass instead?
[+] [-] kfrzcode|9 years ago|reply
[+] [-] EdwinHoksberg|9 years ago|reply
[+] [-] LamaOfRuin|9 years ago|reply
Edit: found it on the github readme https://github.com/justwatchcom/gopass#autocompletion
[+] [-] miduil|9 years ago|reply
For 'teams' (and serv{er, ices}) I've started implementing some stuff via. vault-project [0]. The project looks really promising, sadly never got up-voted on HN so far.
The basic concept of vault is a centralized storage of secrets, managed via. Access-Control-Lists (ACLs) and accessible via. REST. Because the secrets are only accessible from a single point, you'll also have an overview of who did access which secret (called audit log). It's also possible to implement replacing all necessary secrets whenever someone has left/changed the group that got access to the secrets. Vault also makes integration in certain provisioning tools possible (though, that's something you need to spend more development in). Vault provides many database-backends [1], but also various other things (like ssh [2]).
Other things for managing secrets are:
- keywhiz: https://square.github.io/keywhiz/single_page.html
- keyringer: https://keyringer.pw
[0]: https://www.vaultproject.io/
[1]: https://www.vaultproject.io/docs/secrets/index.html
[2]: https://www.vaultproject.io/docs/secrets/ssh/index.html
[+] [-] MetalMatze|9 years ago|reply
However Vault is mostly meant for machines to read the secrets and gopass is designed for humans.
[+] [-] riffic|9 years ago|reply
[+] [-] dkonofalski|9 years ago|reply
I'm very curious to see how this will stack up against those solutions because, to be honest, there is very little room for improvement from 1Password, in my eyes. They have a very, very solid and secure product and the UI is fantastic.
[+] [-] swozey|9 years ago|reply
Literally the only reason I currently use OSX. A password manager...
Here's the 6 year old 35 page thread if you want to throw your vote into a black hole; https://discussions.agilebits.com/discussion/2846/new-produc...
Instead they've become a SAAS Lastpass competitor which literally nobody asked for, in fact people were trying to leave LastPass due it it's forced-online nature (which naturally frightens people, having your passwords stored online somewhere).
[+] [-] tbrock|9 years ago|reply
No Linux support, crappy website, high price.
[+] [-] draven|9 years ago|reply
Gopass seems great, especially the multistore support (which you can do w/ pass by setting an env variable), thank you for your work!
[+] [-] nerdponx|9 years ago|reply
[+] [-] aeorgnoieang|9 years ago|reply
I was using Bruce Schneier's Password Safe (and various compatible apps: pwSafe on Mac and iOS and Password Gorilla on an older Mac and Linux boxes) and the big pain for me was merging changes.
I'd found that trying to use a single 'safe' via Dropbox was a recipe for disaster because some of the programs wouldn't cleanly close the safe file, or at least one of them would occasionally complain about the state of the file. So I created a copy of the safe for each of my computers and devices. Then every 6 months or so I'd merge all of the safe files into a single file and recreate all of the device-specific files as copies of that single file.
But merging in Password Safe sucked. There was no way to review the differences between entries in different safes, other than manually inspecting entries. I don't believe either of the two versions (Mac and iOS) of pwSafe (both version 1) supported merging at all. Password Gorilla was actually the best among the bunch as it had a nice 'diff' window with which you could explicitly pick which version of several fields for an entry you wanted to retain. But sometimes I couldn't get its 'diff' window to fit on my screen so I'd have to plug my laptop into a larger monitor.
Using Pass with Git is so much easier.
I've also been using git-remote-gcrypt[1] to push my local Pass repos to a shared 'remote' file stored in Dropbox. It works great.
[1] https://spwhitton.name/tech/code/git-remote-gcrypt/
The only painful aspects of Pass now is the weird behavior of `gpg` on Windows in Cygwin and the clunkiness of my current multi-repo setup. Hopefully running Pass under "Bash on Ubuntu on Windows" will mitigate the former. Given that Pass is written in Bash and that the various repo config settings are read from environment variables, it doesn't seem likely that the latter will get much better than my current setup, which involves sourcing a script to switch the relevant environment variables.
[+] [-] MetalMatze|9 years ago|reply
Regard the windows support we would be happy to get as much feedback on that as possible. Nobody of us uses windows with gopass. If you have any idea how to improve the experience please let us know. Thanks!
[+] [-] OJFord|9 years ago|reply
My concern with using something like this or pass is that I have to manage the distribution/backup of the store/vault/db myself - whereas I can throw my laptop off a cliff, buy a new one, login to Keybase, and my passwords are still there.
[+] [-] jpeeler|9 years ago|reply
[+] [-] tyingq|9 years ago|reply
Would be cool if it could leverage a GitHub public repo for password updates. Something like using the list of collaborators on a repo, iterate over their GH public keys, and push new encrypted files for each collaborator on the repo.
I suppose though, this would leak a lot of metadata on how the tool is being used, and would tie it too closely to GitHub vs just git.
[+] [-] hobarrera|9 years ago|reply
It's literally a port of an existing tool, so a tool DID exist.
[+] [-] endymi0n|9 years ago|reply
[+] [-] praseodym|9 years ago|reply
[+] [-] MetalMatze|9 years ago|reply
[+] [-] rkeene2|9 years ago|reply
https://chiselapp.com/user/rkeene/repository/hunter2/
[+] [-] marcosnils|9 years ago|reply
[+] [-] WhitneyLand|9 years ago|reply
[+] [-] Roritharr|9 years ago|reply
There was TeamPass, which was buggy as hell and shouldn't be touched with a long pole... ...but why is there nothing else?
Where can i donate twice my yearly LastPass fee to get something self-hostable opensource and fund their Audits?
And no, Keepass in Dropbox/NextCloud/WhateverStorage doesn't work for a company that has Non-IT People needing access to passwords.
[+] [-] eridius|9 years ago|reply
[+] [-] endymi0n|9 years ago|reply
[+] [-] creshal|9 years ago|reply
(Mobile OS clients are on the roadmap.)
[+] [-] devopsproject|9 years ago|reply
[+] [-] homakov|9 years ago|reply
[+] [-] Daviey|9 years ago|reply