The irony of a security improvement which is equally insecure

Hey jscarle,

Thanks for writing in with your concern. We always appreciate feedback. I'm happy to add stdin as an input method to op create item to our roadmap. ref: dev/b5/op#1754 As you mention, there are definitely use cases where that is the best, most secure option. It's certainly the best option for, say, a .NET wrapper around our command-line tool 😉

One of the considerations that we make throughout all of our products is to aim for a secure default. We clearly missed the mark when asking users to pass vault item details as a command-line argument. As part of adding support for stdin, we'll want to make it clear to users how to securely use that as well.

I'd like to push back on the idea that storing the template JSON is equally insecure. When we asked users to pass their details as command-line arguments, there was little that a user could do to protect themselves. When writing to and editing a file, on *nix-like systems, we can ask users to set umask 077. On Windows systems, working in your own $HOME directory is the safest option (to our knowledge, at least!). And we can instruct users to take these precautions. You're correct in that deleted files can be recovered, but we still feel that this is a safer option than what we had before.

And, to your point, I think that having an option where we read from STDIN would also be acceptable from a security perspective.

I hope that this helps. Let me know if you have any additional questions or feedback.

Michael