NixOS package and module

[Tomaszal]

First for some context - in the past few days I went on a research spree trying to simplify my YubiKey encryption/signing/authentication setup (again). I tried FIDO2 resident SSH keys, GPG agent with SSH support, SSH agent with PIV keys through PKCS#11, yubikey-agent and pivy. In the end I think that this project still has the nicest UX for SSH keys (which can be used for both encryption and signing), and if #134 is addressed, it could be the best UX for YubiKey cryptography in general. Yet it seems to be criminally underrated, which I imagine doesn't help with motivation or contributions.

I've been using this project in a NixOS configuration for over a year now and I think making it generally available as part of the project could make it more attractive to others (though I do realise I'm talking about a niche within a niche within a niche...). Anyway, I suggest adding a flake to this repo which would output a package, an overlay, a NixOS module, and a home manager module. I volunteer to contribute this if you think it's a good idea.

[smlx]

Hmm. I wonder if this repository is the best place to do packaging.

I have no experience with NixOS, but on Debian at least packaging is generally done in a separate repository containing only packaging stuff?

[Tomaszal]

Nix/NixOS in general are quite different compared to the traditional Linux package managers and distributions, and although they do have a central repository for packaging, they also have a somewhat new concept of Flakes, which supports/encourages decentralized distribution through git. You can think of a Flake as a universal language-agnostic package.json & package.lock in JS (or I guess go.mod & go.sum in Go, though I'm not sure if that's a great analogy as I'm not very familiar with it). The relevant bit here is that a package for piv-agent can be defined in a way that can be easily consumed by any Nix compatible OS, which basically means Linux, macOS, and technically Windows through WSL, though I'm not sure how useful/usable piv-agent would be there. In addition to packaging, NixOS also has a module system, which lets users easily integrate things into their system with a simple config, which together with home-manager could look something akin to this:

{inputs, ...}: {
  imports = [inputs.piv-agent.homeManagerModules.default];
  piv-agent = {
    touchNotifyDelay = "100ms";
    idleTimeout = "30m";
    agent.ssh = true;
  };
}

The module would then handle all of the setup itself. Home manager is not limited to NixOS, which means this would be a viable installation strategy for any distro. Theoretically it would even be possible to make it work on macOS too with launchd, though I don't have a Mac to test that out with.

While it's definitely possible to do all of this in a traditional centralized way, a lot of maintainers are now choosing to add Flakes to their repos, as they're relatively simple and it makes the package + configuration instantly widely available, without having to deal with large centralised entities. This approach is not mutually exclusive to the centralized one, so it would be possible to add it to the central repositories later too for convenience. You can check out how Hyprland handles this as an example.

The main concern I can think of is the integration with CI/CD and dependabot. It should be quite simple to add a workflow that updates flake.lock once in a while. In addition to that, when updating Go dependencies, vendorHash (basically a Nix hash of Go dependencies for reproducibility reasons) will need to be somehow updated in the Flake. I've not worked much with dependabot before, but I think it should be possible to run a simple script in CI of the bump branches that handle that part.

The other thing to keep in mind is if/when you add options to piv-agent serve, it would be ideal to also add them into the module provided by the Flake. I understand the concern of having one more thing to maintain, but I'd be happy help with that if/when necessary. Apart from that there shouldn't be much extra maintenance needed.