9 ms·
> 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 cle
by zeveb 10y ago
> 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.
- dewey 10y agoI 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.
- abeyer 10y ago> 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.
- aeorgnoieang 10y agoI 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. [1]: https://spwhitton.name/tech/code/git-remote-gcrypt/ https://spwhitton.name/tech/code/git-remote-gcrypt/
- johnnycarcin 10y agoHoly cow, thank you for this!
- zeveb 10y agoThat is pretty cool, although I'd _also_ like to have the filenames encrypted on my machine.