ambiguity in config fields: file names vs verbatim strings #3792
Description
This came up discussing #3772: We're having a single field for keys that could either be file references, or verbatim secrets. The disambiguation happens by first attempting to pem.Decode
it (if it succeeds, it's a priv key of some sort), then trying to open it as a file, and if that yields a "file not found" error, we'll take it as a verbatim secret key string.
The understanding from the discussion there was that the last part is to support HMAC secrets which are "plain strings", not PEM encoded of some sort. As a consequence, certain HMAC secrets are impossible to use, like "/dev/null" on UNIX-y platforms.
While it's very unlikely to cause any trouble, I think it would be nicer if we avoided this kind of ambiguity altogether. For any X that could come from a file or a verbatim string, it would be preferable to have two config keys, X_file
and X
or something like that 🤔