Skip to content

ambiguity in config fields: file names vs verbatim strings #3792

Open
@srenatus

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 🤔

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions