Hi, I have some dylib files that I embedded into my project (a macOS app) and selected the 'Embed without signing' option. After I run xcodebuild -exportArchive command, I saw that the signature of those file change to my certificate. I'm using developer-id method and the dylib files are embedded in my system extension. How can I remove the force codesign for those files from the xcodebuild command. Thanks
How can I remove the force codesign for those files from the xcodebuild command.
You can’t.
Having said that, you don’t want to do that, for both business and technical reasons:
At the business level, you are responsible for putting that code on the user’s system and thus you should confirm that responsibility by signing it as your code.
At a technical level, if you leave the library signed by another team you won’t be able to use it unless you disable library validation, and library validation is a really important security feature.
Why do you not want to re-sign these libraries?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Hi, I'm running into a similar issue on iOS. In my case I have a build phase that signs the dylib and computes a checksum over it for anti-tamper validation. When the archive step resigns the dylib it embeds the new code signature, causing my checksums validation to fail at runtime.
I'm running into a similar issue on iOS. In my case I have a build phase that signs the dylib and computes a checksum over it for anti-tamper validation.
That’s not something we support. The App Store re-signs your product as part of its distribution pipeline, and that re-sign is going to break your checksums regardless of what you do on the build side.
Oh, and to be clear, this re-sign is the minimum that the App Store will do. It may also do other processing, like:
Encrypting your code
Removing architectures that are unnecessary on the client device
Recompiling bitcode
Other stuff I’ve forgotten
Other stuff that may get added in the future
And that last point is why we don’t support this. Even if you get this right today, there’s no guarantee that it won’t break in the future.
When doing DRM, you have to decide up front what threats you are trying to protect yourself from. Doing anti-tamper protection on your dynamic libraries is pointless IMO because, if someone is in a position to modify your dynamic libraries, then they are also in a position to modify your anti-tamper checks in your main app. So what threat is this protecting your from?
You would be better off spending your time implementing App Attest.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"