Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > Hi, > > Am 28.07.24 um 23:27 schrieb Zack Weinberg: >> The*problem* with this is that it appears there's no way to make a >> file in the store not be world readable. >> >> What's the best way to deal with this situation? > > I feel your pain! Several years ago already I started a nullmailer > service for Guix - and never finished it for similar > reasons. (nullmailer expects the password being part of the config > file.) > > I'm afraid, the only solution is to create a service which generates > the config at boot time from a file containing the password and some > template (or guile data structure). The password file would not be > part of the Guix system definition. Anyhow I'm not aware of any > example, sorry. > > Please let me know if you implement something like this as I'd like to > eventally finish the nullmailer service :-)
At the start of my server configuration I have the following lines: (define smtpd-keys "/secrets/smtpd") (define radicale-keys "/secrets/radicale/keys") (define dovecot-keys "/secrets/dovecot") These files have appropriately limited permissions and are not tracked with any version control. It is my responsibility to ensure the integrity of this data. The /etc directory is writable for root, so if a configuration file must be in /etc , it can…? I wonder how that works with the system activation now. I am afraid that any undeclared files in /etc could get wiped on system reconfigurations. In the past I had attempted to maintain a file-based guix channel for secrets, but it was not possible to easily reconcile the necessity of declaring the channel as a dependency and having it on one system only.