TSIG secret can also be a path to a file, but what's the formula?

[jpmens]

cascade 0.1.0-beta2-dev at 2f9fee2

I was provoked by the sentence

Can also be a path to a file containing the Base64 encoded secret key material

in the help text of cascade tsig add --help.

It would appear that if a file exists, its content is used, otherwise the specified SECRET. I think this ought to be briefly documented in the help text.

filename which looks like base64 is used

$ echo "vmvBDFsB2vX5C0QqRUmuVMOvr52a3MgfQRu65hsRhM4=" > $(echo J | base64)
$ ls -l S*
-rw-rw-r-- 1 jpm jpm 45 Jun  7 06:55 'Sgo='

$ cat Sgo= 
vmvBDFsB2vX5C0QqRUmuVMOvr52a3MgfQRu65hsRhM4=

$ cascade tsig add sunday1 hmac-sha256 Sg*
Added TSIG key 'sunday1'

$ jq .map.sunday1 < tsig-keys.db 
{
  "alg": "hmac-sha256",
  "data": "vmvBDFsB2vX5C0QqRUmuVMOvr52a3MgfQRu65hsRhM4="
}

use base64 secret

$ echo JP | base64
SlAK

$ cascade tsig add sunday2 hmac-sha256 SlAK
Added TSIG key 'sunday2'

$ jq .map.sunday2 < tsig-keys.db 
{
  "alg": "hmac-sha256",
  "data": "SlAK"
}

use any old clear text

$ cascade tsig add sunday3 hmac-sha256 blabla17
Added TSIG key 'sunday3'

$ jq .map.sunday3 < tsig-keys.db 
{
  "alg": "hmac-sha256",
  "data": "blabla17"
}

and I lose track because file is ENOENT, but it is valid base64 :-D

$ cascade tsig add sunday4 hmac-sha256 /tmp/404
Added TSIG key 'sunday4'

$ jq .map.sunday4 < tsig-keys.db 
{
  "alg": "hmac-sha256",
  "data": "/tmp/404"
}

[ximon18]

Hi @jpmens,

The documentation is trying to say that the <SECRET> positional argument can be either a base64 encoded string OR a filename/path to a file and that that the contents of that file should be a base64 encoded textual representation of the secret key bytes.

Regarding your various cases above:

1. "filename which looks like base64 is used" - It is not the intention that the filename itself be base64 encoded.
2. "use base64 secret" - This is a supported use, base64 encoded secret key bytes as the positional argument value.
3. "use any old clear text" - The Cascade CLI will pass the bytes given as-is to the server. The server will attempt to base64 decode them and keep them if successful, or return an error otherwise.
4. "and I lose track because file is ENOENT, but it is valid base64 :-D" - The Cascade CLI checks if the given argument is an existing path and if so attempts to open it. If you provide a mistyped path that doesn't exist the text will be used as-is.

This first iteration of the tsig add CLI clearly has some rough edges.

Rather than overload the meaning of the <SECRET> argument perhaps it would be better if the CLI require the operator to explicitly supply a file. As other tools that produce/consume TSIG keys via files also include the key name and algorithm in the file we should perhaps also do the same.

Ximon

[jpmens]

@ximon18 alternatively do away with reading from a file and simplify: seeing as a base64-encoded string is expected I can do either of the following (or any shell variants thereof):

$ cascade tsig add monday1 hmac-sha256 "Y29mZmVlCg=="
$ cascade tsig add monday2 hmac-sha256 "$(cat filename)"

There is a very small risk of ps(1) leaking the secret, but as the Cascade host is likely to be used by just a very few people (who can probably look at tsig-keys.db anyway), I don't think it's a big deal.

[ximon18]

Indeed that risk of leakage was the rationale for supporting file based input based on original PR feedback.