`trusted-substituters` matching for nix stores don't match parameter changes for untrusted users

[sakompella]

Describe the bug

trusted-substituters matching appears to use raw string equality for untrusted users, so adding store query params (for example ?priority=10) causes a substituter to be rejected as untrusted even when the base URL is in trusted-substituters.

Steps To Reproduce

# /etc/nixos/configuration.nix
{
  nix.settings = {
    substituters = [ "https://cache.nixos.org/" ];

    # explicitly allow numtide cache base URL for untrusted users
    trusted-substituters = [ "https://cache.numtide.com" ];
    trusted-public-keys =[ "niks3.numtide.com-1:DTx8wZduET09hRmMtKdQDxNNthLQETkc/yaX7M4qK0g=" ];
    trusted-users = lib.mkForce [ "root" ];
    allowed-users = [ "*" ];
  };
}

# flake.nix
{
  nixConfig = {
    extra-substituters = [ "https://cache.numtide.com?priority=10" ];
    extra-trusted-public-keys = [ "niks3.numtide.com-1:DTx8wZduET09hRmMtKdQDxNNthLQETkc/yaX7M4qK0g=" ];
  };

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }: {
    packages.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.hello;
  };
}

Run:

nix build .#default --accept-flake-config -L
# ...
# ignoring untrusted substituter 'https://cache.numtide.com?priority=10', you are not a trusted user
# ...

Expected behavior

Matching should treat https://hostname/path and https://hostname/path?priority=... (and potentially other store options) as the same identity for trusted-substituters.

Metadata

nix-env --version
# nix-env (Nix) 2.31.3

Additional context

Ran into this attempting to use numtide/llm-agents.nix in my own nixos/nix-darwin config.
Sidenote PR #15369 would have VASTLY improved the debugging experience, hope it lands soon!

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

[xokdvium]

This isn't really a bug, because you can e.g. set ?trusted which disables signature checking. If that were allowed to be set by the client then that'd be bad (since the remote explicitly wants signature checking to be enabled). Allowing to change priority is also iffy to me tbh.

[sakompella]

Ok, ?trusted makes sense, but I see no reason ?priority does -- for the example I showed, it's a cache of a lot of expensive-to-compile programs. Notably, codex is built in rust, and has to be rebuilt for each update, of which there are frequent. There's no reason I would want to check cache.nixos.org first then cache.numtide.com for something I know is in the numtide cache, so it makes sense to me to place something like that in a nixConfig. Vice versa applies too -- I have the numtide cache set at ?priority=42, and nixos' at ?priority=40, but if a nixConfig doesn't have that (like llm-agents.nix) then I can't use it. I honestly wouldn't know how I would "resolve" that difference (for priority specifically, probably just what's in the nixConfig, but you make a good point that not every parameter makes sense to just take for an untrusted user, and parameters should be evaluate case-by-case). I'd like to point out that if it's already set as a trusted-substituter with the associated trusted-public-keys, then it's already trusted, and already would have root over my machine were it malicious, so priority in particular doesn't really matter. Regardless, it's not documented anywhere, so if that's really intended behavior then the docs should be updated to match.

[xokdvium]

Seems like there's an ancient issue too #2711

[sakompella]

Oops, my bad, didn't catch that. seems like it was targeting trusted in nix.conf -> not included in daemon. I can close this issue, but I think this one is a bit more clear than that

[sakompella]

@xokdvium is it possible for me to submit a PR as a first-time contributer to try to fix this, or given that there would have to be a few decisions made (which parameters gets stripped, which are set as different? which store types?) would that not be possible? At least in the mean time I think a docs PR is valuable