Disabling Hardened Runtime For Ad Hoc Signing Only

Hmmm, that seems to be an Xcode-ism. AFAIK there’s nothing fundamentally wrong with enabling the hardened runtime on ad-hoc signed code.

Having said that, I generally recommend that you avoid ad-hoc signed code because it doesn’t have a stable designated requirement, something that’s important per the discussion in TN3127 Inside Code Signing: Requirements. So, while ad-hoc signed code has its place — for example, it’s ideal for tools like Homebrew — it’s not something I’d use with Xcode.

Is there a reason you can’t switch to an Apple Development signing identity? That’s my recommended path forward.

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

@DTS Engineer Thank you for your attention to this issue.

I'm not allowed to use an Apple Development identity as this project is distributed to others and we can't tell them that they have to have a signing identity.

We're signing a stub app w/ a test suite that runs the CPython test suite on Mac Catalyst. If I use ad-hoc and hardened runtime, the Python binary in Python.framework won't load (code for the support: https://github.com/freakboy3742/cpython/pull/8#issuecomment-2837308049)

AFAIK there’s nothing fundamentally wrong with enabling the hardened runtime on ad-hoc signed code.

I asked about this internally and uncovered a useful titbit. If you enable the hardened runtime in ad-hoc signed code, simple things work but you’ll run into problems if you depend on libraries. The hardened runtime enables library validation by default, and library validation requires that any library code loaded in your process either:

• Be part of the platform [1]

• Have the same Team ID as the main executable

If you’re ad-hoc signed then you have no Team ID and thus, if you have library validation enabled, you can only load platform libraries.

If I use ad-hoc and hardened runtime, the Python binary in Python.framework won't load

Yep. That’s exactly the case I outlined above.

You might be able to get around this by disabling library validation via the com.apple.security.cs.disable-library-validation entitlement.

Having said that, I’m gonna stand by my original advice here. If you ad-hoc sign code you will run into numerous weird problems like this.

we can't tell them that they to have a signing identity.

Well you can, but you’re choosing not to. Like all engineering, this is a trade-off. You can either educate your clients that they’ll need a Apple signing identity or you can educate your clients about library validation. I’d rather you do the former, because it solves this problem and numerous other problems. But you’re free to do the latter if you like.

Note that, if this binary gets distributed widely then someone will eventually have to sign it with an Apple signing identity, because both of our standard distribution paths (Mac App Store and direct distribution) require that.

Also, Apple Development signing does not require that you be part of a paid team. It just requires that you have an Apple Account. Xcode can use any Apple Account to sign code under its Personal Team feature. That has significant limitations — see Developer > Support > Choosing a Membership — but most of them are only critical on iOS and its child platforms.

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

[1] The exact definition of what that means is complex, but you can think of it as meaning built in to the OS.

@DTS Engineer I have used the entitlement for now, but usually on an Xcode project it'll disable hardened runtime on Ad Hoc builds -- any insight on why this isn't happening? The code is in the linked PR at iOS/testbed.

Having said that, disabling library validation is a valid (pun intended) solution for now, since we've got plenty of stuff to sort out w/ the app. So thank you

disabling library validation is a valid … solution for now

OK, cool.

any insight on why this isn't happening?

Not really. But I’m also not in a position right now to test this with a large project. If you want to keep digging into this, I recommend that you isolate it a small test project and, if that doesn’t reveal the issue, feel free to post a link to it and I’ll take another look.

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