all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Marek Paśnikowski" <marek@marekpasnikowski.pl>
To: help-guix@gnu.org
Subject: Re: Another service definition question: Files containing secrets?
Date: Sat, 03 Aug 2024 11:09:58 +0200	[thread overview]
Message-ID: <87frrmgeft.fsf@marekpasnikowski.pl> (raw)
In-Reply-To: <99677080-16c8-4e20-ba7f-063a908272a5@crazy-compilers.com> (Hartmut Goebel's message of "Mon, 29 Jul 2024 17:38:31 +0200")

Hartmut Goebel <h.goebel@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.


  reply	other threads:[~2024-08-03  9:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-28 21:27 Another service definition question: Files containing secrets? Zack Weinberg
2024-07-29 15:38 ` Hartmut Goebel
2024-08-03  9:09   ` Marek Paśnikowski [this message]
2024-07-29 23:33 ` Giacomo via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frrmgeft.fsf@marekpasnikowski.pl \
    --to=marek@marekpasnikowski.pl \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.