Different team ID issue with code sign

Question

neel5481 OP

Created Feb ’20

Replies 2

Boosts 0

Views 3.6k

Participants 2

I am using Mac 10.15.1.

I have installed PostgreSQL database which is signed by its certificate. User can extend the postgresql database by writing the extension so I have written the extension and created ".so" file which is signed by my certificates. I have used below com mand to sign the library file.

codesign --verbose --verify --deep -f -s '<My_Apple_ID>' --options runtime My_library.so

After loading this new library with installed postgresql database, it gives error of "different Team IDs" as below.

code signature in (My_library.so) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs

As in my Certificate Team ID is different and installed product have their own team ID.

So how can we resolve this issue ?

Boost

Answer 1

alain_grenoble OP

Apr ’20

I am using 10.14.5 since my Catalina is quarantined at work.

My application is X11 based and Xquartz 2.7.11 is installed.

The application was successfully notarized and stapled using Xcode and the option "Disable library validation" checked.

I also tried the command line approach with codesign, altool and xcrun stapler.

Whatever I do the application fails with error:

/opt/X11/lib/libXinerama.1.dylib: code signature in (/opt/X11/lib/libXinerama.1.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs

Yes the Team IDs are different:

myApplication --> TeamIdentifier=P65398CN49

libXinerama.1.dylib --> TeamIdentifier=NA574AWV7E

but the hardening option "Disable library validation" being checked I do not understand that error message.

Clearly, this key does not work as described by Apple (see below).

com.apple.security.cs.disable-library-validation

Typically, the Hardened Runtime’s library validation prevents an app from loading frameworks, plug-ins, or libraries unless they’re either signed by Apple or signed with the same team ID as the app. The macOS dynamic linker (dyld) provides a detailed error message when this happens. Use the Disable Library Validation Entitlement to circumvent this restriction.

I searched the internet but could not find any solution.

0

Answer 2

alain_grenoble OP

Apr ’20

I finally found a solution to obtain a notarised application which is functional.

The bundle is organised as follows

TestApp.app

Contents

MacOS

testAppp <-- a launcher (C binary)

myAlert <-- an alert dialogue (Cocoa binary)

Resources

winteracter <-- an X11 (Xquartz) window and dialogue (Fortran binary)

The binary "winteracter" is based on the Winteracter library <http://www.winteracter.com> which uses OpenMotif and Xquartz

winteracter binary

This binary is hardened manually (i.e. from outside Xcode) prior to the others

codesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" --entitlements "winteracter.entitlements" "winteracter"

winteracter.entitlements should only contain the following:

com.apple.security.cs.disable-library-validation

testApp and myAlert binaries

These are signed and hardened either manually

codesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" "$MYBINARY"

or using Xcode

In that case be sure to manually erase the field "Code Signing Entitlements" en Build Settings.

It may remained filled in even if you delete "Sandboxing" from the the Capabilities interface.

Once notarized the application is functional.

I tried sandboxing it but the infamous error "mapping process and mapped file (non-platform) have different Team IDs" went back !

But what were my mistakes?

1- Apple says that sandboxing keys must appear only once in entitlement file of the main binary, with other having only the "inherit" key. I wrongly assumed that com.apple.security.cs.disable-library-validation was inherited too.

2- I thought the key com.apple.security.app-sandbox was compulsory in entitlement files. Not at all!

3- I wrongly assumed that setting com.apple.security.app-sandbox to false is equivalent as no entitlement file. Wrong again!

4- I wrongly assumed that the Xcode interface "Signing & Capabilities" correctly manages the Build Settings

5- I performed so many trial an errors that I do not remember all by all dead ends where I got lost.

0