network system extension + macOS 14.2 update kills networking

Here are some additional console messages if it helps:

Disallowing com.xxxxxxxxxxxxxxxx.networkagent because no eligible provisioning profiles found

/Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxx.xxxxxxxxxnetworkagent not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/, NSLocalizedDescription=No matching profile found}

mac_vnode_check_signature: /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent: code signature validation failed fatally: When validating /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements:

proc 2260: load code signature error 4 for file "com.xxxxxxxxxxxxxxxx.networkagent"

ASP: Security policy would not allow process: 2260, /Library/SystemExtensions/ACB1E368-5355-4959-9800-737ED2BE9EDC/com.xxxxxxxxxxxxxxxx.networkagent.systemextension/Contents/MacOS/com.xxxxxxxxxxxxxxxx.networkagent

The feedback ID … is: FB13458972

Thanks for filing that. This is most likely a bug in TestFlight, and hence a bug report is your best option. However, there’s a few things that I recommend that you check:

• Check that the bundle ID of your system extension is an immediate child of the bundle ID of your app. For example, if your app’s bundle ID is com.example.waffle-varnish then your sysex’s bundle ID might be ``com.example.waffle-varnish.wv-ne-provider`.

• If you’re manually signing your code, then for each code item that uses restricted entitlements:

  • Check that the code signing identifier matches its bundle ID.

  • Likewise for the bundle ID part of the App ID.

  • And that its provisioning profile’s allowlist authorises its specific App ID.

  This is only necessary if you’re signing manually; Xcode will always do the right thing here.

I’ve seen weird TestFlight problems like this because the developer was signing their code manually and decided to give multiple code items within their app the same code signing identifier. That made things easy because they only needed one provisioning profile, but it completely confused TestFlight )-:

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

Bundle IDs follow the correct form.

I use Xcode's archive to sign and submit the code to the App Store.

This morning, I repeated the experiment:

• install a fresh copy of macOS 14.1.2
• install app and then its network system extension
• but this time I uninstalled the network system extension before upgrading to 14.2
• Upgraded to 14.2

This time networking worked from the beginning, but I still could not run the main application.

It looks like Apple is following a "fail secure" approach when a network system extension fails (i.e., if a network system extension fails, no networking is allowed) as opposed to a "fail open" approach.

As a user and a 3rd party developer, I would prefer a "fail open" approach.

I will test alternative distribution approaches ((1) test version using the computer's registered UUID, and (2) independent distribution after notarizing the app) to see how the system behaves.

The bug may be tied to TestFlight.

I ran another test.

• Created another instance of macOS 14.1.2.

• Deployed my app with a Development provisioning profile for the main app and network system extension.

• Upgraded to macOS 14.2.

• Everything proceeded smoothly.

• No loss of networking. No complaints of invalid profile. Everything just worked.

I started the process of testing a 3rd distribution method using Developer ID and content-filter-provider-systemextension instead of content-filter-provider, but the process looked complicated. I'll wait to see if Apple gives any guidance (or fixes) TestFlight.

I have filed another feedback, FB13468019, this one targeted at TestFlight.

The problem is using TestFlight with an app with a network system extension. In the last two days, I

• Released an app via the Mac App Store.
• Used Apple Configurator to restore a Mac mini to macOS 13.6 and Safari 16.6
• Installed the app with network system extension from the App Store and installed the network system extension.
• Upgraded from Safari 16.6 to 17.2.1 (which had caused problems when deployed with TestFlight). No problem.
• Upgraded from macOS 13.6 to 13.6.3 (which had caused problems when deployed with TestFlight). No problem.
• Upgraded from macOS 13.6.3 to 14.2.1 (which had caused problems when deployed with TestFlight). No problem.
• Verified the problem still exists today by sending out the released program via TestFlight, and it killed networking when doing one of the upgrades.

As of this writing (2024-01-04), I would not recommend using TestFlight for testing an app with a network system extension.