pnpm.fetchDeps: ensure consistent hashes by setting file permissions after fetching

[obreitwi]

For reasons not yet completely understood, pnpm might create dependency files with inconsistent file permissions. Since file permissions influence the resulting hash, this PR attempts a workaround by ensuring consistency after the fact.

NOTE: I am unsure that this should be merged prior to understanding what causes pnpm to generate inconsistent file permissions in the first place.
Maybe this PR already helps others facing the same issue.

More details:
We tried to build a small pnpm-based application locally versus within Github actions.
Here we observed build failures due to differing hashes for pnpmDeps. After investigation of the actual derivation contents we discovered that on a local, Ubuntu 24.04.1 LTS-based laptops with multi-user nix installs, all files in the derivation either had 444 or 555, the same derivation within the ubuntu-24.04-based runner (with single user install via nix-quick-install) had 644/755 as permissions and in different quantities.
To make things even more confusing: The ubuntu-22.04 agent runner showed the same behavior as our local environment.

Detailed statistics.

environment	permission	count
Ubuntu 24.04 LTS-based laptop/ubuntu-22.04 Github actions runner	444	27511
Ubuntu 24.04 LTS-based laptop/ubuntu-22.04 Github actions runner	555	108
ubuntu-24.04 Github actions runner	444	27497
ubuntu-24.04 Github actions runner	555	122

Since file permissions are stored in the NAR-archives used to derive the hash of a fixed output derivation, this leads to inconsistencies depending on where a derivation is built.

Hence, we ensure a consistent file permission schema:

• All files with -exec suffix have 555.
• All other files have 444.
• All folders have 555.

This schema was chosen because it as already upheld in most environments we tested (i.e. local multi user installs on Ubuntu 24.04.1 LTS and single user install via nix-quick-install in ubuntu-22.04-based Github action runners).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[gepbird]

A related bug in pnpm recently got fixed in pnpm/pnpm#8625, and got released in pnpm 9.12.2 4 days ago.
This pnpm version bump recently got merged into nixpkgs, which made pnpmDeps hashes change, see #349093 (comment).

Were you using the same pnpm version on the 22.04 and 24.04 ubuntu machines? Would you mind testing it with pnpm 9.12.2?

(The merge conflict was caused by a formatting change, nothing to worry about when rebasing)

[obreitwi]

Thanks for the hint!

Were you using the same pnpm version on the 22.04 and 24.04 ubuntu machines? Would you mind testing it with pnpm 9.12.2?

Yes, we were using the same version in all cases, but it was 9.12.1.

I will check if the inconsistency still occurs with 9.12.2 and report back.

[obreitwi]

Finally got around to check: pnpm v9.12.2 does not fix the issue, making this permissions fix still necessary to ensure compatibility between Github actions and local development.

[gepbird]

@obreitwi There were many changes in pnpm 10, and since not many packages are using it yet, we can afford to change the permissions and therefore the hashes if needed. Would you mind checking whether this bug is reproducible with pnpm 10?

[obreitwi]

@gepbird Just double checked: With pnpm 10.2.1 we can still can reproduce the issue.

• Locally and in GH actions runner Ubuntu 24.04 we get different hashes for fetchDeps.
• When applying the patch GH actions can reproduce the same hash.

Unfortunately, I did not have time to investigate what causes these wrong permissions in the runner any further.

[gepbird]

Interesting that it still happens with pnpm 10.

Unfortunately, I did not have time to investigate what causes these wrong permissions in the runner any further.

That's fine, you already spent a lot of time with this problem. I suggest making these permission changes only for pnpm 10 and mentioning it in the release notes that pnpm_10 hashes will change. So far no packages in nixpkgs use this version, perhaps a few PRs. And maybe a few out-of-tree packages (like yours) are affected.