The dreaded "developer cannot be verified" error. Why?

Question

Created Jul ’20

Replies 5

Boosts 0

Views 1.9k

Participants 3

Hi,

(long post, sorry).

TLDR: I signed and notarized my a.out executables, shared libs, and dmg file, but still get "developer cannot be verified" error. Why?

Gory details:

I am trying to get our MacOS app signed and notarized so it can be opened without the dreaded
"app cannot be opened because the developer cannot be verified" error.

The build and testing are all done in my iMac, which is running Catalina (10.15.6).

Our app is a smalltalk database app written in C++ without any GUI components (no bundles).
All executables are command line tools in a.out format.
All executables and shared libraries are signed.
The build is done exclusively via command line tools (not using Xcode, although Xcode is installed).

Here are the build steps:

Compile and link using g++ (clang) and make. This creates an installation directory tree /Users/normg/gs353/fast42/gs/root
Enable hardened runtime and sign all a.out executables and shared libraries with:

Code Block codesign --options runtime -s "72G58AHU7P"	--entitlements /info.plist

Other resource files (text files, shell scripts, binary database data files, etc are not signed).

3. Create a disk image:

Code Block hdiutil create /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg -srcfolder /Users/normg/gs353/fast42/gs/root

4. Sign the disk image

Code Block codesign -s "72G58AHU7P" 
/Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg

5. Have the disk image notarized

Code Block xcrun altool --notarize-app \
 --primary-bundle-id "com.gemtalk.GemTalkServer" \
						 --username "norm.green@gemtalksystems.com" \
						 --password "@keychain:Developer-altool" \
						 --asc-provider "72G58AHU7P" \
						 --file "/Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg"

6. Notarization succeeds:

Code Block normg@idget>xcrun altool --notarization-info "7c78f26d-13c7-4a35-a29b-74ee66862282" --username "norm.green@gemtalksystems.com" --password "@keychain:Developer-altool"
No errors getting notarization info.
					Date: 2020-07-16 16:50:44 +0000
					Hash: 3a237b8ddf3fb412345e3c45971db135de2d23690b94995df73b84d47f367dc8
...
				Status: success
	 Status Code: 0
Status Message: Package Approved

7. staple the disk image

Code Block normg@idget>stapler staple /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg
Processing: /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg
Processing: /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg
The staple and validate action worked!

Now I download the final signed, notarized and stapled, disk image with a browser (Chrome) and extract
it to a directory. That all works. But I still get "app cannot be opened because the developer cannot be verified" error when I attempt run any a.out.

The signature is valid:

Code Block normg@idget>codesign -vvv ./vsdwishDarwin
./vsdwishDarwin: valid on disk
./vsdwishDarwin: satisfies its Designated Requirement

and the check-security routine on the a.out passes:

Code Block normg@idget>./check-signature /Users/normg/GemStone64Bit3.5.3-i386.Darwin/bin/vsdwishDarwin
(c) 2014 Apple Inc.	All rights reserved.
YES

My downloaded dmg is quarantined:

Code Block normg@idget>xattr -l "GemStone64Bit3.5.3-i386.Darwin (1).dmg"
com.apple.diskimages.fsck:
...
com.apple.quarantine: 0181;5f10870d;Chrome;AAD23815-6326-4CC8-9178-42494E58AD50

but so is the signaturecheck.dmg I downloaded from apple, and that opens without errors:

Code Block normg@idget>xattr -l signaturecheck.dmg
\com.apple.diskimages.fsck:
...
com.apple.quarantine: 0081;5f0fe0f8;Chrome;11737297-FF43-481E-B7BE-B5063943F3EA

What do I have to do to avoid the "developer cannot be verified" error?

Norm Green

Boost

Answer 1

normg OP

Jul ’20

More info: I'm seeing these 2 entries in console when the gatekeep denies the app. Any idea what this is telling me?

Code Block 
com.apple.message.domain: com.apple.security.assessment.whitelist2
com.apple.message.signature: gslist-555549445c92ec0ac81b3662ba8565553a875a6e
com.apple.message.signature2: 8bb662ddcf832a219e9cd09d016aeb7bd52e5679
com.apple.message.result: fail
com.apple.message.signature3: f0aa56bcede510089225e045db8f8c575a6ddb54
com.apple.message.reason: -67002
com.apple.message.teamid: 72G58AHU7P
SenderMachUUID: D45CB554-D139-30D8-83FC-636CC22ED7D8

Code Block assessment denied for gslist
com.apple.message.domain: com.apple.security.assessment.outcome2
com.apple.message.signature2: bundle:UNBUNDLED
com.apple.message.signature3: gslist
com.apple.message.signature5: UNKNOWN
com.apple.message.signature4: 1
com.apple.message.signature: denied:obsolete resource envelope
SenderMachUUID: D45CB554-D139-30D8-83FC-636CC22ED7D8

0

Answer 2

Etresoft OP

Jul ’20

Try adding timestamp to your options.

0

Answer 3

DTS Engineer OP

Apple

Jul ’20

Tracking down Gatekeeper problems can be quite tricky. I have some general advice on the topic but it’s far from comprehensive.

Given where you’re coming from (a whole world of UNIX-y build system stuff) my advice is that you start by doing an end-to-end test with a trivial executable. Create a “Hello [Cruel] World!” program and run it through your signing, packaging, and notarisation process. Can you get that working?

As you do this, keep Signing a Mac Product For Distribution handy because it explains each of the required steps.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

normg OP

Jul ’20

Hi Quinn,

Thanks for your comments.

my advice is that you start by doing an end-to-end test with a trivial executable.

I was working on that very thing when you replied. Turns out the info.plist must be linked directly into the a.out in order to get past gatekeeper. I found this by trial and error and it would be nice if Apple documented it somewhere.

Adding these arguments to the g++ linker line of my trivial program does that:

Code Block -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist -Xlinker </pathTo/Info.plist>

With that change, I can invoke my a.out from the command line in Terminal.app. However I still cannot invoke it by double clicking a.out in Finder. I can live with this limitation.

Next I will this all works with the complete application. I'm skeptical because our app has several shared libs but my trivial test program doesn't.

Norm Green

0

Answer 5

DTS Engineer OP

Apple

Jul ’20

Turns out the info.plist must be linked directly into the a.out in order to get past Gatekeeper.

That’s unlikely to be the root cause of the problem you were having. Rather, it’s likely that the presence of the external Info.plist was cause codesign to sign your code as a bundle, which was then triggering some failure in Gatekeeper.

It’s hard to know for sure though because, as I mentioned earlier, tracking down Gatekeeper problems is quite tricky. I think it’d be worthwhile you opening a DTS tech support incident for this overall problem. There’s a limit to how much time I can spend on DevForums issues.

However I still cannot invoke it by double clicking a.out in Finder.

This is a known bug (r. 58097824).

I'm skeptical because our app has several shared libs but my trivial test program doesn't.

That can be tricky. I have one specific recommendation here: Do not disable library validation. Doing that makes Gatekeeper extra persnickety.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0