nix: buildInputs appear to be from different nixpkgs versions

[sbellem]

Hi, I am trying to understand the Dockerfile that uses nix to verify the reproducibility of the pre-built binaries, and I noticed that the dependencies, such as:

• /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27
• /nix/store/1kl6ms8x56iyhylb2r83lq7j3jbnix7w-binutils-2.31.1
• /nix/store/lvwq3g3093injr86lm0kp0f61k5cbpay-gcc-wrapper-8.3.0

are from different nixpkgs versions. The linked derivations above lead to the Hydra server, where it's possible to see that these derivations are part of different nixpkgs versions.

Is this intended?

[lzha101]

Not quite understand your question and I don't know how you derived the links.
The packages are from nixos server. We chose one version with the specific hash. The nix-env command would install the expected packages.

[sbellem]

@lzha101 See the pull request #616 as an example of how nixpkgs can be pinned down to a version, which then makes it simpler and clearer to write a nix derivation. It appears to be a recommended practice, as per https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs.html#pinning-packages-with-urls-inside-a-nix-expression for instance.

Now, perhaps SGX has specific dependency needs that complicates pinning the nixpkgs version. For instance, if you look at the PR (#616) you'll noticed that glibc is pre-installed using /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27 in the Dockerfile as it is currently done. But all the other packages are installed from the same nixpkgs revision (https://github.com/NixOS/nixpkgs/archive/10e61bf5be57736035ec7a804cb0bf3d083bf2cf.tar.gz). There appears to be an issue with glibc and nixpkgs commit NixOS/nixpkgs@10e61bf, which is the commit from which gcc-wrapper is from as per the search on Hydra, shown above.

I am both new to nix and SGX but it seems to me that it would be preferable to use packages from a single nixpkgs revision.

[lzha101]

I may get your point now. But we will continue current Dockerfile for compatibility. And we need to use current workflow to install all the nixpkgs during building the docker image. As you know, in order to avoid some unexpected actions to break the reproducible environment, we disable network in the container. While, your changes require network in the docker container.

We will consider your suggestion when we have to break the compatibility and update the Dockerfile in future.

[sbellem]

Thanks for your reply.

Ok, I understand that the proposed approach in #616 does not preserve the reproducibility of the current builds, such as sgx_linux_x64_sdk_reproducible_2.10.100.1.bin. By keeping the nix-env install commands in the Dockerfile, the shell.nix may be modified to preserve the currently expected reproducibility ... I'll try to see if that works.

I don't think network access is required though, because when nix-shell is invoked, the buildInputs are installed, under /nix/store/. So invoking the nix-shell command has a similar effect as using nix-env -i ....

I do not fully understand why this would break the reproducibility. Currently, with the current sgx_2.10_reproducible branch, if I build the sdk, I do not get the same sha256sum as the one published at https://download.01.org/intel-sgx/sgx-linux/2.10/SHA256SUM_linux_2.10.cfg. Is one expected to be able to rebuild the sgx_linux_x64_sdk_reproducible_2.10.100.1.bin and obtain the same sha256sum?