-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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.
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
git immediately dies on aarch64-darwin #208951
Comments
Works for me: $ nix run github:nixos/nixpkgs/master#git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
$ nix run nixpkgs#nix-info -- -m
- system: `"aarch64-darwin"`
- host os: `Darwin 21.6.0, macOS 12.5.1`
- multi-user?: `yes`
- sandbox: `no`
- version: `nix-env (Nix) 2.12.0`
- channels(kubukoz): `"nixpkgs"`
- channels(root): `"nixpkgs"`
- nixpkgs: `/Users/kubukoz/.nix-defexpr/channels/nixpkgs` |
Works for me as well: nix shell github:nixos/nixpkgs/master#git
git status
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
nix run nixpkgs#nix-info -- -m
- system: `"aarch64-darwin"`
- host os: `Darwin 21.6.0, macOS 12.6.2`
- multi-user?: `yes`
- sandbox: `relaxed`
- version: `nix-env (Nix) 2.11.0`
- channels(tricktron): `"darwin"`
- channels(root): `"nixpkgs"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs` I am using bash though instead of zsh. |
What git rev did your nix shell pick up? This will end up different on anyone who tests this later than you, making reproducing more complicated. With rev a2d2f70 (where my |
With rev f289c49 I'm unable to reproduce either.
|
I see various reports of this happening randomly to people in 10.15.4 and a few mentions of other versions with completely random apps. This may not be a nix issue specifically, but rather some mac weirdness. Does that happen on any other apps, or just git? |
@viraptor I've only noticed it with git, but that doesn't necessarily rule out it happening elsewhere. |
I've been seeing this for a while. Eg, current
Metadata:
According to
In case relevant,
and
|
Cannot reproduce on my end right now either - git command runs fine. Metadata (same, except last modified):
Code signature:
System info:
nix-info:
|
I have not seen this issue again since i first reported it - at some point I forgot that I was running a pinned rev, and updated with no problems. I think @viraptor is right, in that it is somewhat random and it is mac weirdness. @kamalmarhubi if you force nix to build from source ( |
After forcing a rebuild this time:
|
@Sciencentistguy that command reports:
The binary at that store path works and codesign is happy with it:
I don't know if the binary at that path is the downloaded artifact or the locally built one, so I reran the command with
Checking those two store paths' git binaries:
and the
I think this means the downloaded artifact is fine but the locally built one isn't? Aside: I'm not where my
I ran what I think is the flake equivalent command at the current
But in this case, both outputs' git binaries are SIGKILLed:
Looking slightly closer, the (presumably?) downloaded one is unsigned (different from above), and the locally built one has an invalid signature (similar to above):
Not sure what to make of this? At some point artifacts in cache.nixos.org stopped being signed? Why are my local builds producing binaries with invalid signatures? I don't know anything about how substitution works, so I can't figure out how to fetch the built artifact for an arbitrary |
A bisect may be useful, but I'm not certain it will tell us much - last time, it just came up with a rev that didn't touch Testing on my machine (2021 M1 Max MBP) with rev 2c09e8e gives the following: The downloaded (substituted) binary works, and is signed:
The locally built binary does not match - nix complains about determinism
and is killed my macos and fails codesign:
Interestingly, I can't even strip the signature
|
@Sciencentistguy that's unfortunate about the previous bisect. Do you know how I can force my system to get an artifact from cache.nixos.org? I'm still curious to know if there are situations where the cached artifact has an invalid or missing signature. |
See also: LnL7/nix-darwin#693 (in particular LnL7/nix-darwin#693 (comment), LnL7/nix-darwin#693 (comment)). This may be related to store optimization? |
I don't know if this is a bug with the Nixpkgs Git package. It seems to involve a derivation getting somehow replaced with one that is almost identical but subtly broken, perhaps a Nix bug involving substituters or store optimization (which is quite broken on macOS in general). I don't know where the broken "shadow derivation" is coming from, especially since we don't know its derivation hash, but at least in the case of the issue I linked it was fixed by repairing the store path. |
This is cropping up again for me, btw. The workaround of forcing it to rebuild still works. @emilazy i don't seem to be able to run
EDIT: running |
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will update ad hoc signatures after they perform their modifications. The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful. In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature. It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one. Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin. Fixes NixOS#208951.
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will update ad hoc signatures after they perform their modifications. The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful. In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature. It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one. Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin. Fixes NixOS#208951.
Sorry about the commit message spam. I believe this will be fixed by the ld64 upgrade in #307880. As part of the upgrade, the post-link signing hook is being dropped. ld64 will automatically handle code-signing, and cctools will automatically preserve linker-generated signatures (which ld64 creates). |
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will update ad hoc signatures after they perform their modifications. The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful. In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature. It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one. Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin. Fixes NixOS#208951.
Describe the bug
Running
git
from nixpkgs masternix shell github:nixos/nixpkgs/master#git
fails (it is sent signal 9 by the OS)This appears to be a codesigning issue: (from the system log)
Forcing nix to build git locally solves the problem:
nix-shell --pure --run "git"
withdefault.nix
:Steps To Reproduce
Steps to reproduce the behavior:
zsh: killed git
Expected behavior
git should work
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers
@NixOS/darwin-maintainers
@primeos
@wmertens
@globin
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.The text was updated successfully, but these errors were encountered: