NSTask launchRequirementData

Question

Created 1d

Replies 2

Boosts 0

Participants 2

I've noticed that NSTaks has this property as of macOS 14.4 @property (nullable, copy) NSData *launchRequirementData API_AVAILABLE(macos(14.4)) API_UNAVAILABLE(ios, watchos, tvos, visionos);

It has no documentation whatsoever. Even google search has no clue. Does this have anything to do with code signature requirements validation? Any explanations and examples would be appreciated!

Answered by DTS Engineer in 823047022

Does this have anything to do with code signature requirements validation?

Yes. However, it’s not using the traditional code signing requirements, as discussed in TN3127 Inside Code Signing: Requirements. Rather, it uses the new lightweight requirements. We talk about these concepts in general in:

WWDC 2023 Session 10266 Protect your Mac app with environment constraints
Defining launch environment and library constraints documentation

However, the easiest way to build this data is with the LightweightCodeRequirements framework. I show an example of this in this thread.

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

Boost

Answer 1

DTS Engineer OP

Apple

1d

Accepted Answer

Recommended

Does this have anything to do with code signature requirements validation?

Yes. However, it’s not using the traditional code signing requirements, as discussed in TN3127 Inside Code Signing: Requirements. Rather, it uses the new lightweight requirements. We talk about these concepts in general in:

WWDC 2023 Session 10266 Protect your Mac app with environment constraints
Defining launch environment and library constraints documentation

However, the easiest way to build this data is with the LightweightCodeRequirements framework. I show an example of this in this thread.

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

1

Answer 2

DTS Engineer OP

Apple

4h

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

What would be suggested way to achieve same level of validation with pre-14.4 macOS versions?

There isn’t a good way to do this on earlier system, which is why we added the feature (-:

You might want to check out this thread, where I’ve been discussing a similar issue with a different developer.

I’m happy to use this thread to discussion your specific situation, but I need more context. For example, if you’re building an app and spawning a tool that’s embedded in that app, then app bundle protection offers some protection from these attacks on macOS 13 and later [1].

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

[1] For more that, follow the link in the Trusted Execution Resources post.

0