[drdaeman]

Downside of pass is that the filenames are in the open. Thus, metadata (which sites you have account on) is not secured. Linked one seems to store everything in a single encrypted file.

Upside is that it has ton of implementations readily available - browser integration, mobile apps, etc. Linked one (passbox) is just a bash script at the moment, if one wants to use it across multiple devices and platforms, the experience may be quite rough.

Another upside is that with a single file model you have to invent your own conflict resolution scheme. For pass, git just does the trick. And this one doesn't seem to have anything in this regard.

[deathanatos]

> Downside of pass is that the filenames are in the open.

The "entry" names (which I think would correspond to filenames in `pass`) appear to be passed on the command line here; they'll likely get swept up in your shell's history file, unless you're careful. (And thus, are essentially in the open, just like pass.) That said, I think most shells make their histfiles 600, so they're not directly readable. (And I think `pass`'s directory is 700, similarly.) And you have to trust the machine you're running on, of course; otherwise, I can just dump the memory as soon as your keyring is decrypted.

I think it was when `pass` was on HN that I mentioned this; I have a terminal keyring manager myself[1], but one of the design decisions I made in it (aside from a single-file archive) was to not pass entry names on the command line, specifically so they won't get swept up in histfiles. It's easy, though, it make it optional, and let the user decide what they want to do. Of course, your

[1] which is way not ready to be looked at… also seems like we as a crowd enjoy this topic (keyrings) as a side project.

[drdaeman]

There is HISTIGNORE for a reason ;)

But, yeah, if one forgot to add pass there, the metadata will be leaked.

[deathanatos]

I did not know about HISTIGNORE! Very interesting. I knew about HISTCONTROL=ignorespace, though I did not know it was a variable; I just thought that was a hard-coded feature.

[jessaustin]

...filenames are in the open.

Is this something that can't be fixed by directory perms?

[drdaeman]

If you trust the box.

That said, if you have a secure trusted machine with FDE that you don't let strangers touch, and where every piece of software is well-isolated (for example, web browser is sandboxed and can't access the ~/.password-store/), then yeah, filesystem permissions will do the trick.

But, for example, if you sync using git repo hosted on some third-party VPS then directory permissions won't protect you from that host owner or whoever gains superuser access to the filesystem.

(Hey, don't downvote the parent, he didn't said anything wrong, just asked a question! In my opinion that contributes to the discussion.)

[ape4]

I agree. Perhaps a zip file with a password?