“codesign”

[quote='833602022, Etresoft, /thread/779910?answerId=833602022#833602022, /profile/Etresoft'] Or various command-line looks like pkgutil, codesign, or spctl? [/quote] [quote='833618022, DTS Engineer, /thread/779910?answerId=833618022#833618022'] Stick with installer packages but use pkgutil to check their signature. [/quote] Thanks for the responses! pkgutil was considered but we wanted to avoid parsing of the command line tools output. We are primarily interested in the certificate subject names present in the package signature. The intention is to make sure that we install packages that are not only validly signed or accepted by Gatekeeper, pkgutil. And it looks like one would need to parse the output of command line tools to check if a specific team ID is present. That's definitely doable but we wanted to look into options with proper API that we could call from ObjC/Swift before going to an option with running a command line from code.

It looks like that was a Google thing originally. After Google abandoned it, Apple didn't want to take it up. Have you tried the standard signature verification APIs? Or various command-line looks like pkgutil, codesign, or spctl?

Actually, I just found this within the Console output: Library Validation failed: Rejecting '/Users/chip/Library/Containers/com.chipcastle.pathmanager/Data/tmp/tebako-runtime-20250404-48697-v1sra5/libui.dylib' (Team ID: none, platform: no) for process 'PATHmanager(48697)' (Team ID: BXN9N7MNU3, platform: no), reason: mapping process and mapped file (non-platform) have different Team IDs This is strange, because I'm using the same Team ID in the cert when codesigning the libui.dylib and the app bundle. Additionally, I'm unclear on why the dylib would be located under /Users/chip/Library/Containers/com.chipcastle.pathmanager/Data/tmp/tebako-runtime-20250404-48697-v1sra5/libui.dylib, because not only is that not where I initially built the binary, it's not where I copied it for codesigning.

Getting back to this! Thanks again or the detailed response. The ugly truth is we need exec_b to be run from exec_a and by thirdparty tools that might need to call up it's UI. Think of exec_a as a sort of launcher program that orchestrates exec_b instances it's called up but so too do other parts of our pipeline, potentially. [quote='831858022, DTS Engineer, /thread/778169?answerId=831858022#831858022'] Add com.apple.application-identifier and com.apple.developer.team-identifier to your App. [/quote] Where should this be put? In the entitlements.plist we use while signing App? If we're to test the .inherit entitlement to just get exec_a launching exec_b, you're describing something like: # codesign other binaries... (macdeployqt does much of this work) # Sign child exec codesign ... --entitlements=./entitle_child.plist .../exec_b # Then sign the App (including the com.apple.application... tags) codesign ... --entitlements=./entitle_app.plist .../App.app Apologies if I'm missing the

[quote='779395021, ethanndickson, /thread/779395, /profile/ethanndickson'] The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. [/quote] Really. That’s a surprise. AFAIK Xcode isn’t capable of correctly exporting a Developer ID-signed NE sysex. See Exporting a Developer ID Network Extension. However, that’s not the main thrust of your question, so let’s continue… [quote='779395021, ethanndickson, /thread/779395, /profile/ethanndickson'] This is actually the same issue described in: [/quote] Right. Thanks for collecting those together. And, yeah, there’s definitely something weird going on here. [quote='779395021, ethanndickson, /thread/779395, /profile/ethanndickson'] One thing I'm particularly interested in is the outcome of … FB11086599 [/quote] I’ll come back to that in a sec, but first: [quote='779395021, ethanndickson, /thread/779395, /profile/ethanndickson'] I can't view it [/quote] Yep. That’s just how Feedback Assistant works. I have

Hi Quinn(@DTS Engineer), Thank you for the quick response and for the (updated) post! I had wondered about this warning, but I decided it was unimportant since it is also present on versions of my software which work. For instance, if I check the same file in the conda environment contained in a working version of the app on the same machine, it also displays this warning. I should also note that, on the M2 MacBook Pro (MacOS 14.1) I'm working with today, my MWE does not reproduce the error (i.e. scipy.sparse can be imported without error following signing), and it also has this warning. > codesign -dvvv /path/to/lib/python3.11/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-311-darwin.so Executable=/path/to/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so Identifier=_arpack.cpython-310-darwin Format=Mach-O thin (arm64) CodeDirectory v=20400 size=3806 flags=0x10000(runtime) hashes=113+2 location=embedded Library validation warning=OS X SD

I see the whole error now, thanks to your instructions, but i still don't understand it/know how to fix it: CodeSign /Users/mjw/Library/Developer/Xcode/DerivedData/test3-fplwbgvlqthlalgvxynxjlnmsemc/Build/Products/Debug-iphoneos/test3.app/test3.debug.dylib (in target 'test3' from project 'test3') cd /Users/mjw/Documents/Projects/Current/test2/test3 Signing Identity: Apple Development: Full Name (V6775UBEAS) Provisioning Profile: iOS Team Provisioning Profile: * (982489b4-4832-4f77-8246-e8b1ea49eff1) /usr/bin/codesign --force --sign 6411F4C28E0E1A991FBFE8E1F1A89B77B589EC21 --timestamp=none --generate-entitlement-der /Users/mjw/Library/Developer/Xcode/DerivedData/test3-fplwbgvlqthlalgvxynxjlnmsemc/Build/Products/Debug-iphoneos/test3.app/test3.debug.dylib Warning: unable to build chain to self-signed root for signer Apple Development: Full Name (V6775UBEAS) /Users/mjw/Library/Developer/Xcode/DerivedData/test3-fplwbgvlqthlalgvxynxjlnmsemc/Build/Products/Debug-iphoneos/test3.app/test3.debug.dylib

It's definitely an Apple code signing issue. I connected my phone to my mac with a cable and created a brand new test project. I ran it on the simulator and it ran and showed hello world. When tried to run it on my phone, it errored (Command CodeSign failed with a nonzero exit code). If you would please help me debug code signing, I would really appreciate it. Thanks!

Yes, that's correct. That error only only occurs when installing via TestFlight and pops up twice. The app is never installed under /Applications. To be clear, before codesigning, the app runs fine on my system (always has). As a further test, if I extract the pkg file that I uploaded via Transporter, which is subsequently available via TestFlight, I get this: /tmp λ xar -xf ~/code/ruby/PATHmanager.pkg /tmp λ ll total 8 drwxrwxrwt 7 root wheel 224 Mar 31 09:23 . drwxr-xr-x 6 root wheel 192 Mar 20 09:49 .. -rw-r--r-- 1 chip staff 1217 Mar 31 09:23 Distribution drwx------ 3 chip wheel 96 Mar 20 09:50 com.apple.launchd.AUOVCHr68r drwx------ 5 chip staff 160 Dec 31 1969 com.chipcastle.pathmanager.pkg srwxr-xr-x 1 chip wheel 0 Mar 20 09:50 mykitty-1525 drwxr-xr-x 2 root wheel 64 Mar 30 15:31 powerlog /tmp λ cpio -i < com.chipcastle.pathmanager.pkg/Payload 58137 blocks /tmp λ ll total 8 drwxrwxrwt 8 root wheel 256 Mar 31 09:23 . drwxr-xr-x 6 root wheel 192 Mar 20 09:49 .. -rw-r--r-- 1 chip staff 1217 Ma

There are a bunch of factors that could lead to this problem but, after doing a bunch of testing here in my office, I suspect that this is a bug in local network privacy )-: To start, I’m testing on macOS 15.3.2 (24D81), in a VM, restoring from a clean snapshot between each test. I have a test tool that connects either via Network framework or BSD Sockets. The code is pasted in at the end of this email. Note This relies on the helpers in Calling BSD Sockets from Swift. The tool is signed with an Apple Development signing identity: % codesign -d -vv Test778457 … Authority=Apple Development: Quinn Quinn (7XFU7D52S4) … Note This is different from your case, because Homebrew uses ad-hoc signing. I was hoping that signing the code might help. It does not. I have a launchd property list that runs my shell script: % plutil -p com.example.Test778457.plist { Label => com.example.Test778457 ProgramArguments => [ 0 => /Users/quinn/Test778457.sh ] } And a shell script that runs my tool: % cat Test778457

Yes, sorry that I wasn't clear - The error did occur when attempting to open the app with TestFlight (the dialog box opened twice with the same message, BTW.) Plus, PATHmanager.app is neither installed under /Applications, nor ~/Applications. If there's something else I can do to get it installed, I'm all ears. :-) I'll post the output of your suggested commands from the extracted .pkg file that was uploaded using Transporter (hopefully that helps?): Signature dump for app bundle /tmp λ codesign -d -vvv PATHmanager.app/ Executable=/private/tmp/PATHmanager.app/Contents/MacOS/PATHmanager Identifier=com.chipcastle.pathmanager Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=223206 flags=0x10000(runtime) hashes=6964+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=a7e912f449ef085b27467d282bfeca980b8e4d9c CandidateCDHashFull sha256=a7e912f449ef085b27467d282bfeca980b8e4d9c9063d3b31bb34aaa15383e7d Hash choices=sha256 CMSDigest=a7e912f449ef085b27467d282bfeca980b8e4d9c9

[quote='831709022, chipcastle, /thread/774923?answerId=831709022#831709022, /profile/chipcastle'] I was able to get it submitted to TestFlight, but am now getting a slightly different error for the dylib than before: [/quote] So, you’re seeing this when launching the app that you installed using TestFlight? If so, reproduce the problem and then dump the signature of your app and its embedded dynamic library. So, this: % codesign -d -vvv /Applications/PATHmanager.app and this: % codesign -d -vvv /Applications/PATHmanager.app/Contents/Frameworks/libui.dylib They should be the same, that is, both signed by Apple Mac OS Application Signing. Is that what you see? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com