-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Single-file: Facilitate signing on mac #3671
Comments
Here's an attempt to fixup the __LINKEDIT section to accommodate the SingleFile blob at the end of the file: https://github.com/dotnet/core-setup/compare/master...swaroop-sridhar:mac?expand=1 There are some downsides to doing this fixup:
|
Any update about when this will be fixed or available in a preview release? We want to distribute a .NET Core 3.0 (preview6) app on MacOS. Code siging is mandatory. Is there any workaround to publish a signed .NET Core MacOS application? |
@MarcWils Did you find some way to publish signed MacOS application? |
After dotnet/core-setup#8590, I have a better understanding of the file layout; I'll try out another fix for this issue to extend the __LINKEDIT section to cover the single-exe metadata. |
No I didn't. We reverted to building a native macOS app. |
The single-file bundler adds additional contents (the apps's dependencies) at the end of the host-binary. This violates the strict consistency checks performed by codesign tool in MAC. This change adjusts the MachO headers to accomodate the bytes added by the bundler. This Method is a utility to adjust the apphost MachO-header to include the bytes added by the single-file bundler at the end of the file. Fixes #7065
The MAC codesign tool places several restrictions on the layout
In order to circumvent these restrictions, I implemented a change that:
This method has certain limitations:
Here's a change that implements the fix: https://github.com/dotnet/core-setup/compare/master...swaroop-sridhar:macsign?expand=1 |
The fix is somewhat fragile in the long run, because it relies on the current behavior and checks implemented in The reliable way to generate an image is to use the native tool chain, but this involves substantial support in and beyond the .net core SDK. |
CC: @jeffschwMSFT @jkotas |
CC: @noahfalk |
ok, this is going to block distribution of the app. Not cool. |
What is my alternative to start sharing my dotnet 3.1 application with my clients? |
@richardlalancetteyoui You can distribute your app without publishing it as a single-file. The single-file-ness of apps is less important on MAC, sine MAC treats apps as folders. |
Oh that's a good point! |
I can confirm that, whenever selecting the option to create a single-file, the generated binary cannot be signed. Is this going to be fixed? |
Apple has a variety of restrictions on exactly what needs to happen for signing. Those restrictions change over time and we try to address them for various deployment models. Single-file embedding is a new deployment model that will need new work to deal with additional signing restrictions. This probably won't make .NET 5, but there are a variety of other deployment models that are signable, including the existing self-contained deployment, that will continue to work for .NET 5. Is there a particular issue that's blocking you from using self-contained deployment on macOS right now? |
Single file is much smaller to distribute, which is very helpful for desktop applications running .NET Core (which I understand is not a priority, but it would be nice). |
If the main concern is size, you can enable trimming even without enabling single file. There are some single-file specific size improvements, but AFAIK it's not huge for macOS at the moment. |
Guys. This is a make or break for my team. If this cannot be smoothed out, I might have to go for another ecosystem, and I would hate to have to give away .net core. I'm going to be using .net core to build command line art processing tools, for our designer workflow and this really needs to get addressed as I will be distributing my tools to mac, windows and maybe linux users. |
We do plan to fix this, and it's high priority for .NET 6, unfortunately we just haven't had time to fix it for 5.0. As @swaroop-sridhar mentioned, you can use a macOS app bundle to distribute a multi-file app that appears as a single file to consumers. Unfortunately, command line apps are one of the tools that do not normally use macOS bundles. Until we can fix this authoring issue, it won't be possible to create single-file command line apps on macOS. |
@richardlalancette |
Oh, this is a risky business @Meowzz95, but nonetheless a good lead. Thank you. This can't be the final solution though. |
I'm using CoreRT for command line tools on macOS. It AOT-compiles to a single binary that can be signed and notarized. CoreRT is experimental and has a bumpy future, so using it comes with some risk and you might not be able to use it with the latest .Net releases and features. But right now it's the only single-file solution I can use on macOS. |
@richardlalancette Agreed that .net team should fix this. But using |
OH I see! I didn't realise specific files could be changed. Well worth a quick research spike :) thank you. @Meowzz95 |
@richardlalancette HAHA, yes we can label specific files and whitelist them in gatekeeper, I'll show you my solution here.
This is a very straight forward solution without much consideration on skipping the Hope this helps as a workaround for people who are distributing single-file to users |
@Meowzz95 Very generous of you to share your results. Thank you! |
Related work in mono: mono/mono#17881 |
Fixed in #46558 |
Hey guys. Not sure how to solve my problem, even after @VSadov fix. I have a singleFile bundle inside another App and when I sign the whole contents of the App it always fails in the singleFile bundle binary with the mentioned error. I'm failing to understand how to fix the issue... |
This single-file was our workaround to: #46990 Everything worked well, except for the signing of the SingleFile binary/bundle. Now we have no idea on how to tackle the problem at hands. |
@Jmales - I am a bit confused. Did you have a problem signing a .NET 6.0 singlefile app? I wonder what was the SDK build number. The fix is fairly recent and it takes some time for a fix to make it from the development branch to the published installers. Maybe the fix was not there yet. |
Really looking for this. This was a pretty major roadblock for my team. |
Note that at the moment we have no plans to backport the fix to 5.0 -- are you OK with relying on a preview version or waiting for 6.0? |
Recent 6.0 and 6.0.preview1 SDK builds should contain the fix. |
I'm still on .net 5.0 here. Is the 6.0 preview SDK good enough for production apps? |
The single-file bundler adds additional contents (the apps's dependencies) at the end of the host-binary. This violates the strict consistency checks performed by codesign tool in MAC.
This work item track the effort to make the MAC bundle amenable to signing.
Original issue
dotnet/core#2811
Repro stesps
You will get error message: main executable failed strict validation
If you add --no-strict option in codesign, you will get more detailed error messages:
The text was updated successfully, but these errors were encountered: