“codesign”

[quote='814996022, dongkeqiang, /thread/768361?answerId=814996022#814996022, /profile/dongkeqiang'] Is there any difference between the two ? [/quote] It’s hard to say for sure without seeing the binaries involved, but it’s most likely that one has the hardened runtime enabled and the other doesn’t. To see if an app has the hardened runtime enabled, look for the runtime flag in its signature. For example, Pacifist does: % codesign -d -vvv /Applications/Pacifist.app … CodeDirectory v=20500 size=11364 flags=0x10000(runtime) … … but Apple Configurator does not: % codesign -d -vvv /Applications/Apple Configurator.app … CodeDirectory v=20400 size=17981 flags=0x2000(library-validation) … … The hardened runtime is required for directly distributed apps. It’s optional for Mac App Store apps. I generally recommend that you enable it everywhere. [quote='814993022, dongkeqiang, /thread/768361?answerId=814993022#814993022, /profile/dongkeqiang'] Now, if it can't be opened, no crash record will be genera

I've been able to re-test all of these automatic codesigning/provisioning/notarization suggestions on Xcode 16.1, by modifying all of the bundle IDs, changing to Automatically Manage Signing and attempting again with my Admin developer portal credentials. It does not work. I still get all 3 errors of: There is a problem with the request entity - you already have a current Developer ID Application Managed (With Kext) certificate or pending certificate request. No profiles for com.company.HostingApp.Driver were found - Xcode couldn't find any Developer ID provisioning profiles matching 'com.company.HostingApp.Driver'. No profiles for com.company.HostingApp were found - Xcode couldn't find any Developer ID provisioning profiles matching 'com.company.HostingApp'. It seems you are correct, the Admin level does not have authority to manipulate the developer portal side of the automatic process. Tightly controlled account access does not really work in the modern world of two-factor authentication and remot

Sorry to hijack, but that didn't work for me. I'm trying a command-line utility, doing: static size_t get_thread_count(pid_t pid) { mach_port_t me = mach_task_self(); mach_port_t task; kern_return_t res; thread_array_t threads; mach_msg_type_number_t n_threads; res = task_for_pid(me, pid, &task); if (res != KERN_SUCCESS) { fprintf(stderr, Unable to get task for pid %d: %dn, pid, res); return 0; } res = task_threads(task, &threads, &n_threads); if (res != KERN_SUCCESS) { fprintf(stderr, Could not get threads: %dn, res); return 0; } res = vm_deallocate(me, (vm_address_t)threads, n_threads * sizeof(*threads)); // Ignore error return n_threads; }``` and using an entitlements plist of and using codesign --sign - --entitlements ./ent.plist --deep ./t3 --force to get it in there, but it fails with error 5. (Even when run as root. 😄) This could be how I'm codesigning it, of course; I was just doing a simple CLI tool test first.

That failed in the automatic process, though - it kept bringing in the old dext bundle ID, and it was only AFTER involving the Team Agent and registering a new dext bundle ID that I got the correct results So, the issue here is that automatic works by having Xcode modify the portal, so if you're account type can't modify the portal configuration, Xcode can't fix it. You can fix this in two ways: You can have the Team Agent log in to Xcode and configure the project, which will then cause Xcode to modify the portal. You can modify the portal configuration yourself so that it's configuration matches what it should. This is ultimately a business decision, but my personal experience has been that out development flow works MUCH better with admin accounts. With a large company (which obviously has concerns about legitimate app distribution), my own inclination would be to have two different accounts- a development account where all developers could be admins but which never actually shipped software and a company a

Hi Kevin, First, thank you for your patience on all of this. It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now. FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere else. That's the issue, though. I don't know EXACTLY why automatic codesigning is failing - at least with manual code signing I can look at what settings I am using and try something else. If I just press automatic and it doesn't work (it hasn't yet), there does not seem to be anything further I can

You're right, I'm not using XCode for development. I know why this issue didn't occur, and I hope it can be helpful for those who come across this blog in the future. But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: The reason for this issue is that when using @ electron/osx sign for signing, some parameters in the old option were invalid, resulting in the execution of the default entitlement. plist file in the node_module package. But now, I have encountered a new problem and I hope you can help me take a look: When I submitted a new binary file for review, I received a response saying that the software could not be opened, and other phenomena included: Before I signed the app, it could run normally, but after I signed it, I found that the app package could no longer run. I submitted the version to Apple Connect, but even after downloading it through TestFlight, I couldn't open it. Even if I turn off sandbox mode in the entities

[quote='768573021, fraapaul, /thread/768573, /profile/fraapaul'] Is it correct that codesign only uses certificates from the local Keychain … ? [/quote] Correct. If you use the Xcode organiser to export a Developer ID signed app [1], you can look at Packaging.log to see how this works. codesign is used to generate the data to be signed and then to apply the signature, but the actual signing is done using a web service. AFAIK all of this is considered an implementation detail and not documented for third-party use (other than via Xcode and xcodebuild, of course). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You have to remove your Developer ID signing identity from the keychain in order to get cloud signing. I have mine in a separate keychain — I talk about that more in The Care and Feeding of Developer ID — so I just removed that keychain from the search list in Keychain Access.

[quote='813976022, dongkeqiang, /thread/768361?answerId=813976022#813976022, /profile/dongkeqiang'] Amazing, it worked. [/quote] Yay! [quote='813976022, dongkeqiang, /thread/768361?answerId=813976022#813976022, /profile/dongkeqiang'] But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: [/quote] My understanding is that you’re not using Xcode to sign and package your app. Given that, there’s a limit to how much I can help you with. Your third-party tooling is probably based on Apple’s low-level tools, xcodebuild (perhaps), Clang, codesign, and so on. Those tools don’t add entitlement claims spontaneously. They only do that if you instruct them to. So you have two choices: Seek help from the support channel for the tools you’re using. Or take ownership of the tool, and work through the steps that it takes to create your package to see where it’s adding these entitlement claims. If you get to a point where you see an Apple tool

Building a notarized Perl app on a Mac using the command line? You're kind of fighting the whole world at once there, eh? 😄 In addition to the hardened runtime, you'll need some entitlements to relax said hardened runtime. Put those in an XML file and use the --entitlements flag with codesign. Make sure to completely test your installation with all kinds of funky edge cases. In addition to all the up-front notarization checks, there are certain checks that happen only at runtime, or only at runtime when you try to trigger something like dynamic loading or JIT execution. That is the part that trips up most people in your situation who get that far. I don't know which entitlements Perl will require - most likely all of them.