Change:
}; }; config = mkIf cfg.enable { <del> warnings = optional (cfg.configFile != null) "services.gitlab-runner.`configFile` is deprecated, please use services.gitlab-runner.`services`."; </del> <ins> warnings = (mapAttrsToList (n: v: "services.gitlab-runner.services.${n}.`registrationConfigFile` points to a file in Nix Store. You should use quoted absolute path to prevent this.") (filterAttrs (n: v: isStorePath v.registrationConfigFile) cfg.services)) ++ optional (cfg.configFile != null) "services.gitlab-runner.`configFile` is deprecated, please use services.gitlab-runner.`services`."; </ins> environment.systemPackages = [ cfg.package ]; systemd.services.gitlab-runner = { description = "Gitlab Runner";

Discussion:
Describe the bug A file that is explicitly created to contain secrets, namely the for new gitlab runners ends up in the nix store To Reproduce Steps to reproduce the behavior: a gitlab runner with the module Expected behavior Secrets don't end up in the nix store Screenshots Contents of : Notify maintainers Metadata Maintainer information:
Could you please share your config?
Using unquoted paths will always copy them to nix store. You should use instead of
Yes, but there should be a check that this doesn't happen. It's still an information disclosure.
What if user wants them to be in nix store?
I could add a warning if is in . This will still allow doing whatever user wants to. Should I open pull-request with this change?
I think that is a good compromise.
please take a look at
I marked this as stale due to inactivity. &rarr;
I appreciate that you did something about this problem. I also get this warning for my config, which does something like this: In that case the warning is a false positive, because the registration token itself does not actually end up in the store. I think to avoid this problem the secret by itself would have to be represented in its own field as part of the service configuration so that the warning can look at that field by itself. I'm not sure if what I am doing in my config is a good way to make that happen and it's not a universal solution. Usually I would prefer my configs to not run code. Maybe this can be taken into account as part of some future work, for example if someone implements and changes registration anyways. It would be great if there was a better solution for this general problem, because even if a user sees the warning and fixes the issue the registration token is already in the store at that point and getting it back out is a pain. Right now probably not even an error would prevent it from ending up in the store.
I use sops and I've had a related issue where I can only reference the path to the token. I ended up with:
nevermind this seems to break the way the gitlab module works (my module contains 3 runners, the gitlab module creates the 3 but then remove 1 in a cyclic fashion). I will try your solution instead .

EDIT: so in fact my technique should work, I just hadn't realized that the gitlab runner is registering the runners everytime, wich is quite different from what we did before. The current approach forces to keep a registration token around which could be seen as a security flaw vs just giving a runner token. I will subscribe to