freakingpenguin blog

Guix Tricks: Managing secrets using password-store and run-time decryption scripts.

2024-12-10T12:00:00Z

Intro

Guix is a package management tool with support for declarative operation. By declarative, I mean I can write various objects—such as an operating system configuration—in a text file. Guix will take that text file and use it to create what I want. For example...

(define %simple-os
  (operating-system
    (host-name "komputilo")
    (timezone "America/New_York")
    (locale "en_US.UTF-8")

    (bootloader (bootloader-configuration
                 (bootloader grub-bootloader)
                 (targets '("/dev/sdX"))))
    (file-systems (cons (file-system
                          (device (file-system-label "my-root"))
                          (mount-point "/")
                          (type "ext4"))
                        %base-file-systems))

    (users (cons (user-account
                  (name "alice")
                  (comment "Bob's sister")
                  (group "users")
                  (supplementary-groups '("wheel" "audio" "video")))
                 %base-user-accounts))))

Generally speaking, anything stored in these files or built from them should be considered public knowledge. Even if I decide not to share the declarative files, the outputs from building them are placed in a location called the store, unencrypted and globally readable on the hard drive. It would be trivial for an attacker to capture private information from these files.

This presents a challenge. How can we use private information (i.e. secrets) in these files without leaking said secrets?

There are three solutions I can think of.

Create files containing secrets manually and avoid using Guix. Set permissions to limit readability.
Use a service to store secrets in the store encrypted, then decrypt them on boot and place them in the desired location.
Store the secrets encrypted, then run scripts to retrieve them on an as-needed basis.

In this post I will be discussing how I implement the 3rd solution. If 2 sounds interested, check out sops-guix.

Runtime Decryption and Retrieval

The Not State of the Art Solution

I store my secrets encrypted in a separate, private Git repository using password-store. For this strategy to work, the service or program being configured needs to support running a script to retrieve a secret.

Consider my git configuration. I regularly use the $ git send-email command. While I could manually decrypt my password and paste that when prompted, I would rather git do that automatically. Fortunately, git supports running an arbitrary command to retrieve the password. This is done by setting core.askPass.

I could construct my git config like this:

;; Git does not actually support arguments for askPass.
;; For brevity I am going to pretend it does.
(define rsent-git-config-file
  (plain-file "git-config"
                   "
[core]
        askPass = pass ls Passwords/MyEmailAccount"))

# Contents of .config/git/config
[core]
        askPass = pass ls Passwords/MyEmailAccount

While it works in this example, this solution is not as general purpose as it could be. This solution:

Requires an environment where the PATH environment variable is already set.
Makes it challenging to switch off of password-store in the future.
Creates an unlinked dependency in my code because I have to install password-store elsewhere.

Some of these issues can be mitigated while still invoking pass directly but I believe there's a better way.

A More Guixy Way

Instead of invoking pass directly in my git config file, I go another route. In essence, I write a function that takes a "key" for what I want to retrieve. This function returns a script that, when invoked, decrypts the secret associated with said key and returns its value.

(define rsent-get-smtp-password-script
  (get-secret-program-file "git-getpass" "Passwords/MyEmailAccount"))

(define rsent-git-config-file
  (mixed-text-file "git-config"
                   "
[core]
        askPass = " rsent-get-smtp-password-script "
"))

# Contents of .config/git/config
[core]
        askPass = /gnu/store/...-git-getpass

get-secret-program-file in turn looks something like this:

(define (get-secret-program-file name key)
  "Returns a file-like object capable of retrieving the secret for @var{key}."
  (program-file name #~(display #$(get-secret key))))

As you can probably guess, most of the magic happens in another function called get-secret. This function is quite a bit more complicated than I want to dive into, but I'll share an abbreviated version. (Until recently this function was short, but then GnuPG pinentry fun happened.)

(define (get-secret key)
  "Returns a @code{gexp} that returns the associated secret for @var{key}.
Key should be in the form of a password-store path."
  #~(begin
      (use-modules (ice-9 format)
                   (ice-9 popen)
                   (ice-9 rdelim))
      (format (current-error-port) "~!Fetching secret for ~a... " #$key)
      (let* ((port (open-input-pipe
                    (string-append
                     #$(file-append password-store "/bin/pass")
                     " ls " #$key)))
             (str (read-line port)))
        (close-pipe port)
        (when (eof-object? str)
          (error "Failed to retrieve secret for" #$key))
        (format (current-error-port) "~!done~%")
        str)))

I want to emphasize how flexible this solution is. Any arbitrary Scheme code can be placed in get-secret, invoking any combination of external programs. If in the future I want to switch to another secret management system, I only need to rework one function and everything that works with secrets will use the new system.

Conclusion

Guix does not have an official integrated method for secrets management. This leads to users creating ad-hoc solutions. One such method is creating executable scripts that can decrypt and retrieve secrets, then embedding those scripts in the appropriate program or service.

Here are the positives to this approach:

Secrets are always encrypted on disk.
Works for both Guix System and Guix Home.
It is easy to migrate between different methods for storing secrets.

However, there are limitations:

The services and/or programs being configured need to support executing programs to retrieve secrets.
User interaction is generally recommended to protect against unauthorized access.
The creator is responsible for ensuring the script is secure, especially if it is designed to operate non-interactivity
Debugging requires a thorough understanding of the context the script is running in. For example, system services have a barer environment than home services.

Guix Tricks: Soft-pinning channels in a channels.scm file.

2024-05-26T12:00:00Z

Problem

Guix is a very powerful tool to integrate into a project's toolchain. This isn't just for build systems. It can also apply to tools like interactive interpreters and debuggers. By creating a project-wide channels.scm file, you can prepend tool scripts with both guix time-machine and guix shell invocations. This allows for easy integration of additional Guix channels and ensures that every developer has development tools available to them that aren't reliant on the outside environment.

You can see an example of me using this here to invoke a Guile REPL with the Guix and rsent-freakingpenguin channels. This includes a dependency of rsent-freakingpenguin: guile-blocks. I also use it in the ./bin/serve script to build and locally deploy the website for testing.

However, one challenge of guix time-machine is that unless you are willing to pin channels to specific commits, it will ALWAYS try to pull the latest version of that channel. Because channels are always changing (particularly the Guix channel) this can introduce significant delays when, say, invoking a Guile REPL after a new Guix commit was pushed.

As mentioned, one solution is to pin channels to specific version or branches. However, this has several drawbacks:

The commit needs to be updated regularly to ensure compatibility with newer tools.
When first run, developers still need to pull an entirely different commit to what they're running.
It implies that the developer tools require that specific commit to function even if that is not the case.

My proposed solution to this is a concept I'll call "soft-pinning", which means "try to use whatever commit of this channel that is currently present on the user's profile". This will let us mix and match channels into different categories. One category is kept up to date at all times while the other is only updated as the user updates their system.

Solution

To implement this, we can take advantage of the fact that channels.scm is Guile Scheme code and use the current-channels procedure in the (guix describe) module. Here's the code:

;; Use this file with time-machine -C to get an up to date copy of
;; this channel and any dependencies.
(use-modules (srfi srfi-1)
             (guix channels)
             (guix describe)
             (ice-9 control))

(define (soft-pin-channel input-channel)
  "Given @var{channel}, return a new version of channel that uses the
current profile's commit of said channel. If the channel is not present,
commit is #f."
  (define (desired-channel? channel)
    (equal? (channel-name input-channel)
            (channel-name channel)))

  (define (profile-commit input-channel)
    (call/ec
     (lambda (return)
       (map (lambda (x)
              (when (desired-channel? x)
                (return (channel-commit x))))
            (current-channels))
       #f)))

  (channel
   (inherit input-channel)
   (commit (profile-commit input-channel))))

;; Note that if you try running this in a container (say, the
;; project's interactive Guile), the commit picked up will match the
;; Guix package in the container's profile. It will not match the
;; user's current profile channel commit.
(cons*
 (channel
  (name 'freakingpenguin)
  (url (string-append "file://" (getcwd))))
 (list
  (soft-pin-channel %default-guix-channel)))

Now, invoking the Guile REPL is instantaneous as long as the freakingpenguin channel does not change. I no longer have a minute delay or more every time a new Guix commit is pushed, while still not having to pin Guix at a specific commit.

Guix Tricks: Self-contained shebang scripts.

2024-05-11T12:00:00Z

Intro

I like scripts. You like scripts. We all like scripts. But, I don't like that when I give a script to someone else, they need to install X, Y, and Z packages for that script to work. I don't like that my scripts may behave differently depending on the user's environment. I don't like needing to install a bunch of packages in a CI environment before running my./bin/*scripts. If ONLY someone could help me!

Consider the following script:

#!/usr/bin/env -S emacs -x
;; -*- mode: emacs-lisp; -*-
;; https://orgmode.org/manual/Bare-HTML.html
(setq org-html-head ""
      org-html-head-extra ""
      org-html-head-include-default-style nil
      org-html-head-include-scripts nil
      org-html-postamble nil
      org-html-preamble nil
      org-html-use-infojs nil
      org-html-mathjax-template "")

(defvar build-status-image
  (concat "#+ATTR_HTML: :alt builds.sr.ht status
[[https://builds.sr.ht/~freakingpenguin/" (getenv "repo") "]"
"[https://builds.sr.ht/~freakingpenguin/" (getenv "repo") ".svg]]
"))

(with-current-buffer (find-file-noselect (nth 0 argv))
  (insert build-status-image)
  (org-html-export-to-html))

This is a script that takes an org-mode file and generates an HTML file. A perfect task for a CI job. Ideally, we want this script to contain all the information required to run it, including the packages it requires. Keeping this information together in one file makes it easier to track and simpler for anyone to run the script.

To both install Emacs AND run the script in one go, all we have to do is replace the shebang with this:

#!/usr/bin/env -S guix shell emacs emacs-htmlize -- emacs -x

I like this because it lets me avoid needing to learn complicated tools like Docker for something that should be a simple task. A concept like "run command X with software Y in a containerized environment" can be expressed using basic tooling (shebangs) everyone is already familiar with. I may know how Docker works and how to write Dockerfiles, but without regular, consistent use it's easy to forget their syntax and need to relearn it yet again. Shell scripts are universal. 💕

Another example

You can go one step further and run the script in a containerized environment to ensure that you captured all possible dependencies and that the behavior is consistent regardless of the user's environment.

For particularly version-sensitive scripts, you can combine this with guix time-machine. Then, all dependencies required to run the script can be near-effortlessly frozen and guaranteed to run identically between invocations.

Using guix shell in shebangs makes running arbitrary projects with Emacs'scompile-command a breeze, since it boils down the complicated task of environment setup all the way down to just a running a script. Like, for example, with how I build this site. In./bin/serve:

#!/usr/bin/env -S guix shell ruby ruby-colorize -- ruby
# -*- mode: ruby; -*-
require 'optparse'
require 'colorize'
require 'socket'

bind = "localhost"
quiet = ""
no_substitutes = ""
options = {}
OptionParser.new do |opts|
  opts.on("-p", "--public", "Bind to 0.0.0.0 instead of localhost") do
    bind = "0.0.0.0"
  end

  opts.on("-q", "--quiet", "Minimize output.") do
    quiet = "-q"
  end

  opts.on("-s" "--no-substitutes", "Do not use substitutes") do
    # Helpful if there are network issues
    no_substitutes = "--no-substitutes"
  end
end.parse!

puts "Building site".red
puts site_dir = `guix time-machine -C channels.scm -- \
                      build #{no_substitutes} #{quiet} -f guix.scm`
                  .chomp + "/site"
raise "Build Failure" unless $?.success?

ip_address = Socket.ip_address_list.detect{|intf| intf.ipv4_private?}.ip_address.to_s
puts "Serving site publicly on #{ip_address}".red unless bind == "localhost"
system("guix time-machine -C channels.scm -- shell #{no_substitutes} \
              -CN --no-cwd --expose=#{site_dir}=/srv/html python --   \
              python3 -m http.server -d /srv/html --bind #{bind}")

Now I can add (compile-command . "./bin/serve -p") to .dir-locals.el, without needing to worry about direnv, syncing separate scripts and Dockerfiles, or anything else.