python3Packages.cryptography: Update Cargo hash

[centromere]

Motivation for this change

The present hash seems incorrect. Some tell me this is because Rust was recently upgraded to 1.51.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[primeos]

I can confirm the hash change but I also don't know why. Two suggestions:

1. The commit message should use the attribute name (e.g. python3Packages.cryptography instead of python-cryptography - see previous history)
2. Optional: Would it be possible to add that email address to your GitHub account (not required but would be useful in general - then GH can link commits to you)

[SuperSandro2000]

I think we need to target master for this to fix cryptography.

I think we need to target master here instead of staging because the breakage is important.

[centromere]

I think we need to target master for this to fix cryptography.

I do not understand. Aren't I targeting master already?

[SuperSandro2000]

I do not understand. Aren't I targeting master already?

I updated my comment. I meant we cannot target staging here.

[danieldk]

This should not happen on a Rust update. We should figure out the source of this change, rather than just updating hashes without understanding. I will have a look.

[danieldk]

This is really odd. I can still build the cargo dependencies successfully with the old hash:

❯ nix-build -A python3Packages.cryptography.cargoDeps --check
[...]
/nix/store/fri4y3fiyadjvsyxmwn15f69rbcssm51-cryptography-3.4.7-vendor.tar.gz

However, stubbing a fake hash gives the new hash (1m6smky5...). The tarballs and unpacked tar files differ. However, the contents of the unpacked tarballs are identical, as well as ls -lR output (so, doesn't seem to be any visible metadata change).

[danieldk]

Found it, it's permissions in the tarball:

diff -u  <(tar -ztvf 1nb0hfxj4cx19nmn2cj148d9sm0bgzwy-cryptography-3.4.7-vendor.tar.gz) <(tar ztvf fri4y3fiyadjvsyxmwn15f69rbcssm51-cryptography-3.4.7-vendor.tar.gz)      
--- /proc/self/fd/11	2021-04-17 09:01:17.537248897 +0200
+++ /proc/self/fd/12	2021-04-17 09:01:17.537248897 +0200
@@ -41,11 +41,11 @@
 -rw-r--r-- 0/0            6894 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/README.md
 drwxr-xr-x 0/0               0 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/
 -rw-r--r-- 0/0             173 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/args.rs
--rw-r--r-- 0/0            6493 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/derive.rs
+-rw-rw-r-- 0/0            6493 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/derive.rs
 -rw-r--r-- 0/0           10899 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/lib.rs
 -rw-r--r-- 0/0             992 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/parse.rs
--rw-r--r-- 0/0            1357 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/variance.rs
--rw-r--r-- 0/0            1954 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/visibility.rs
+-rw-rw-r-- 0/0            1357 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/variance.rs
+-rw-rw-r-- 0/0            1954 1970-01-01 01:00 cryptography-3.4.7-vendor.tar.gz/ghost/src/visibility.rs

This should have broken a lot of other hashes as well.

[FRidh]

I've converted this to a draft for in the meanwhile

[danieldk]

I think this may be caused by: rust-lang/cargo#9131

It seems that this was fixed in 1.51:

rust-lang/cargo@75d5d8c...rust-1.51.0

So, at the very least, we should update cargoSha256s treewide. However, I wonder if we should take this opportunity to normalize permissions to avoid that this happens in the future?

[danieldk]

@centromere I am still wondering why building fails for you. Even though the hash is now invalid due to the cargo vendoring changes, it's a fixed-output derivation, so the vendor tarball with the old hash should still be retrieved from the binary cache. This happens on my machine if when build the vendor tarball with the old hash:

❯ nix-build -A python3Packages.cryptography.cargoDeps
this path will be fetched (8.64 MiB download, 8.83 MiB unpacked):
  /nix/store/fri4y3fiyadjvsyxmwn15f69rbcssm51-cryptography-3.4.7-vendor.tar.gz
copying path '/nix/store/fri4y3fiyadjvsyxmwn15f69rbcssm51-cryptography-3.4.7-vendor.tar.gz' from 'https://cache.nixos.org'...
/nix/store/fri4y3fiyadjvsyxmwn15f69rbcssm51-cryptography-3.4.7-vendor.tar.gz

[centromere]

I disabled the binary cache and was building all dependencies of an application from source.

[centromere]

@danieldk What are the next steps for this?

[danieldk]

@danieldk What are the next steps for this?

Sorry, I was completely sidetracked by teaching. I think the best solution would be to merge this PR to solve the issue for this derivation and create an issue that points the thread here to document the underlying problem. Someone should do a treewide check of cargoSha256/cargoHash to see if other derivations are affected. I currently only have access to my laptop, so I cannot easily do a tree-wide check/update.

[SuperSandro2000]

Someone should do a treewide check of cargoSha256/cargoHash to see if other derivations are affected.

This is already a quite common issue when packaging new rust programs that people get different hashes from ofborg due to using an older rust version.

[primeos]

and create an issue that points the thread here to document the underlying problem

@danieldk thanks! I've created a small issue so that this won't get lost: #121259