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