Post

Replies

Boosts

Views

Activity

Reply to sysextd: "no policy, cannot allow apps outside /Applications" - NEFilterDataProvider system extension on macOS 26
Adding a data point since our config is a step further than the OP's and still fails — might narrow this down. Setup: NEFilterDataProvider system extension, Developer ID Application signed, fully notarized (Accepted) and stapled, running on macOS 27.0 "Golden Gate" (26A428) — the public GM release, not a beta. Unlike the OP, our entitlements already use the -systemextension suffix on both sides: Container app: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], com.apple.developer.system-extension.install = true Extension: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], app-sandbox = true, application-groups set And unlike the OP's finding, our Developer Portal-issued profiles DO contain content-filter-provider-systemextension — confirmed by decoding the embedded provisioning profile directly (security cms -D) on both the container and the extension. So in our case the portal is generating the right entitlement value; that's not the blocker. We still get the exact same rejection: sysextd: no policy, cannot allow apps outside /Applications ...immediately after sysextd validates and dumps our app's own entitlements (confirmed correct) via the unified log. The app is genuinely at /Applications/SecureMac.app, no quarantine xattr, no translocation. /Library/SystemExtensions/db.plist shows zero prior record for our extension identifier — so it's not a stale/poisoned cache from earlier testing either. A full reboot didn't change anything. The one thing that does correlate: we found a crash report on this same Mac from a completely unrelated, already-shipping Developer ID product (Little Snitch) showing "developerMode" : 1 in its own crash metadata from when its system extension was actively working. Our current system state has developerMode: false (SIP enabled, the normal/correct posture). That strongly suggests activation is effectively gated behind Developer Mode (and therefore SIP disabled) even for a fully correct, notarized, Developer ID + -systemextension-suffixed configuration — not just for ad-hoc/local development builds. Given that: is there a supported path for a Developer ID + notarized NEFilterDataProvider extension to activate for an ordinary end user — SIP enabled, Developer Mode never touched — at all on 27.0? If Developer Mode really is required, that's a hard blocker for shipping this to customers, not just a development inconvenience, and I want to make sure we're not missing a step before concluding that. Happy to share full log excerpts / entitlement dumps if useful.
Sep ’26
Reply to sysextd: "no policy, cannot allow apps outside /Applications" - NEFilterDataProvider system extension on macOS 26
Adding a data point since our config is a step further than the OP's and still fails — might narrow this down. Setup: NEFilterDataProvider system extension, Developer ID Application signed, fully notarized (Accepted) and stapled, running on macOS 27.0 "Golden Gate" (26A428) — the public GM release, not a beta. Unlike the OP, our entitlements already use the -systemextension suffix on both sides: Container app: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], com.apple.developer.system-extension.install = true Extension: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], app-sandbox = true, application-groups set And unlike the OP's finding, our Developer Portal-issued profiles DO contain content-filter-provider-systemextension — confirmed by decoding the embedded provisioning profile directly (security cms -D) on both the container and the extension. So in our case the portal is generating the right entitlement value; that's not the blocker. We still get the exact same rejection: sysextd: no policy, cannot allow apps outside /Applications ...immediately after sysextd validates and dumps our app's own entitlements (confirmed correct) via the unified log. The app is genuinely at /Applications/SecureMac.app, no quarantine xattr, no translocation. /Library/SystemExtensions/db.plist shows zero prior record for our extension identifier — so it's not a stale/poisoned cache from earlier testing either. A full reboot didn't change anything. The one thing that does correlate: we found a crash report on this same Mac from a completely unrelated, already-shipping Developer ID product (Little Snitch) showing "developerMode" : 1 in its own crash metadata from when its system extension was actively working. Our current system state has developerMode: false (SIP enabled, the normal/correct posture). That strongly suggests activation is effectively gated behind Developer Mode (and therefore SIP disabled) even for a fully correct, notarized, Developer ID + -systemextension-suffixed configuration — not just for ad-hoc/local development builds. Given that: is there a supported path for a Developer ID + notarized NEFilterDataProvider extension to activate for an ordinary end user — SIP enabled, Developer Mode never touched — at all on 27.0? If Developer Mode really is required, that's a hard blocker for shipping this to customers, not just a development inconvenience, and I want to make sure we're not missing a step before concluding that. Happy to share full log excerpts / entitlement dumps if useful.
Replies
Boosts
Views
Activity
Sep ’26