Hydra, hash and inputs

Help
1

When building a derivation on restricted mode, locally with the flag --restrict-eval, but specially on a Nix system configured to run on restricted mode such as Hydra, evaluation errors warning about access to URI ... is forbidden in restricted mode are seemingly common. Passing a hash seems to be the right way to do it, but there seems to be no way to declaring a hash for a Flake input, such as in this example. Specifically, there seems to be no such attribute for any of the types documented here. There is a reference to a narHash attribute but it seems to apply only to flakerefs not inputs, or is it safe to assume that it can be used in an input declaration too?

2 Likes
2

Actually, the attribute narHash does seem to apply to both flakerefs and inputs equally well. I found the documentation somewhat confusing since the attribute narHash is filed under the Flake reference attributes subheading and Flake references or flakerefs are described as a way to specify the location of a flake, not necessarily an input.

For future reference, for the package above that is giving an evaluation error on Hydra, the following attribute set build locally with the --restrict-eval flag:

  inputs.bearssl-src = {
    type = "git";
    url = "https://www.bearssl.org/git/BearSSL";
    narHash = "sha256-Mdkfgq8v5n1yKnSoaQBVjwF6JdT76RoZfdv44XT1ivI=";
    flake = false;
  };

I also bumped into this issue. Using nix-prefetch-git to grab the hash is not enough as it will throw a hash 'some-hash' is not SRI, it needs to be converted to SRI format beforehand with nix hash to-sri --type sha256 some-hash .

It’s also worth noting that the narHash attribute will not be recognized if the git+https URL form is given. The following will throw error: unexpected flake input attribute 'narHash':

inputs.bearssl-src = {
  url = "git+https://www.bearssl.org/git/BearSSL";
  narHash = "sha256-Mdkfgq8v5n1yKnSoaQBVjwF6JdT76RoZfdv44XT1ivI=";
  flake = false;
};
1 Like
3

Thanks for pointing out the problem. Do you have a suggestion how we could change documentation so the next person does not stumble over it again? Could you please open an issue on GitHub - NixOS/nix: Nix, the purely functional package manager describing the problem concisely, or, even better, directly make a pull request with changes that would have helped you figure out what you wanted to achieve? I will help you getting it merged.

1 Like
4

@fricklerhandwerk Thanks for the feedback! Absolutely no problem doing both. I’ll first open the issue and start working on a PR for changes in the documentation that might help other people in the future.

2 Likes
5

Added issue, waiting for discussion before proceeding with PR on the manual (as it may be a feature rather than a bug, which means adding different updates/notes).

6

I think the intention is that you’d specify rev, either as a separate attribute when using type = "git" or git+https://...?rev={the commit hash} when only using url.

Moreover I think the intention is that you either use type and specify the different parts using attributes, or only use url and specify everything inside the url.

I’m not sure about how narHash works though.

1 Like
7

@dramforever I don’t now why I never tried adding narHash inline (?narHash=), but I did it following your comment and it seems to go through without any issues. Maybe because I assumed that since ?narHash= was not documented and since ?ref= points to branch or tag name whereas ?rev=referes to a commit hash, it was only possible to add one using a separate attribute. In other words, declaring an input or flakeref either inline or through separate attributes is indeed equivalent. So, this:

  inputs.bearssl-src = {
    url = "git+https://www.bearssl.org/git/BearSSL?narHash=sha256-Mdkfgq8v5n1yKnSoaQBVjwF6JdT76RoZfdv44XT1ivI=";
    flake = false;
  };

Is equivalent to this:

inputs.bearssl-src = {
  type = "git";
  url = "https://www.bearssl.org/git/BearSSL";
  narHash = "sha256-Mdkfgq8v5n1yKnSoaQBVjwF6JdT76RoZfdv44XT1ivI=";
  flake = false;
};

It could be, however, that the use of narHash inline is underdocumented.

8

Actually, adding a SHA-256 value doesn’t solve the issue at all with Hydra throwing an evaluation error when the URI is not whitelisted in the server. There’s currently an open issue, also see this thread.

I was thrown into the wrong direction by evaluating with nix build . --restrict-eval, instead of nix flake check --restrict-eval, which is the right way to evaluate with the restrict mode flag (therefore to reproduce the evaluation error in Hydra) in the example given since the input with an exotic URL (not whitelisted by the Hydra server) is used by the attribute zphinxzerverTest in checks output, through zphinxzerver, rather than the default derivation.

It is also worth mentioning that, since builtins.fetchurl is similarly allowed to only access URI’s in allowed-uris, as explained here, adding the following declaration on the outputs attribute doesn’t lead us anywhere either (it throws the exact same error in restrict mode):

bearssl-src = builtins.fetchurl {
  url = "git+https://www.bearssl.org/git/BearSSL";
  sha256 = "1wlaymsf3y6vglcimsgvshjpl0cgal06ka3l59r7vrigmy11zn9i";
};