Binaries missing the "LC_VERSION_MIN_MACOSX" or "minos" keys

Am I right to say that all binaries in a notarised bundle must have the minimum OS version set ?

Yes and no. The notary service used to enforce that but IIRC that’s no longer the case. However, its absence will cause problems at runtime. For the details, see the Use of an Old macOS SDK section of Resolving Library Loading Problems.

Are these binaries compatible with notarisation nevertheless?

Yes, but not with trusted execution |-:

Is there a way to add "minos" and "sdk" keys afterwards?

Yes, but it’s not something I recommend [1]. Rather, I encourage you to investigate the build process used by your build server to find out why this load command is missing. Can you get a build transcript? If so, that should be enough to work out why things aren’t built correctly.

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

[1] The above-mentioned section has a link to another post that explains the hackaround.

Thank you very much for your help. That's extremely useful.

I encourage you to investigate the build process used by your build server

Of course yes but the "build server" is not under my responsibility and thus the vtool trick is welcome to go ahead with my project!

$ vtool -show-build myBinary      <-- the LC_BUILD_VERSION was successfully added
myBinary:
Load command 6
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform MACOS
    minos 11.0
      sdk 12.1
   ntools 0

I thought that the missing minos was the cause of the Killed: 9 error in the Terminal and EXC_BAD_ACCESS (Code Signature Invalid) in the Console. If fact the problem is with "--options runtime" wether or not com.apple.security.cs.disable-library-validation is added to the entitlements This is new to me since I used that codesign option for long for both the current project and some others.

$ codesign --remove-signature myBinary
$ ./myBinary
	<--- Okay

$ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary
$ ./myBinary
	<--- Okay

$ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --options runtime --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary
$ codesign --display --verbose myBinary
	CodeDirectory v=20500 size=13876 **flags=0x10000(runtime)** hashes=423+7 location=embedded
$ ./myBinary
**Killed: 9 **

     <-- Why ?

And this can be repeated at will. Just removing the "runtime" option makes the binary operational. What do you suggest to bypass this problem ?

Here my configuration: MacBook pro late 2013, MacOS Big Sur 11.7.2, Xcode 13.2.1 (I ordered a MacBook pro M1 but not yet received)

I will try on a more recent Intel MacOS asap.

All the best

Just removing the runtime option makes the binary operational. What do you suggest to bypass this problem?

The runtime flag enables the hardened runtime, which in turn enables a bunch of different security features. It’s hard to say which one of these is causing this specific problem. As a diagnostic step, try enabling all the hardened runtime exception entitlements and see if that gets your code to start. If so, you can selectively disable them to see which one is triggering the issue.

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

Thank you very much for your help again.

As a diagnostic step, try enabling all the hardened runtime exception entitlements and see if that gets your code to start.

And this was an excellent advice since my app is again functional. Up-to-now I successfully used the only entitlement: com.apple.security.cs.disable-library-validation I am now forced to add the following: com.apple.security.cs.allow-unsigned-executable-memory I really don't know why since the code of most of the 50 Fortran binaries in the bundle was unchanged. They were only re-compiled on the build server.

Anyway, the build server is another story and, at least, with your help, I could notarize the bundle again.

For sure, you gave me decisive help! All the best

I am now forced to add the following: com.apple.security.cs.allow-unsigned-executable-memory

That suggests that something in your process is generating code on the fly. The most common cause of this is language runtimes (like JavaScript) that JIT code. However, I’ve seen in crop up in unexpected places, like in regex libraries [1].

This entitlement shouldn’t be necessary — you should be able to get away with just com.apple.security.cs.allow-jit — but a lot of code hasn’t been updated to use MAP_JIT.

If you’d like to dig deeper into this:

1. Build a version of your app with the hardened runtime enable and without com.apple.security.cs.allow-unsigned-executable-memory.

2. Run that, reproducing the crash.

3. Grab the crash report and post it here (see Posting a Crash Report for advice on that).

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

[1] Technically a regex library is a language runtime, but most folks don’t think of it that way.

Sorry for the delay. Here the crash report from the Console when "com.apple.security.cs.allow-unsigned-executable-memory" removed.

All the best

That is a weird crash, even within the scope of weird Code Signature Invalid crashes (-:

Is there any chance you could be being hit by the issue described in Updating Mac Software? If you make a copy of basireps tool, making sure that the new file name is unique, does the copy crash?

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

We finally found why the binaries x86_64 from our Build Server missed the LC_BUILD_VERSION section.

Our server admin is a Linux expert and she configured the macOS server as she did for Linux. The offender turned out to be the packager UPX which works nicely on Linux but does strange things on macOS. UPXed binaries miss LC_BUILD_VERSION parameters, however they work nicely on Big Sur and Ventura for M1. On Ventura for Intel (and presumably on Monterey too) they crash with a "Segmentation fault 11".

Removing the UPX step in the cmake of the build server turned ou to be the solution!

View, what a fight! I finally got a working version of my app and I am very grateful for your help.