Closed maxtaco closed 5 years ago
Maybe input is fine as is, but a --binary/-b
flag will force binary output (otherwise it's hex).
Yeah, makes sense. But then to decrypt it has to be hex-encoded and passed on the command line... Not really consistent.
I'm starting to think that making the key and not the message optional on the command line might have been a bad idea.
A stdin/stdout Unix flow migth be more elegant. But then how to pass a key in every day use without leaking it to bash history?
Maybe it's fine as is. If you want binary, you can do triplesec .... | xxd -r -p
?
This is fine with me, come to think of it.
I'm not totally fond of the 0x prepending thing, too
What about
triplesec [-k key] [-b|--binary] [-h|--hex] {enc|dec} [data]
Key: first checked for in the command line, then in the ENV var $TRIPLESEC_KEY, the prompted from stdin
-h
makes everything hex: key, plaintext, ciphertext-b
makes everything binary: key, plaintext, ciphertext (imagined for piping)this is great.
Seems done.
Umh, any preference on how exactly to handle this?
At the moment any parameter can be specified as hex by prepending 0x.
As for binary I'm not sure we should get 8-bit input from the command line arguments, so I guess switch to (key as argv[1], input in stdin)?