5 ms·
Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html https://vaultproject.io
by mitchellh 11y ago
Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html https://vaultproject.io/docs/commands/read-write.html So you should use what you feel is most secure given the data you're entering.
- sliverstorm 11y agoI think the argument is something like, why support a method that is insecure nearly all the time and leads less-experienced users to make the wrong choices. Good security software gently herds the non-expert to make good choices. Too many options, especially specialty risky options, don't help that goal.
- zobzu 11y agotrue most ppl will do it command line..
- kylequest 11y agoWhy not use interactive CLI instead of command line CLI (like routers have) to avoid leaks through the shell command history and other related channels?
- nunull 11y agoI think what you mean by "interactive CLI" is reading from stdin, which seams to be supported.
- mpdehaan2 11y agoThis is why ansible-vault (which is not trying to do the same thing) spawned a temporary editor, and immediately upon save encrypted the file - it doesn't exist in history, nor is there a chance of leaving it behind on disk. There's probably a way to do what you have launching an editor with stdin, but I'd probably suggest documenting an example, to avoid the risk of leaving the secret around. Also +1 to removing the insecure history option. Documenting the stdin to use 'cat' or something that's not in the history would probably take care of that one.