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.

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.

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

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

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.)

Annoying amount of hubris.

This pile of unattractive bash-snippets is neither unix nor standard. Just call it what it is: A very dependent script that will probably work on most GNU/Linux distributions.

I had a play with 'pass' before but i wasn't keen on the way it splits the entries up into separate files which was one of the drivers for putting passbox together.

You can still decrypt the file with just GPG if you wanted and modify the file in plain text. Passbox just acts as a layer on top of that to interrogate the encrypted GPG file.

The only (somewhat big) downside to this, and related unix pw managers is the sheer lack of browser compatibility - mobile would also be nice, as that's one of the places where it's a PITA to use and enter long passphrases.

pass claims to have both, but doesn't:

https://github.com/jvenant/passff#readme does not work.

The iOS app has disappeared from github: https://github.com/rephorm/pass-ios#readme

It's solvable problems, I just find it a somewhat important part of a password manager.

Firefox and Chrome extensions are working, and I'm currently spending a few hours a week on migrating to the new Firefox-extension protocol.

How come you aren't bothered? I ask because I can't image apart from:

a. I use short or cryptically unsafe passphrases,

b. I use passphrases and type them easily,

c. I only need to log in a few times.

Am I forgetting others?

http://git.zx2c4.com/password-store/tree/contrib/dmenu/passm...

It types the selected password via xdotool.