• change the tooling
• adapt check phase & execute checks before the build phase
• especially run the fmt check first to avoid building everything (twice) only to fail the build on format checks

closes #61

error: builder for '/nix/store/kjzpnhknd26670201m9lvbwzhxxrwhkg-decrypt-with-age.drv' failed with exit code 101;
       last 2 log lines:
       > thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotWellFormed', /private/tmp/nix-build-rage-0.7.0.drv-0/rage-0.7.0-vendor.tar.gz/locale_config/src/macos.rs:16:76
       > note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
       For full logs, run 'nix log /nix/store/kjzpnhknd26670201m9lvbwzhxxrwhkg-decrypt-with-age.drv'.
error: build of '/nix/store/4574nc3jkm74pmbld8akw8b8kx5hvhd3-check-agenix-symlink.drv', '/nix/store/8fb3b4yyc71h403i421njbb9ng16d7p8-emit-schema.drv', '/nix/store/dl0mqvayp04jhggi7z4y14l33m62mbw4-check-shell-completions.drv', '/nix/store/kjzpnhknd26670201m9lvbwzhxxrwhkg-decrypt-with-age.drv' failed

This problem is this call in locale_config, which rage depends on for localizations. rage works in every other context but this check on my machine.

Refactor the code to allow building without recursive-nix:

• The Rust integration tests which require recursive-nix are guarded by a feature flag which is enabled by default (to still run them by just executing cargo test).
• nix build disables the recursive-nix feature flag. This allows using ragenix without a system with recursive-nix support. nix flake check will build ragenix (again) and run all tests.
• Building and checking are two separate CI workflows now. The former uses a Nix without recursive-nix while the latter uses a Nix installation with the recursive-nix feature enabled. Only the check workflow requires recursive-nix.
• macOS fails to run the recursive-nix checks. I'm not sure what's the reason but it is probably an upstream bug. Therefore, I moved the respective checks to the Linux check outputs. We can revert the commit as soon as this is addressed.

Fixes #65

In the README we get the impression that the recursive-nix feature is only needed if we want to contribute but for me, simply putting ragenix as an input in my flake.nix and having it as a command in my devshell gives me:

error: a 'x86_64-linux' with features {recursive-nix} is required to build '/nix/store/dn03sf91527lndd0mj6s35qsd6v38a3b-ragenix.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

Is recursive-nix needed to just use ragenix? In that case maybe it should be listed as a dependency or something.

For testing the agenix NixOS module, use QEMU 6.0.0 until upstream fixes a bug which causes QEMU 6.1.0 to hang indefinitely, at least for virtualized hosts.

Closes #35

naersk has a track record of pulling in it's own nixpkgs and any follows constellations continuously cause problems (due to long lasting bugs in nix's follows implementation). This is why many repositories start switching to 21.11 upstream rust machinery (which can consume Cargo.lock files).

Piling up uncontrolled nixpkgs versions in flake lock files is not necessarily bad, per se, but it makes it increasingly hard for an operator to manage & audit this core dependency for about everything.

If my sentiment is mirrored I'd be happy to prepare a PR with a switch.

Resolved URL: git+file:///home/runner/work/ragenix/ragenix?shallow=1
Locked URL: git+file:///home/runner/work/ragenix/ragenix?ref=main&rev=36679efd2f4818035e2d7db900db0f3010e6fb3c&shallow=1
Description: A rust drop-in replacement for agenix
Path: /nix/store/6ilzzimnv33lqqldp9nna6ihsvb731i0-source
Revision: 36679efd2f4818035e2d7db900db0f3010e6fb3c
Last modified: 2021-12-05 02:38:46
Inputs:
├───agenix: github:ryantm/agenix/52ea2f8c3231cc2b5302fa28c63588aacb77ea29
│ └───nixpkgs follows input 'nixpkgs'
├───flake-utils: github:numtide/flake-utils/74f7e4319258e287b0f9cb95426c9853b282730b
├───naersk: github:nix-community/naersk/c3e56b8a4ffb6d906cdfcfee034581f9a8ece571
│ └───nixpkgs follows input 'nixpkgs'
├───nixpkgs: github:nixos/nixpkgs/6daa4a5c045d40e6eae60a3b6e427e8700f1c07f
├───nixpkgs-nixos-test: github:nixos/nixpkgs/e1fc1a80a071c90ab65fb6eafae5520579163783
└───rust-overlay: github:oxalica/rust-overlay/88ce9c458d9e4dedfd9eed85a3fe818730a2fac5
 ├───flake-utils follows input 'flake-utils'
 └───nixpkgs follows input 'nixpkgs'

In an effort to reduce the build times, use a public binary cache from cachix.

I've created the binary cache through @wurzelpfropf with the name wurzelpfropf and added an auth token as a secret with write access as CACHIX_AUTH_TOKEN_PUBLIC on the organization level.

Upstream naersk now has support for

• aarch64-darwin: https://github.com/nix-community/naersk/pull/182
• Stable Rust channel: https://github.com/nix-community/naersk/pull/191

That means, we no longer have to use our fork.

Updated Flake dependencies through nix flake update.

Resolved URL:  git+file:///home/runner/work/ragenix/ragenix?shallow=1
Locked URL:    git+file:///home/runner/work/ragenix/ragenix?ref=refs%2fheads%2fmain&rev=bb31b2b70dfca44f08b0b7775b0702d7a9155885&shallow=1
Description:   A rust drop-in replacement for agenix
Path:          /nix/store/248zb3nybzj96fd52fva4rkdz29vf1jz-source
Revision:      bb31b2b70dfca44f08b0b7775b0702d7a9155885
Last modified: 2023-01-01 02:29:46
Inputs:
├───agenix: github:ryantm/agenix/a630400067c6d03c9b3e0455347dc8559db14288
│   └───nixpkgs follows input 'nixpkgs'
├───flake-utils: github:numtide/flake-utils/5aed5285a952e0b949eb3ba02c12fa4fcfef535f
├───nixpkgs: github:nixos/nixpkgs/677ed08a50931e38382dbef01cba08a8f7eac8f6
└───rust-overlay: github:oxalica/rust-overlay/176b6fd3dd3d7cea8d22ab1131364a050228d94c
    ├───flake-utils follows input 'flake-utils'
    └───nixpkgs follows input 'nixpkgs'

Updated Cargo dependencies through cargo update.

Dependency status of main prior to this PR:

Updated Flake dependencies through nix flake update.

Resolved URL:  git+file:///home/runner/work/ragenix/ragenix?shallow=1
Locked URL:    git+file:///home/runner/work/ragenix/ragenix?ref=refs%2fheads%2fmain&rev=468ba936f9205e5ed7bf4321dc2adaa09d9632c1&shallow=1
Description:   A rust drop-in replacement for agenix
Path:          /nix/store/vmpczdl8js7b76xnmx0zcgp7gj4a9816-source
Revision:      468ba936f9205e5ed7bf4321dc2adaa09d9632c1
Last modified: 2022-12-25 02:21:52
Inputs:
├───agenix: github:ryantm/agenix/a630400067c6d03c9b3e0455347dc8559db14288
│   └───nixpkgs follows input 'nixpkgs'
├───flake-utils: github:numtide/flake-utils/5aed5285a952e0b949eb3ba02c12fa4fcfef535f
├───nixpkgs: github:nixos/nixpkgs/652e92b8064949a11bc193b90b74cb727f2a1405
└───rust-overlay: github:oxalica/rust-overlay/631e692192eeeea85cdfb2a9dccbbfce543478b1
    ├───flake-utils follows input 'flake-utils'
    └───nixpkgs follows input 'nixpkgs'

Updated Cargo dependencies through cargo update.

Dependency status of main prior to this PR:

When I try to edit the file a12l_password.age I get an error message

$ ragenix -e a12l_password.age
error: secrets rules are invalid: './secrets.nix'
Failed to read ./secrets.nix as JSON

My expected result is that my $EDITOR starts with the decrypted file in a buffer.

This is my secrets.nix file:

let
  a12l = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9yYBrcu2A7N5S93yOgK7J9wNcMUWMN2va2cd7srZ6m";
  users = [a12l];
  p-desktop1 = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK1YN6HPXhnwhxr/qzvIstjLP70h+EXJ95/Ilsrl9W/0";
  systems = [p-desktop1];
in {"a12l_password.age".publicKeys = [a12l p-desktop1];}

I've looked at

$ ragenix --schema
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "Agenix secrets rules schema",
  "type": "object",
  "properties": {},
  "additionalProperties": {
    "type": "object",
    "description": "An age-encrypted file",
    "required": [
      "publicKeys"
    ],
    "properties": {
      "publicKeys": {
        "type": "array",
        "minItems": 1,
        "items": {
          "type": "string",
          "description": "An age-compatible recipient, e.g., an ed25519 SSH public key"
        },
        "uniqueItems": true
      }
    }
  }
}

but I don't know when the schema is checked in the evaluation process.

• Tooling: change from naersk to nixpkgs+fenix
• Tooling: avoid double building between codeStyleConformanceCheck & cargoCheckHook
• Feature: add first implementation of secrets generate script

Just an idea I wanted to propose:

Would it be possible to support reading rules from another flake's output instead of a separate secrets.nix file? E.g. If I have a flake defining my systems like this:

{
  outputs = { self, nixpkgs }: {

    nixosConfigurations = {
      system1 = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ({ pkgs, ... }:
            {
              # Config ...
              age.option-to-set-key = "ssh-ed25519 AAAAAAA...";
              age.secrets.secret1.file = ./secrets/secret1.age;
              age.secrets.secret2.file = ./secrets/secret2.age;
            })
        ];
      };

      system2 = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ({ pkgs, ... }:
            {
              # Config
              age.option-to-set-key = "ssh-ed25519 AAAABBB...";
              age.secrets.secret2.file = ./secrets/secret2.age;
            })
        ];
      };
    };
  };
}

nixosConfigurations could be used directly resulting in a rule set equivalent to:

let
  system1 = "ssh-ed25519 AAAAAAA..";
  system2 = "ssh-ed25519 AAAABBB..";
in
{
  "secret1.age".publicKeys = [ system1 ];
  "secret2.age".publicKeys = [ system1 system2];
}

Since you only plan on supporting flakes it seems like an extra step to have to write a secrets.nix file, as the information is already present in an organized form. The --rules flag of ragenix could be expanded do accept a flake path or an additional flag (e.g. --flake) implemented the same way as other tools like nixos-rebuild have.

I might have not considered something, let me know what you think or if this is a bad idea. This could even serve as an alternative for #48, as there would no longer be a reason to have globs since you don't need to define the rules at all.

I'm wondering how to organise my secrets without specifying every single one of them explicitly Is there some mechanism of how to specify glob patterns or regex's in the secrets.nix file?

It would be nice to be able to specify something like this:

let
  host1 = "ssh-ed25519 AAAAC3...";
  host2 = "ssh-ed25519 AAAAC3...";
  backup-admin = "ssh-ed25519 AAAAC3...";
in
{
  "hosts/host1/*".publicKeys = [ system1 ];
  "hosts/host2/*".publicKeys = [ system2 ];
  "hosts/*/backup-key".publicKeys = [ backup-admin ];
}

In this example every host should be able to access anything in his directory and the backup-admin should additionally be able to access the backup-keys for all hosts (but not the other files of all hosts).

└── hosts
   ├── host1
   │  ├── backup-key   # Readable by 'host1' and 'backup-admin'
   │  └── ssh-key      # Readable by 'host1'
   └── host2
      ├── backup-key   # Readable by 'host2' and 'backup-admin'
      └── ssh-key      # Readable by 'host2'

Is this possible?