Ma27
commented
4 months ago @RaitoBezarius is binary_cache_secret_key_file actually used in nixos-org-configurations? I thought the signing is done via store_uri with a path to a secret-key? At least that's what I'm doing and I just serve the binary cache directory with nginx.
Nonetheless, I agree with this: I was kinda surprised when I learned about that behavior while updating Perl bindings and to me it seems like a feature that's not relevant anymore with store_uri=scheme://foo?secret-key=/etc/secret being a thing. This has its own shortcomings that warrant its replacement, but I think it's way better than the approach implemented in NARInfo.pm.
That being said, hydra-queue-runner claims that binary_cache_secret_key_file gets ignored (the code in NARInfo.pm doesn't look like it though), so I'm not sure if there are many users left.
cc @Ericson2314 @dasJ
Is your feature request related to a problem? Please describe.
Currently, when rendering a NAR via
NARInfo.pm, Hydra will sign autonomously the path by using Nix Perl bindings. This feature is undesirable because it creates a tightly coupling to the secret key inside of Hydra and prevent from using more advanced way of signing like remote signing in https://github.com/NixOS/nix/pull/9076.Describe the solution you'd like
It seems better to me to move this to Nix and remove this feature whatsover.
Describe alternatives you've considered
Implementing remote signing in the Nix perl bindings and creating a general but fallible signer function attached on abstract stores.