nixos/forgejo: refactor secrets, add `cfg.secrets`

This is not a breaking change. Existing setups continue to work as-is.

Users of `cfg.mailerPasswordFile` will get an option rename/deprecation
warning, but that's it (assuming there is no regression).

This adds `cfg.secrets`, which is a wrapper over systemd's
`LoadCredential=` leveraging Forgejo's `environment-to-ini`.

`environment-to-ini` is intended for configuring Forgejo in OCI
containers.

It requires some fairly annoying escaping of the section names to fit
into the allowed environment variable charset.

E.g. `"log.console".COLORIZE = false` becomes
`FORGEJO__LOG_0x2E_CONSOLE__COLORIZE=false`.

 - `.` needs to be replaced with `_0X2E_` and
 - `-` needs to be replaced with `_0X2D_`

Those are simply the hex representation of each char from an ASCII
table:

. = ASCII 46 = 46 (decimal) = 2E (hex) = 0x2E = _OX2E_

To make interacting with `environment-to-ini` less annoying, we template
and escape the sections/keys in nix:

`cfg.secrets` takes the same free-form sections/keys as `cfg.settings`.
Meaning there is now a generalized abstraction for all keys, not just
those that have been manually implemented in the past.

It goes as far as theoretically allowing one to have `DEFAULT.APP_NAME`
read from a secret file.

I don't know why one would want to do that, but it has been made
possible by this :^)

More reasonable examples are listed in the `cfg.secrets` option example.

We also continue to bootstrap a handful of secrets like
`security.SECRET_KEY`. This is done is a sort of sidecar bootstrap unit
fittingly called `forgejo-secrets.service`.

Overriding those is, just like before, not really intended and requires
the use of `lib.mkForce` and might lead to breakage. But it is, in a
way, more possible than before.

0 files changed, 0 insertions, 0 deletions