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!). https://support.1password.com/command-line-getting-started/#parse-and-manipulate-json-output-with-jq. 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

That's some great news as it will allow the use of non-file based inputs, whichever the source. Thank you very much!

As for the $HOME directory, that's a Linux variable. The mistake is equally present on the documentation page. The Windows equivalent to cd $HOME would in fact be cd %USERPROFILE%.

In order to improve security by preventing command-line logging, there would also need to be an improvement made to op edit item (https://support.1password.com/command-line-reference/#edit-item) as there is currently no other way to edit an existing item other then to hand over a list of assignments.

Personally, I would love to see the addition of --filename <path> with the option to specify stdin in the same way as edit document does (--filename -). This would allow sending the full json of an existing item (either through a permission secured local file or through stdin) without logging any of the changes on the command-line.