-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Codesigning on macOS 11 on Apple Silicon #9082
Comments
I don't see the benefit for codesigning on platforms that don't check for signatures. I can see the costs: we're increasing processing time, and increasing risk of breakage. I would add another question:
And to that, I would answer yes, because that bug has been around for some time and is currently making our life (well, my life at least!) harder in testing and preparing for the ARM Big Sur release. So I'd say let's implement the workaround, provided it's clearly marked as such as can be easily removed in the future. In summary, my opinion is that for now a limited intervention based on our needs would be to follow the approach you proposed in #9082, but limited to ARM, and with an extra workaround in |
Agreed 👍🏻
We've been told that apparently there is a slight performance bonus from platforms with Gatekeeper from not code-signing hence why we considered doing it globally.
Ideally, yes 👍🏻 |
I agree this should be the approach we focus on. To my understanding, it should then be not a problem to make codesign failures fatal. |
Should code-sign eventually not be adhoc-only, should the solution architecture consider this now? |
My word! Is this bug tracked elsewhere? I'm pretty sure I've been seeing it non stop outside of brew: Why does my native arm64 application built using an x86_64 build system report “killed” when executed on Apple Silicon? It looks like copying and signing works...ish:
You'll note that I've gotten up to
|
This:
is the error we're seeing. If this occurs, you need to change that file's inode (so copying it someplace and back will work). Once you've done that, you can sign and it will work. |
I'd like to subscribe to the relevant issue to avoid further cluttering up this issue. |
@shepmaster we don't really have an issue for it, but you can check the code we're using to work around this: #9102 |
@fxcoudert testing this myself, is this only occurring when using x86 compiler targeting ARM through Rosetta2? If so this is an apple bug, how long you seeing this for? |
@johnalanwoods we're seeing this the native ARM Xcode toolchain (which is what we've been testing most), this is an Apple bug, they are aware |
This is my case, and it appears to be 100% reproducible in this setup.
I don't have any Apple contacts and I've only heard bad things about trying to use Radar. If you have someone on the inside that you talk with, I'd deeply appreciate it if you'd forward this particular wrinkle as part of the existing issue. ❤️ |
This specific bug is known. But I would still suggest filing bugs with the Feedback Assistant (the new name of the radar) |
@fxcoudert sounds like it's around a while! (Unfortunately) |
We've implemented the solution discussed here in #9102 |
Executables, once tampered with, need to be resigned on BigSur (arm64) Ideally, it should be as simple as, $ codesign --sign - --force --preserve-metadata=<...properties> /path/to/binary However, due to bug in the tool, codesign, the following error is thrown. ``` the codesign_allocate helper tool cannot be found or used ``` (not sure where this is tracked. Ref: Homebrew/brew#9082 (comment)) To workaround this, interim fix suggested by Homebrew team is to copy the binary to a different folder, and mv it back destroying the original file's inode.
Executables, once tampered with, need to be resigned on BigSur (arm64) Ideally, it should be as simple as, $ codesign --sign - --force --preserve-metadata=<...properties> /path/to/binary However, due to bug in the tool, codesign, the following error is thrown. ``` the codesign_allocate helper tool cannot be found or used ``` (not sure where this is tracked. Ref: Homebrew/brew#9082 (comment)) To workaround this, interim fix suggested by Homebrew team is to copy the binary to a different folder, and mv it back destroying the original file's inode.
Executables, once tampered with, need to be resigned on BigSur (arm64) Ideally, it should be as simple as, $ codesign --sign - --force --preserve-metadata=<...properties> /path/to/binary However, due to bug in the tool, codesign, the following error is thrown. ``` the codesign_allocate helper tool cannot be found or used ``` (not sure where this is tracked. Ref: Homebrew/brew#9082 (comment)) To workaround this, interim fix suggested by Homebrew team is to copy the binary to a different folder, and mv it back destroying the original file's inode.
* Unit testing setup (with test for getMachOBins) * Cleanup print_endlines * Explain the codesigning process Executables, once tampered with, need to be resigned on BigSur (arm64) Ideally, it should be as simple as, $ codesign --sign - --force --preserve-metadata=<...properties> /path/to/binary However, due to bug in the tool, codesign, the following error is thrown. ``` the codesign_allocate helper tool cannot be found or used ``` (not sure where this is tracked. Ref: Homebrew/brew#9082 (comment)) To workaround this, interim fix suggested by Homebrew team is to copy the binary to a different folder, and mv it back destroying the original file's inode. * fmt
Feature suggestion
A detailed description of the proposed feature
On macOS 11 on Apple Silicon, codesigning will be mandatory for binaries to run. This applies to both executables and dylibs. An ad-hoc signature is sufficient, and the linker will automatically apply one when a binary is created. However, our tooling (such as ruby-macho) will break existing code signatures and it's necessary to reapply a signature in order to ensure it will continue to run properly.
I've opened a PR in #9040 to automatically apply code signatures whenever we alter a binary using ruby-macho. Failures in that code signature process are currently ignored. A few details we need to discuss here:
codesign
utility.The motivation for the feature
This is needed to future-proof Homebrew.
How the feature would be relevant to at least 90% of Homebrew users
Code signatures are necessary to run code. 100% of Homebrew users, eventually, will need this.
What alternatives to the feature have been considered
There are no alternatives.
The text was updated successfully, but these errors were encountered: