Code-sign and notarize all binaries on macOS

[wjk]

Summary of the new feature/enhancement

Starting on macOS Catalina, all native binaries (command-line and GUI application), as well as all .pkg installer files, must be both code-signed and notarized by Apple, or the system will refuse to run them. Notarizing the .pkg file is easy, since it is already being signed. Notarizing the pwsh command-line tool, as well as the PowerShell.app wrapper application, will be harder. Note that while notarization is optional on macOS Mojave, it is still supported on that version. We do not (and, IMHO, should not) wait for Catalina's release to start work on this important change.

Proposed technical implementation details

We will need to do the following:

1. Code-sign the pwsh apphost binary with a Developer ID certificate. For notarization to succeed, we must also enable Hardened Runtime on that binary by passing the -o runtime flag to the signing tool. We must also use an entitlements file (the correct contents of which are attached at the end of this issue), or else Hardened Runtime will disallow the binary from jitting code or loading third-party dynamic libraries.
2. Code-sign all *.dylib files with the Developer ID certificate that is used to sign the apphost binary. No other special steps are required here.
3. Code-sign the *.app launcher with the same Developer ID certificate, and enable Hardened Runtime on it as well. While no entitlements are required for the launcher app, we must rewrite the launcher's main executable (which is currently a shell script) in Objective-C, as the macOS code signing process does not support applications with shell scripts as main executables.
4. Notarize all dylibs, the apphost binary, and the launcher app before including them into the installer. You can use xcrun altool and xcrun stapler to do this.
5. Notarize the *.pkg installer once it has been signed.

Note that the code-signing process is completely independent of the .NET build process, and can easily be run on a .NET CLI-generated apphost binary, as long as the apphost binary in question has been stamped with the appropriate path before it is signed. (After signing, any changes to the binary will invalidate the signature and render the file un-runnable.)

Entitlements for pwsh tool

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
</dict>
</plist>

[christian-korneck]

+1 (now that ps 7-lts is ready this would make Mac Enterprise deployments easier)

[wjk]

One quick note: I have since found that, while all exes/dylibs must be signed (and all exes must have Hardened Runtime enabled), only the final *.pkg file needs to be notarized. This is a good thing, as notarization is a long-running, asynchronous process. Having to repeat it over and over again for every file in the project would drive me nuts. (That's not even mentioning the automated email that Apple sends whenever a notarization run completes, which becomes quite annoying when I am monitoring it using an automated script!)

[TravisEz13]

This is related to #10874

I understand the requirement for the pkg to be signed and notarized.

Can someone explain the requirement for the executables to be signed? I'll need I very good explanation for this. If this involves a binary not provided by PowerShell most likely you will need to go back to that binary to get it signed.

For example

Code-sign all *.dylib files with the Developer ID certificate that is used to sign the apphost binary. No other special steps are required here.

If the binary is not from Microsoft, and several are, our policy is not not sign the binary. I'll need a good justification to get an exception to this policy.

All of these requirement make building the package long and complicated. We are having trouble getting notarization support at all.

[calebkiage]

@TravisEz13, I've recently added code signing and notarization to a .NET executable. Do you need assistance to add signing and notarization to PowerShell?

[TravisEz13]

@calebkiage Feel free to contact me on teams. I don't believe anyone outside Microsoft can do this work.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[janparttimaa]

@TravisEz13: Hi, I just noticed this conversation. Pkg-installers of Microsoft Edge, Microsoft 365 Apps (including Teams) and Defender are already notarized, stabled ans signed appropriately. Would it be possible if you or your team can co-operate with these teams that are handling these pkg-installers to get PowerShell pkg-installer issue fixed? These of your colleagues might help you: https://macadmins.software/slack.html

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.