Proposal: Support for "Special" String Values (Such as Secrets)

Problem Definition

Cuttlefish does its job well but there's one area where it is not particularly strong: specifying secrets such as passwords, PII or other values that cannot or should not be stored in the config files.

Using advanced.config is an option for those cases but using it is error prone or, for those who are not Erlang-savvy, is often not an option.

Cuttlefish will be more useful in more contexts if it introduces a way to store (references to) such sensitive values.

The Proposal

Cuttlefish can introduce support for "tagged values" that would be translated into
Erlang tuples in the generated configuration file. The value can be specified using a syntax extension, something like this:

• ${{secret:tls.private_key.password}}
• {secret:tls.private_key.password}

Or even a sigil (I do not like this idea personally):

• $secret:tls.private_key.password

With an example app.conf like this

connection.username = cuttlefish
connection.password = ${{secret:connection.password}}

A generated value may look like this:

[
  {my_app, [
    {tls, [
      {private_key, [
        {password, {secret, <<"connection.password">>}}
      ]}
    ]}
  ]}
].

How exactly the {secret, Value} tuple is interpreted by the application should not matter to Cuttlefish, its job would be to generate a special value that can be distinguished by its structure.
The actual secret value then can be retrieved from a suitable secret store.

"Value tags" can be arbitrary strings that will be propagated to the tuple:

connection.username = cuttlefish
connection.password = ${{secret_store_key:connection.password}}

A generated value then will look like this:

[
  {my_app, [
    {tls, [
      {private_key, [
        {password, {secret_store_key, <<"connection.password">>}}
      ]}
    ]}
  ]}
].

Alternatives Considered

It's technically possible to do exactly this already with the help of a relatively simple translation. But for the sake of code/knowledge reuse and establishing a common convention, I'd like to propose this syntactic extension.