codesign

System Extensions framework is meant to be called from a GUI application. Is that the case here? I see a lot of folks try to use the framework from a command-line tool (or daemon or whatever) that’s pretending to be a GUI app, and that often ends badly. I'm using a gui container app, it's just the default App macos template from xcode with the init for the App class changed to start the system extension. Check that you’re container app has a reasonable structure and that the sysex is embedded within that: Seems almost identical:  tree Applications/dns-proxy-tests.app Applications/dns-proxy-tests.app └── Contents ├── Info.plist ├── Library │ └── SystemExtensions │ └── com.myteam.dns-proxy-tests.ne.systemextension │ └── Contents │ ├── Info.plist │ ├── MacOS │ │ └── com.myteam.dns-proxy-tests.ne │ ├── _CodeSignature │ │ └── CodeResources │ └── embedded.provisionprofile ├── MacOS │ ├── __preview.dylib │ ├── dns-proxy-tests │ └── dns-proxy-tests.debug.dylib ├── PkgInfo ├── Resources ├── _CodeSignature │ └── CodeR

Error 1 in the OSSystemExtensionErrorDomain is OSSystemExtensionErrorUnknown. That doesn’t sound good. [quote='829698022, conectado, /thread/776759?answerId=829698022#829698022, /profile/conectado'] after that I don't see any of the delegate being called [/quote] And that’s also not good. System Extensions framework is meant to be called from a GUI application. Is that the case here? I see a lot of folks try to use the framework from a command-line tool (or daemon or whatever) that’s pretending to be a GUI app, and that often ends badly. Check that you’re container app has a reasonable structure and that the sysex is embedded within that: QNE2DNSProxyMac.app/ Contents/ Info.plist Library/ SystemExtensions/ com.example.apple-samplecode.QNE2DNSProxyMac.SysEx.systemextension/ Contents/ Info.plist MacOS/ com.example.apple-samplecode.QNE2DNSProxyMac.SysEx _CodeSignature/ CodeResources embedded.provisionprofile MacOS/ QNE2DNSProxyMac … _CodeSignature/ CodeResources embedded.provisionprofile Check that the app is si

The devil is in the details here. First, this: [quote='776479021, baxterjo, /thread/776479, /profile/baxterjo'] from a VScode terminal and I am getting permissions prompts. [/quote] A VS Code terminal is not Terminal. The exception carved out for Terminal doesn’t apply to other terminal-ish apps. What’ll actually happen in the VS Code case is gonna depend on how it implemented its terminal environment. It’s possible that the system will see VS Code as the responsible code for your program and thus VS Code’s Local Network privilege will apply. However, it’s also possible for programs to do things that break that responsibility chain, in which case your program will look like a tool being run in a background context. What happens then is complex. Regardless, this is something to talk about with the VS Code folks. Coming back to Terminal, that exception works as documented, at least in my experience. Consider my built copy of the TLSTool sample code: % codesign -d -vvv `which TLSTool` … Authority=Develo

codesign wants too access my certain key in my keychain

[quote='829245022, chipcastle, /thread/774923?answerId=829245022#829245022, /profile/chipcastle'] ran my codesigning script which signs in the following order [/quote] Step 2 is unnecessary here. Using the terms from Creating distribution-signed code for macOS, your app is bundled code. That means you only need to sign the bundle. If you sign the PATHmanager executable separately, that signature is just overwritten when you sign the PATHmanager.app. [quote='829245022, chipcastle, /thread/774923?answerId=829245022#829245022, /profile/chipcastle'] so I continue to be puzzled [/quote] That error is misleading, in that there are two potential causes: The executable is missing this entitlement. The executable’s code signature is broken, which means that App Store Connect is unable to check that the entitlement is present. I suspect you’re hitting the second case. If you unpack the installer [1] and check the app’s code signature like so: % codesign --verify -vvv PATHmanager.app what does it repor

Thanks for the suggestion. I was able to extract libui.dylib by running bundle install with the following configuration: cat ~/code/ruby/pathos_macos/.bundle/config --- BUNDLE_PATH: vendor/ BUNDLE_WITHOUT: development:test This created vendor/ruby/3.3.0/gems/libui-0.1.2-arm64-darwin/vendor/libui.dylib, which I ditto'd over to ~/Desktop/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib I bumped version (as described previously) and ran my codesigning script which signs in the following order (under /Users/chip/Desktop/distribution/PATHmanager.app/): Contents/Frameworks/libui.dylib Contents/MacOS/PATHmanager PATHmanager.app directory After uploading the .pkg file using Transporter, I get this old error: Validation failed (409) App sandbox not enabled. The following executables must include the com.apple.security.app-sandbox entitlement with a Boolean value of true in the entitlements property list: [( com.chipcastle.pathmanager.pkg/Payload/PATHmanager.app/Contents/MacOS/PATHmanager )] Refer