recursiveGetAttrsetWithJqPrefix: fix top level values

[Prince213]

This PR allows recursiveGetAttrsetWithJqPrefix to properly handle top level value such as dictionaries, which will have a empty name and cause jq to fail, and arrays where [0] would be used instead of the correct .[0].

Example:

let
  nixpkgs = fetchTarball "https://github.com/Prince213/nixpkgs/archive/refs/heads/push-rvnmkknmmznx.tar.gz";
  pkgs = import nixpkgs { };
  utils = import "${nixpkgs}/nixos/lib/utils.nix" {
    inherit pkgs;
    inherit (pkgs) lib;
    config = null;
  };
in
pkgs.runCommand "result.json" { } ''
  ${utils.genJqSecretsReplacementSnippet {
    _secret = pkgs.writeText "secret" (
      builtins.toJSON {
        answer = 42;
      }
    );
    quote = false;
  } "result.json"}
  cp result.json "$out"
''

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[jian-lin]

The implementation looks good.

I guess the intended use case is the same as configFile, which is a bit weird to me. However, the implementation is simple and easy to understand, so I do not mind supporting that use case.

I tested it with NixOS tests for nginx-sso, glance and scrutiny.

---

I will merge this in a few days if Yinfeng has no other opinion.

[Prince213]

The idea was more about feature completeness and having less surprise. There's no documentation saying that top level secret is not supported so we should properly implement it. Also the implementation is simple enough that there isn't any reason not to support this use case.

[linyinfeng]

I think the real problem is that the original recursiveGetAttrsetWithJqPrefix is not correct.

My fix:

diff --git a/nixos/lib/utils.nix b/nixos/lib/utils.nix
index 251e0460dd03..35f5853e3f66 100644
--- a/nixos/lib/utils.nix
+++ b/nixos/lib/utils.nix
@@ -219,14 +219,14 @@ let
               let
                 escapedName = ''"${replaceStrings [ ''"'' "\\" ] [ ''\"'' "\\\\" ] name}"'';
               in
-              recurse (prefix + "." + escapedName) item.${name}
+              recurse (prefix + (if prefix == "." then "" else ".") + escapedName) item.${name}
             ) (attrNames item)
           else if isList item then
             imap0 (index: item: recurse (prefix + "[${toString index}]") item) item
           else
             [ ];
       in
-      listToAttrs (flatten (recurse "" item));
+      listToAttrs (flatten (recurse "." item));
 
     /*
       Takes an attrset and a file path and generates a bash snippet that

Some test cases that will broken under the original implementation:

1. recursiveGetAttrsetWithJqPrefix [
     {
       example = [
         {
           irrelevant = "not interesting";
         }
         {
           ignored = "ignored attr";
           relevant = {
             secret = {
               _secret = "/path/to/secret";
               quote = true;
             };
           };
         }
       ];
     }
   ] "_secret"

2. recursiveGetAttrsetWithJqPrefix {
     secret = {
       _secret = "/path/to/secret";
       quote = true;
     };
   } "_secret"

[jian-lin]

Nice catch! @linyinfeng

Also thanks @Prince213 for this PR.