Loading
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.