Code signing for macOS release

[rgov]

The NSA has had public-key cryptography capabilities since the 1960s. It would be neat if this could be applied to sign the macOS releases of Ghidra so that Gatekeeper does not interfere with using it.

I don't know how Gatekeeper plays with Java code signing. This problem may be exacerbated by installing with brew cask (--no-quarantine may be a workaround for that).

[ryanmkurtz]

Relates to #621

[SunnyJames]

So.. it has been nearly a year since this has been needed. I've recently taken on the task of creating an app bundle for Ghidra for MacOS to simplify installation without requiring separate JDK install. However, the lack of signing and malware vetting for all of the internal packages of Ghidra or of the JDK has made creating a signed and verified app bundle seemingly impossible.

Could the Gatekeeper issues please be addressed?

See the below for a couple of attempts at wrapping Ghidra and the jdk with a compiled AppleScript to easily launch it.

https://gist.github.com/yifanlu/e9965cdb148b550335e57899f790cad2

https://github.com/stevecheckoway/ghidra_app

I'm also happy to share my own attempts at using Apple notarization service to notarize the binary releases.

[ryanmkurtz]

Does the Gatekeeper issue only apply to macOS "applications?" I've never had any Gatekeeper issues running a Ghidra release or dev build on any version of macOS.

[SunnyJames]

Yes, GateKeeper is MacOS validation service which includes verification of digital signatures of binaries as well as a notarization service where binaries are signed by Apple as having been scanned for malware.

While it is still possible to run Ghidra by manually authorizing the system to run the program, it isn't a best practice and is disabled by policy controls on many systems.

[ryanmkurtz]

I've never had to manually authorize Ghidra, and my Gatekeeper settings have always been "App Store and identified developers." Are our configurations different?

[DashLt]

Almost certainly, had to manually right-click -> open the decompile binary to stop Gatekeeper from yelling at me during analysis of a binary.

[dkontyko]

I'm also experiencing this situation, running macOS 11.1 (build 20C59). My GUI Gatekeeper setting is also "App Store and identified developers."

Excerpts from Gatekeeper:

% spctl --status
assessments enabled
% spctl --list
[snip]
5419[UNLABELED] P0 allow execute [/usr/local/Caskroom/ghidra/9.2,20201113/ghidra_9.2_PUBLIC/Ghidra/Features/Decompiler/os/osx64/decompile] cdhash H"385051bc30cdef532cfd14c777171a31de95aefe"

In addition to decompile, the GnuDemangler jar also prompts me about this when it tries to run from within Ghidra. There's no way to allow it when Ghidra triggers the prompt; I must dig into the folders, find the executable, and manually run it.

Having spctl enabled is also a STIG setting for macOS, and the STIG also recommends that critical software be signed.

[kode54]

I cannot even get it to disassemble anything on macOS 11.5.1.

[ryanmkurtz]

You are not getting the option to "Open Anyway" in the Security & Privacy settings?

[ryanmkurtz]

I just did some testing on macOS 11.5.1. The first time the decompiler tried to run I got a popup forcing me to choose between "Move to Trash" and "Cancel". I went over to "Security & Privacy" and it wasn't aware of the problem yet. When I clicked "Cancel", the decompiler appeared in "Security & Privacy" and I was able to click "Open Anyway". Same process with the demangler. Things worked fine after I did that once.

Definitely not a good user experience but it ultimately worked.

[ryanmkurtz]

We have no plans to sign our executables. Instead, the route we decided to go is to allow the user to rebuild the native binaries from a ghidra release, which is described in #3387. This will be available in the 10.1 release. If you rebuild the native binaries when you download the release, you will not run into any Gatekeeper issues.

[rgov]

Homebrew, a popular macOS packaging system, is discussing the removal of the Ghidra formula due to the lack of code signature. Over 9,000 users installed Ghidra this way on their Macs in the past year.

[ryanmkurtz]

Thanks for the heads up. While we don't officially support any 3rd party packaging systems, we are aware of the poor user experience not having them signed is causing, even with our own official distribution.

If we cannot sign them, we will likely stop distributing the macOS native components, relying instead on the user running support/buildNatives before using Ghidra for the first time. No decisions have been made yet though.