macOS ARM64 App Killed with SIGKILL - Gatekeeper Error -67062

Question

Created 6d

Replies 1

Boosts 0

Participants 2

Problem My ARM64 macOS application is being immediately killed with SIGKILL when launched. No crash report is generated, and the process terminates instantly.

Environment macOS Version: 15.x (Sequoia) Architecture: ARM64 (Apple Silicon) Certificate: Mac Developer certificate (development signing) App Type: Native ARM64 application with embedded Java runtime Symptoms ./MacOS/myapp

Immediately returns: zsh: killed ./MacOS/myapp

Investigation Results

System Logs Show Security Policy Rejection

kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 92850, /path/to/myapp syspolicyd: (Security) MacOS error: -67062

Error Code Analysis

Error -67062 = errSecCSReqFailed (Code signature requirement failed) This is a Gatekeeper enforcement issue, not a code signing problem 3. Code Signature is Valid codesign -dvvv myapp

Shows valid signature with Mac Developer certificate

Authority=Mac Developer: Name (TEAMID)

Authority=Apple Worldwide Developer Relations Certification Authority

Authority=Apple Root CA

What We Tried (That Didn't Help)

✅ Removed hardened runtime flag from Java components ✅ Added JIT entitlements (com.apple.security.cs.allow-jit) ✅ Verified Mach-O structure is correct ✅ Confirmed all libraries are ARM64 ✅ Re-signed with proper entitlements None of these fixed the issue because the problem is Gatekeeper policy enforcement.

Question How can I allow this development-signed ARM64 app to run on macOS 15 without full notarization?

I've tried:

Removing quarantine attributes Various code signing approaches Different entitlements But Gatekeeper still blocks it with error -67062. Is there a way to add a security exception for development builds, or do I need to use a Developer ID certificate even for internal testing?

Additional Context This is for internal development/testing. The app works fine when properly notarized, but we need a way to test development builds without going through the full notarization process each time.

Any suggestions would be greatly appreciated!

Boost

Answer 1

DTS Engineer OP

Apple

5d

Error -67062 = errSecCSReqFailed

This is wrong. The right values are:

Value  | Identifier        | Description
-----  | ----------        | -----------
-67062 | errSecCSUnsigned  | code object is not signed at all
-67050 | errSecCSReqFailed | code failed to satisfy specified code requirement(s)

I suspect your LLM was having a bad trip (-:

Note The easiest way to identify security errors is with the security tool:

% security error -67062
Error: 0xFFFEFA0A -67062 code object is not signed at all

do I need to use a Developer ID certificate even for internal testing?

Definitely not! For this sort of internal testing, and for day-to-day development in general, it’s much better to use Apple Development signing. It’s best to reserve Developer ID signing for distribution. I talk about this a lot more in The Care and Feeding of Developer ID.

As to what’s actually failing, it’s hard to say for sure based on what I’ve seen so far. errSecCSUnsigned is usually associated with a packaging issue. That is, your code doesn’t following the rules in Placing content in a bundle, resulting in some bits of the code being unsigned. This is particularly common for Java programs.

I have a lot of info about how to investigate problems like this in Resolving Trusted Execution Problems, but for the moment I’m going to start you off with a simple question: What does codesign -v -vvv --deep --strict /path/to/myapp.app report?

IMPORTANT Note the path I’m using here. When working with bundled code, you always want to point codesign at the root of the bundle. So, for myapp.app, point codesign at that rather than at myapp.app/Contents/MacOS/myapp.

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

0