i would like to code sign a mac app but leave out the hardened runtime business because some third party libraries (python-related if it is important) are causing troubles with that.
e.g. the benefit of code signing is that it keeps people from modifying the app contents. this is of course a benefit even without the hardened runtime.
is there a way to do this any more? it seems like it used to be an option.
i realize this requires non app store distribution.
it seems that apple policy is to not allow what i asked for earlier (code signed only). you have to do the whole hardened runtime business for all sub-executables unless you want macOS to flag your app as potentially harmful
fyi if anyone is looking for similar, i found this, seems fairly descriptive but non trivial as they say
started going thru it
the trick seems to be the step where they talk about adding a new copy files phase and 'check the "code sign on copy" button'
but it looks like it will require some trial and error for my particular case
i realize this requires non app store distribution.
You have that backwards:
The hardened runtime is required for all apps distributed independently, using Developer ID signing.
It’s not currently required for Mac App Store apps. However, I strongly recommend that you enable it in your Mac App Store app even though it isn’t required. It’s enables multiple security features that you really want enabled.
some third party libraries (python-related if it is important) are causing troubles with that.
I recommend that you work with the library vendor to fix those problems. And if they can’t or won’t do that, I recommend that you reconsider those dependencies. The hardened runtime isn’t exactly new, being introduced in macOS 10.14 back in 2018.
Having said that, you can opt out of most hardened runtime security enhancements using hardened runtime exception entitlements.
IMPORTANT Don’t just enable all of these. Some of are redundant (com.apple.security.cs.disable-executable-page-protection is a superset of com.apple.security.cs.allow-unsigned-executable-memory is a superset of com.apple.security.cs.allow-jit) and some of them will make your life harder down the line [1]. Work with your library vendor to determine exactly what hardened runtime exceptions you need, and apply just those.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Specifically, com.apple.security.cs.disable-library-validation makes it harder to paste Gatekeeper, as discussed in Resolving Gatekeeper Problems Caused by Dangling Load Command Paths.
ah ha, interesting on my backwards interpretation of hardened runtime. thanks for that clue. from the above apple "embedding a helper tool" doc, i was able to get past the issues with the runtime entitlements (i think...), but then got stuck on a dlopen( ) (dynamic library open?) issue with the main Python library. it looks like some others have reported this issue as i was looking around online, but i havent found a solution that works for me yet. at least i made some progress.
got stuck on a
dlopen… issue with the main Python library
I’m happy to offer advice on that, but you’ll need to share some details about what the actual problem is.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
thanks, will have to get back to this in the near future, we had to put it aside because the signing looks to be non-trivial. it looks like the method we are using to build the underlying code ("pyinstaller" ... python installer) packs a whole bunch of .so and .dylib libraries together in a directory hierarchy, and each one of these need to be signed, possibly. yikes.
