codesign

Can you clarify the warning? Does it say the app was downloaded from the internet and no malware was found? Or does it say something worse? If this is an app downloaded from the internet, then it's going to say it was downloaded from the internet. No way around that unless you want to put it in the Mac App Store. If it is just an app, then there is no reason to put it inside a DMG. Just compress it into a zip file. I have no idea what you mean by complete codesigning using the third-party app itself—not via command-line scripts. Are you saying that you didn't use Xcode to build the app? If so, then you're on your own. You are totally at the mercy of whatever tool you are using to build the app. These things are a single button click in Xcode.

Solved (or more like worked around whatever weird issue this was). I realized on this occasion I'd only tried building to VM, not YYC, although I usually tested both in the past if there were any issues. On YYC I was able to build without the codesigning error, after which I needed to open the xcodeproj manually which was located at (macuser)/gamemakerstudio2/GM_MAC/(gamename)/(gamename).

Blat! Sometimes I can’t see the wood for the trees )-: I downloaded your project today, installed it, re-enabled the setCodeSigningRequirement(_:) call, and then reproduced the problem. Cool. The error code logged, -67050, is errSecCSReqFailed, aka: % security error -67050 Error: 0xFFFEFA16 -67050 code failed to satisfy specified code requirement(s) This is very specific. The code doesn’t satisfy the requirement. So after a bit of faffing around I used codesign to actually test the requirement on that code: % codesign --verify -vvv -R =anchor apple AppleDTSLaunchDaemon1.app/Contents/Resources/DTSDaemon … test-requirement: code failed to satisfy specified code requirement(s) Well, that explains why XPC is complaining! But this should work, because the code is properly signed: % codesign -d -vvv AppleDTSLaunchDaemon1.app/Contents/Resources/DTSDaemon … Authority=Apple Development: Quinn Quinn (7XFU7D52S4) … And then it struck me. anchor apple is the wrong requirement. It checks whether

There are a number of potential issues here. First: [quote='779961021, dreisicht, /thread/779961, /profile/dreisicht'] codesign -s My Name --keychain keychain -f --deep … [/quote] Don’t use --deep when signing code. See --deep Considered Harmful for an explanation as to why not. As to what you should do, I’ll come back to that below. [quote='779961021, dreisicht, /thread/779961, /profile/dreisicht'] Unfortunately this signed package does not work when checking with spctl. [/quote] It’s generally best to avoid spctl for this sort of thing. If you want to test whether something will pass Gatekeeper, use the process described in Testing a Notarised Product. [quote='779961021, dreisicht, /thread/779961, /profile/dreisicht'] codesign -dv -veurbose=4 RenderRob.app/Contents/MacOS/libcrypto.3.dylib [/quote] That definitely belongs in Contents/Frameworks. See Placing Content in a Bundle. Coming back to how you should sign your code, there’s a general process for that described in: Creating distributi

[quote='833266022, mmccartney, /thread/778169?answerId=833266022#833266022, /profile/mmccartney'] Perhaps this is because we're trying to run things not delivered by the Mac Store yet. [/quote] If you’re trying to run a distribution-signed app then, yeah, that won’t work. See Don’t Run App Store Distribution-Signed Code. However, it seems like you were also testing development-signed app and that’s also failing. I tried your setup from Xcode, just to make sure that I wasn’t completely misleading you. AFAICT everything worked as expected. Here’s what I did: Using Xcode 16.3 on macOS 15.3.2, I created a new app from the macOS > App template. I then ran through the instructions in Embedding a command-line tool in a sandboxed app to create a new helper tool target and embed the results. I added a button that launched it: Button(Spawn) { do { print(will launch) let p = Process() let u = Bundle.main.url(forAuxiliaryExecutable: ToolX)! p.executableURL = u try p.run() print(did launch) } catch { print(did not laun

[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