Mac OS Gatekeeper blocking signed command line too

Question

I have a "command line tool" target (not an App bundle) in Xcode that is being blocked by Gatekeeper. I've used this tool for years as a simple installer for my PostCheck Address Book plugin.

In 2012 I signed the tool with my Apple Developer ID so that it wouldn't be blocked by Gatekeeper and all was well for a while. I've now noticed that with macOS Sierra (10.12) that it's now being blocked, and during testing I've also found that it's blocked by 10.11.6 as well. (When I say blocked, I mean the user has to right-click on it and choose 'open' instead of being given the option in the warning dialog.) It still works fine with 10.11.2! – If I recall, Mac OS X 10.11.4 had a bug that blocked non-app bundles even if they were signed, but I think that problem was fixed in 10.11.5. Maybe it's related?

I've tried re-compiling and re-signing the executable with Xcode 8 under Sierra. I tried embedding an Info.plist in the binary (which I hadn't done before). I've tried archiving rather than just "building" in case it was an issue with debug vs. release configurations. I've spent two days searching methods for validating my executable is signed properly, seemingly with conflicting results…

There's this:

codesign --verify --verbose <executable> 
<executable>: valid on disk
<executable>: satisfies its Designated Requirement

And this:

spctl --assess --verbose <executable> 
<executable>: rejected (the code is valid but does not seem to be an app)
source=matched cdhash

And this:

spctl -a -v --raw <executable> 
<executable>: accepted
<?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>assessment:authority</key>
    <dict>
        <key>assessment:authority:flags</key>
        <integer>0</integer>
        <key>assessment:authority:source</key>
        <string>allowed cdhash</string>
        <key>assessment:authority:weak</key>
        <true/>
    </dict>
    <key>assessment:cserror</key>
    <integer>-67002</integer>
    <key>assessment:remote</key>
    <true/>
    <key>assessment:verdict</key>
    <true/>
</dict>
</plist>

I suppose part of my problem is I don't know what a command line executable is supposed to look like after being signed with a valid Apple Developer ID. And I also don't know if it's a macOS problem that I can't do anything about anyway. It's also extremely difficult to Google for both command line tools and code signing problems and find something actually related to code signing a command line Unix executable.

I appreciate any insight into what might be going on here. Thanks!

Answer 1

There is a known bug in macOS Catalina 10.15.3 and earlier (fixed in 10.15.4) wherein a notarized command line app that links against a .dylib outside of its bundle (and command line apps are typically not in a bundle) will still fail Gatekeeper checks that trigger when the quarantine** flag is set on the command line executable.

To workaround the problem, Apple DTS recommends:

The easiest workaround is to sign your tool with both the hardened runtime and library validation flags.

That is, change your invocation of codesign from this:

% codesign -s …stuff… -o runtime …stuff… helloworld

to this:

% codesign -s …stuff… -o runtime,library …stuff… helloworld

Explicitly setting the library flag disables this Gatekeeper check and allows your tool to run on macOS 10.15.{0,1,2,3}. Please make a note to remove this flag once 10.15.4 is released and widely adopted.

**The quarantine flag is set whenever you receive a file via internet download or AirDrop (but not via network File Sharing or iCloud Drive), according to https://eclecticlight.co/2019/10/24/airdrop-and-quarantine-flags/

Answer 2

I hate to answer my questions, but in case anyone comes across this same problem:

The solution is to distribute the command line tool on a signed disk image rather than in a zip file.

I ended up testing back to 10.11.4 and confirmed that's when the trouble began. (I must have been testing it improperly back then.) OS X simply blocks double-clicking a Unix Command Line Tool, no matter how I sign it. It's probably for the best as most command line tools will be run from within Terminal.app.

For Sierra, it turned out I needed the signed DMG anyway to get around the new Path Randomization feature of Gatekeeper.

Answer 3

I had the same issue when I was bundling with go-astilectron-bundler and in my case adding

<key>CFBundlePackageType</key>
<string>APPL</string>

to Info.plist file solved the problem.