Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python3Packages.cryptography: Update Cargo hash #119640

Merged
merged 1 commit into from
Apr 30, 2021
Merged

python3Packages.cryptography: Update Cargo hash #119640

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pkgs/development/python-modules/cryptography/default.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ buildPythonPackage rec {
inherit src;
sourceRoot = "${pname}-${version}/${cargoRoot}";
name = "${pname}-${version}";
sha256 = "1wisxmq26b8ml144m2458sgcbk8jpv419j01qmffsrfy50x9i1yw";
sha256 = "1m6smky4nahwlp4hn6yzibrcxlbsw4nx162dsq48vlw8h1lgjl62";
Copy link
Contributor

@danieldk danieldk Apr 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@danieldk danieldk Apr 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

@danieldk danieldk Apr 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@danieldk danieldk Apr 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@danieldk danieldk Apr 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

};

cargoRoot = "src/rust";
Expand Down