Apple's Certificates, Identifiers, and Profiles page says clearly "Download your certificate" and gives instructions on how to install it by double-clicking the .cer file. No clue that an export/import would be necessary. => Any terminology problems are starting real close to home.

Library validation was inadvertent, entitlements file pulled from something else. Wasn't notarized (Distracted by docs saying command line tools can't be notarized or stapled). This tool is always run from Terminal or as a service, never double-clicked. I did this: % zip -j mytool.zip .../mytool % xcrun notarytool submit mytool.zip --keychain-profile "my profile" --wait Successfully received submission info   createdDate: 2021-12-09T15:20:09.725Z   id: myid   name: mytool.zip   status: Accepted % xcrun notarytool log --keychain-profile "my profile" myid {   "logFormatVersion": 1,   "jobId": "myid",   "status": "Accepted",   "statusSummary": "Ready for distribution",   "statusCode": 0,   "archiveFilename": "mytool.zip",   "uploadDate": "2021-12-09T15:20:11.851Z",   "sha256": "9d9e6ce02881e78cb9c7a54560b18894a2b4b70716656d29573413cebba64be7",   "ticketContents": [     {       "path": "mytool.zip/mytool",       "digestAlgorithm": "SHA-256",       "cdhash": "485e2c31245e1ba4975a05f46556c2f47497be96",       "arch": "x86_64"     },     {       "path": "mytool.zip/mytool",       "digestAlgorithm": "SHA-256",       "cdhash": "156a4fc6de8e02f25e39ed2999b781ca3d88ab2f",       "arch": "arm64"     }   ],   "issues": null } (No stapling as there is none for command line tools, AFAIK.) Now I cd to a test directory and cp .../mytool . then run mytool... Killed. Same error reporting etc as originally with no notarization. This is on my same machine that it won't even run!!! (It runs fine in the original directory that is was signed in --- in the build log there is RegisterExecutionPolicyException step, not sure exactly what controls/starts that.) Checking the system log, there are entries for each mytool startup: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Exception Subtype: UNKNOWN_0x32 at 0x0000000104060000 Exception Codes: 0x0000000000000032, 0x0000000104060000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: CODESIGNING 2 But the code signing is fine: % codesign --verify --strict -vvvv --check-notarization ./mytool ./mytool: valid on disk ./mytool: satisfies its Designated Requirement This stuff just drives me INSANE. Not only are there way too many tools and hoops involved, the diagnostics just aren't acceptable. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate why Gatekeeper is unhappy (2), fix that, and then retest. "Fix that" !!!!!! No! Just no! There MUST be a way for Gatekeeper/spctl to render an exact description of whether or not it will run something (apps, command line tools, ...) on arbitrary customer machines, immediately, right away, from the development machine, bypassing any caching or anything else. How many thousands of 3rd party developer days need to be lost for one Apple developer to spend a few days to update spctl to produce 100% accurate and useful messaging? For example, the messaging out of notarytool was very good! It told me which of the half-dozen hoops I had to jump through next (keychains! app-specific passwords!). It just takes too too long to do the research to figure out what to do at all, only to be confronted with an inexplicable error. $237billion a year, and developers have to guess? Apple can do better. Sorry for the rant but it is necessary.

The cmp shows they are identical. It works in its as-compiled location only because Xcode has filed an exception for it... it wouldn't and doesn't otherwise pass Gatekeeper. The crash report here is basically the same no matter what I've done with signing, notarizing, or nothing... I think it's just showing that external Gatekeeper code is killing the process before it actually starts. I haven't removed anything from the crash report, that's all there is. crash.txt Here's what I get from codesign: % codesign -d -vvv --entitlements :- /Code/project/macOS/mytool Executable=/Users/frustrated/Code/project/macOS/mytool Identifier=com.myorg.mytool Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=10271 flags=0x10000(runtime) hashes=310+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=40b0eb4b737a4d4c2fa86558e5a07ede4c1bb907 CandidateCDHashFull sha256=40b0eb4b737a4d4c2fa86558e5a07ede4c1bb9073f041403a7ce64113f891853 Hash choices=sha256 CMSDigest=40b0eb4b737a4d4c2fa86558e5a07ede4c1bb9073f041403a7ce64113f891853 CMSDigestType=2 CDHash=40b0eb4b737a4d4c2fa86558e5a07ede4c1bb907 Signature size=8951 Authority=Developer ID Application: My Org (G00BLEDY) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 10, 2021 at 4:51:18 PM Info.plist entries=19 TeamIdentifier=G00BLEDY Runtime Version=12.0.0 Sealed Resources=none Internal requirements count=1 size=180 Warning: Specifying ':' in the path is deprecated and will not work in a future release <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.automation.apple-events</key><true/></dict></plist> Note that the embedded requirements have been fixed (needs apple-events to open things in the browser on occasion). The spctl -a -v --raw output is still the same. I've seen more transparent bricks.

OK I had a nice response here but the forum timed me out after <2 hours and routed me to an error page and killed it with no recovery. How I hate that. Synopsis: Thanks for pointing out the document and behavior. This is clearly a time-wasting gatekeeper bug. By definition, cache misses cause fetches to backing stores; gatekeeper must revalidate. The document's existence is self-incriminating. I've filed FB9807456 on it. Developers! Developers! Developers!

There's an unacknowledged kCVPixelFormatType_64RGBALE pixel type --- little-endian 64-bit, which does work without errors in VTDecompressionSessionCreate and VTDecompressionSessionDecodeFrameWithOutputHandler. Even more surprising, there's a kCVPixelFormatType_64RGBAHalf that produces half-floats.

I've just run through some analysis on this. It's all about pixel formats --- which are all over the place for ProRes and M1's. I encode from RGB, so here are the kCVPixelFormatTypes that I have working on different machines: MACHINE / 64ARGB / 64RGBALE Intel / Works / fails M1 Mac Mini (2020) / Works! / Works MacBook M1 Pro / fails! / Works From this I conclude to use 64ARGB on Intel, 64RGBALE on all Apple Silicon. It would be nice to official sign-off on that. And it would be nice to have little-endian encoding and decoding "everywhere".