Entitlement issues with network extension

Are these entitlements being whitelisted by your provisioning profile? Remember that both your app and you sysex have profiles, and each profile must whitelist the corresponding program’s entitlements.

You can check this stuff with

codesign

and

security cms

. For example:

% codesign -d --entitlements :- PassThroughProxyMac.app
… elided …
% security cms -D -i PassThroughProxyMac.app/Contents/embedded.provisionprofile
… elided …
% codesign -d --entitlements :- PassThroughProxyMac.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.PassThroughProxy-macOS.TransparentProxy.systemextension
… elided …
% security cms -D -i PassThroughProxyMac.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.PassThroughProxy-macOS.TransparentProxy.systemextension/Contents/embedded.provisionprofile
… elided …

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your response.

when looking at the entitlements of the embedded provisioning profile with "security cms" as you suggested, I see the correct app identifier:

<key>com.apple.application-identifier</key>

<string>RUXT127L01.com.team.AppName.NetworkExtension</string>

So this does not explain the first error I see (ignoring the identifier).

However, it does not contain the com.apple.security.application-groups entitlement. So maybe that explain the second error. The profile is managed by xcode. How can I add this entitlement to the provisioning profile ?

I am developing a network extension based firewall and I have the same issue.
trustd is reporting the same error:

Code Block 
entitlement com.apple.application-identifier is ignored because of invalid application signature or incorrect provisioning profile

The error disappears as soon as I enable sandbox for the network extension.
Are network extensions only supposed to run in a sandbox? If not, why this error?

Are network extensions only supposed to run in a sandbox?

Yes.

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

Thank you Eskimo.
So this means that we *must* run the network extension in a sandbox even if we plan to release our app only outside the App Store?
I'm asking because it sounds a bit strange to me. We were able to compile, notarize and run a non-sandboxed network extension on both Catalina and Big Sur, on a normal Mac (I mean with SIP activated, and so on). It worked perfectly, aside from the logs entries I already mentioned. Both the sysex and its container app were not sandboxed.
Can you please clarify? I'm afraid I'm missing something obvious here...

I’m not sure what you want me to say here. You asked whether the App Sandbox is required for NE provider sysexes and the answer is yes. Things may work in some cases without it, but the answer to your specific question is crystal clear.

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

Ok, thank you.

Hi, im having this exact same problem and i can't seem to figure out a solution. I have the app sandbox enabled but i keep seeing this two errors in the logs. Every thing works fine in the app and i can communicate with the network extension. Could anybody help me? Thanks

Every thing works fine in the app and i can communicate with the
network extension.

If everything is working fine that I’m inclined to treat this as log noise.

Based on my previous investigation into this, I pretty sure that the com.apple.security.application-groups log entry is actually just log noise.

I’m less certain about the com.apple.application-identifier log entry. I would’ve thought that your extension would have a provisioning profile with that entitlement in its allowlist. I think what’s going on here is that the fact that the App Groups entitlement isn’t allowlisted has cause the system to not fully trust your provisioning profile and the App ID entitlement is one entitlement that requires that trust. However, I haven’t looked into this in great detail.

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

Thanks for your reply eskimo thats exactly what i thought. Another thing that led me to believe this is that im running a corporate antivirus called crowdstrike and i checked on the logs and they also get the same errors so i think its just log noise.
Unfortunately this logs seem to appear every time SecCodeCopySigningInformation. is called (i call it on handleNewFlow all the time) so that generates a ton of this logs. I hope this can be corrected in the future.
Again, thanks for the help.

Hi,

I think I may have a solution for you. I was struggling with this for last several months (btw also using SecCodeCopySigningInformation), always getting back to investigate and never found a solution until now. It definitely isn't just a log noise, but a real signing problem, which could potentially block release though app store.

First, some advice, which will save your time:

1. You might find suggestions like using com.apple.developer.networking.multicast entitlement - doesn't work, you are able to build and sign system extension, but it crashes with signature error when OS tries to load it.

2. Enabling Sandbox doesn't help either- but I definitely recommend enabling Sandbox for system extensions, you will need it for future release on App Store, if you plan it, and if you need to store/cache data, you can do it in protected group container with Sandbox on. It's worth the effort to Sandbox system extensions, although when pulishing notarized apps outside of App Store, it works without Sandbox.

3. One of the 2 messages generated complains about applicaiton.group. Ignore that. If you need to communicate through XPC, you need app group anyway.

4. You might find a suggestion to add keychain.access.group entitlement com.apple.token - forget it, it doesn't work with system extensions, you get a signing error when building. Although Apple's doc says com.apple.token is allowed by default, it is very likely tied to another entitlement, perhaps related to biometric reading. But keychain access group is actualy the culprit.

SOLUTION:
Define at least one keychain.access.group entitlement with your group ID in it, example: ABCDEFG.com.company.firewall

<key>keychain-access-groups</key>
<array>
<string>$(TeamIdentifierPrefix)com.company.firewall</string>
</array>

If you do that, "invalid application signature or incorrect provisioning profile" log message will go away.

Explanation:
When creating bundle id, you cannot select/deselect keychain access group (there used to be a checkbox for this couple of years ago, if I remember). Provisioning profiles are now automaticlaly generated with keychain.access.group added, so you have to define it even though you don't need it.

Regards,
Robert

Well, it doesn't quite work with Distribution certificate, although I'm using exact same bundle id settings.

The only difference between distribution and development entitlements is that System Extenion development prov.profile somehow contains following entitlement

Code Block 
				<key>com.apple.developer.system-extension.install</key>
		<true/>

which should only be present in the app bundle that registers extension, it should not be defined for system extension itself.

In any case, it looks like this precise definition inlcuding keychain.access.group makes the error message "invalid application signature or incorrect provisioning profile" disappear:

Code Block 
	<key>Entitlements</key>
	<dict>
				
				<key>com.apple.developer.system-extension.install</key>
		<true/>
				
				<key>com.apple.developer.networking.networkextension</key>
		<array>
				<string>app-proxy-provider</string>
				<string>content-filter-provider</string>
				<string>packet-tunnel-provider</string>
				<string>dns-proxy</string>
				<string>dns-settings</string>
		</array>
				
				<key>com.apple.application-identifier</key>
		<string>ABCDEFGH.com.company.firewall.dev</string>
				
				<key>keychain-access-groups</key>
		<array>
				<string>ABCDEFGH.*</string>
		</array>
				
				<key>com.apple.developer.team-identifier</key>
		<string>ABCDEFGH</string>
	</dict>

with actual keychain value defined in the extesnion project settings as ABCDEFGH.com.company.firewall

Lucky, people I am struggling over 1,5 year with code signing not working for not-paying dev accounts (and even Apple support cannot help maybe they are afraid to admt they no longer allow testing app od device for non-paid accounts).

That being said on Monterey I always see during run

Failed retrieving MusicKit tokens: Error Domain=ICErrorDomain Code=-7009 "Failed to retrieve bundle identifier of the requesting application. The requesting application is likely missing the "com.apple.application-identifier" entitlement." UserInfo={NSDebugDescription=Failed to retrieve bundle identifier of the requesting application. The requesting application is likely missing the "com.apple.application-identifier" entitlement.}. Throwing .permissionDenied.

2022-08-10 19:37:12.939452+0200 ConMusic[3082:33162] [DataRequesting] Failed retrieving tokens for MusicDataRequest.Context(url: https://api.music.apple.com/v1/catalog/us/artists/1264549322). Error = .permissionDenied.

.permissionDenied

I checked AppID on dev account and everything is OK what I am missing:/

This thread is about provisioning Network Extension providers. That capability is not supported by a free accounts (what Xcode calls a Personal Team). If your goal is to create an NE provider, you’ll need a paid account.

For information about which capabilities are supported by which account types, see Developer Account Help > Reference > Supported capabilities (macOS) and the equivalent docs for our other platforms. In this context the Apple Developer column shows the capabilities for a Personal Team.

If you’re not trying to create an NE provider, I recommend that you start a new thread with the details of your issue. Oh wait, it looks like you’ve started this thread. I’ll respond over there.

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